Tag: ai

Starting a career in Confidential Computing

Whether your interests lie in research, design, engineering or operations, there will be opportunities to find rewarding careers in Confidential Computing.

An IDC report published at the end of Q4 2025, revealed that nearly 75% of respondents saw “Lack of skilled personnel” as a hurdle to adopting Confidential Computing.  I was recently speaking at a conference on the subject of security – including, of course, Confidential Computing – and was answering questions in the hallway afterwards when someone asked me, “how would you suggest I start a career in Confidential Computing?”  The person asking was an engineer and had a good understanding of the basics, having spent some time a year or so ago trying out the technology, but now wanted advice on how to forge a career in the area.  As the Executive Director of the Confidential Computing Consortium, this felt like a topic on which I should have an opinion: I thought it might be interesting and useful to provide my thoughts here in an attempt to help fill the perceived gap in the expertise market.

There are, I think, four broad areas – though I initially replied with three – for someone looking to pursue a technical career in Confidential Computing.  There’s definitely overlap, and also opportunities for non-technical paths, but I’m going to concentrate on engineering-related, or at least heavily technical roles:

  1. Research
  2. Infrastructure
  3. CC-dedicated
  4. Generalist

Research

In Q2 of 2026, the CCC published a call for research proposals to receive funding from a grant fund. We expected a handful and received over 35 applications and several after the cut-off date. This signals that research in Confidential Computing topics is alive and well within academia. Some of these will be around low-level hardware and firmware, others much higher up the stack in, for instance, attestation and endorsement protocols. There are also opportunities for research outside academia in some of the key companies in this space who are building the infrastructure for Confidential Computing, but also for independent researchers interested in working on specific projects or vulnerabilities. As Confidential Computing matures and more use cases emerge, we can expect research opportunities to continue to grow.

Infrastructure

The industry needs to build out the infrastructure to allow Confidential Computing to become fully commoditised – and then to create offerings that provide ways for providers to differentiate themselves.  This area is particularly broad, as it encompasses everything from silicon design to cloud computing services such as key management services and all the way to Attestation Verification Services (AVS).  It also includes, as the Research area does not, roles within operations which can expect to look different to existing operations roles as monitoring, debugging and management techniques adapt to Confidential Computing.  Many of these jobs will be in silicon vendors, OEMS, hyperscalers and cloud service providers, but there are also likely to be existing enterprises and new start-ups who will be finding a niche in the Confidential Computing services market and need talented and expert engineering resources to succeed.

CC-dedicated

This area maybe overlaps a little with the enterprises and start-ups looking for a niche in the Confidential Computing ecosystem, but, more specifically refers to applications and services that make use of Confidential Computing in new ways, or adapt existing products to make the most of Confidential Computing, enabling new offerings to be provided to the market.  There are already many start-ups who have identified market opportunities opened up by Confidential Computing in pretty much any sector you can imagine, leveraging the capabilities of TEEs and the enabling power of attestation to do new things or existing things more securely.  Such organisations will need engineers ready to work closely with product and service teams to build applications and frameworks that require deep understanding of Confidential Computing and how it works in a specific engineering context.

Generalist

Where engineers within a CC-dedicated organisation need to work in a specific engineering context, the generalist area is one suited to those who want to help spread Confidential Computing more widely.  This sort of role will see people working either as an internal or independent consultant or as a part of a security team looking to help organisations extend their use of Confidential Computing to existing or new applications and services.  They may specialise in Confidential Computing technologies and how to apply them, or have them as part of their larger engineering, design or architectural armoury in the same way that experts in the use and application of cryptography might advise an engineering team on how to build security primitives into their component or how on how to apply cryptographic protocols to a larger system.  In either case, technologists following this path are likely to encounter a variety of different applications of Confidential Computing and will need to be able to apply the appropriate primitives, tools and techniques to the job in hand.

Conclusion

As Confidential Computing becomes more established as a “must-have” technology and the ecosystem continues to expand, we will continue to build a talent base of expert engineers. Whether your interests lie in research, design, engineering or operations, there will be opportunities to find rewarding careers in Confidential Computing.

AI, blockchain and security – huh? Ahh!

There’s a place for the security community to be more involved AI and blockchain.

Next week, I’m flying to the US on Tuesday, heading back on Thursday evening, arriving back in Heathrow on Friday morning, and heading (hopefully after a shower) to Cyber Security & Cloud Expo Global to present a session and then, later in the afternoon, to participate in a panel.  One of the reasons that I’m bothering to post this here is that I have a feeling that I’m going to be quite tired by the end of Friday, and it’s probably a good idea to get at least a few thoughts in order for the panel session up front[1].  This is particularly the case as there’s some holiday happening between now and then, and if I’m lucky, I’ll be able to forget about everything work-related in the meantime.

The panel has an interesting title.  It’s “How artificial intelligence and blockchain are the battlegrounds for the next security wars“.  You could say that this is buzzwordy attempt to shoehorn security into a session about two unrelated topics, but the more I think about it, the more I’m glad that the organisers have put this together.  It seems to me that although AI and blockchain are huge topics, have their own conference circuits[2] and garner huge amounts of interest from the press, there’s a danger that people whose main job and professional focus is security won’t be the most engaged in this debate.  To turn that around a bit, what I mean is that although there are people within the AI and blockchain communities considering security, I think that there’s a place for people within the security community to be more involved in considering AI and blockchain.

AI and security

“What?” you may say.  “Have you not noticed all of the AI-enabled products being sold by vendors in the security community?”

To which I reply, “pfft.”

It would be rude[3] to suggest that none of those security products have any “Artificial Intelligence” actually anywhere near them.  However, it seems to me (and I’m not alone) that most of those products are actually employing much more basic algorithms which are more accurately portrayed as “Machine Learning”.  And that’s if we’re being generous.

More importantly, however, I think that what’s really important to discuss here is security in a world where AI (or, OK, ML) is the key element of a product or service, or in a world where AI/ML is a defining feature of how we live at least part of our world.  In other words, what’s the impact of security when we have self-driving cars, AI-led hiring practices and fewer medical professionals performing examinations and diagnoses?  What does “the next battleground” mean in this context?  Are we fighting to keep these systems from overstepping their mark, or fighting to stop malicious actors from compromising or suborning them to their ends?  I don’t know, and that’s part of why I’m looking forward to my involvement on the panel.

Blockchain and security

Blockchain is the other piece, of course, and there are lots of areas for us to consider here, too.  Three that spring to my mind are:

Whether you believe that blockchain(s) is(are) going to take over the world or not, it’s a vastly compelling topic, and I think it’s important for it to be discussed outside its “hype bubble” in the context of a security conference.

Conclusion

While I’m disappointed that I’m not going to be able to see some of the other interesting folks speaking at different times of the conference, I’m rather looking forward to the day that I will be there.  I’m also somewhat relieved to have been able to use this article to consider some of the points that I suspect – and hope! – will be brought up in the panel.  As always, I welcome comments and thoughts around areas that I might not have considered (or just missed out).  And last, I’d be very happy to meet you at the conference if you’re attending.

1 – I’ve already created the slides for the talk, I’m pleased to say.

2 – my, do they have their own conference circuits…

3 – not to mention possibly actionable.  And possibly even incorrect.