Tag: business

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.

In praise of triage

It’s all too easy to prioritise based on the “golfing test”.

Not all bugs are created equal.

Some bugs need fixing now, some bugs can wait. Some bugs are in your implementation, some are in the underlying design. Some bugs will annoy a few customers, some will destroy your business.

Bugs come in all shapes and sizes, and one of the tasks of a product owner, product manager, chief architect – whoever makes the call about where to assign resources – is to decide which ones to address in which order: to prioritise them. The problem is deciding how to prioritise them. It’s all too easy to prioritise based on the “golfing test”: your CEO meets someone on golf course who mentions that his or her company loves your product, except for one tiny issue. The CEO comes back, and makes it clear that fixing this “major bug” is now your one and only task until it’s done, and your world is turned upside down. You have to fix the bug as quickly as possible, with no thought to the impact it has on the rest of the project, or the immense pile technical debt that’s just been accrued. You don’t want to live in this world. What, then, is the alternative?

The answer – though it’s only the beginning of the answer – is triage. Triage (from the French for “separating out”) comes from the world of battlefield medicine. When deciding which wounded soldiers to treat, rapid (hopefully objective) assessments are carried out, allowing a quick sorting of each soldier, typically into categories such as “not urgent: wait”, “urgent: treat immediately” and “not saveable: do not treat”. We can apply the same to software bugs in order to decide what to treat (fix) and with what priority. The important thing is not so much the categories – which will vary based on your context – but the assessment criteria, and how they are applied. Here are a list of just some of the possible criteria:

  • likely monetary impact per customer
  • number of customers impacted
  • reputational impact on your organisation
  • ease to fix
  • impact on system security
  • impact on system performance
  • impact on system stability
  • annoyance of CEO not to be listened to.

We do not, of course, only need to apply one of these: a number of them can be combined with a weighting system, though the more you add, the less clear your priorities will be, and the more likely it is that someone will “put a finger on the scales” – tweak the numbers to give the outcome they want. Another important point about the categories that you decide to apply is that they should be as measurable as you can make them, to allow as objective scoring as possible. I wrote a review of the book Building Evolutionary Architectures a while ago: the methodology adopted there, where you measure and test in order to meet specific criteria, is exactly the sort of approach you should be choosing when designing your triage system.

This is (ostensibly) a blog about security, and so you might expect me to say that “security always wins”, but that should absolutely not be the approach you take. Security might be the most important category for you (that is, carry the most weight), but you need to understand why that is the case – at this particular time – and what exactly you mean by “security”. The “security of the system” is not an objective measure: in order to mean anything, such a phrase needs to reference measurements that can be made (“resistance to physical tampering”, “resistance to brute force attacks”, “number or PhD students likely to be needed to reverse engineer our ‘secure’ protocol”[1]). More importantly, it may be that at this point in your organisation’s life, the damage done by lack of stability or decreased performance outweighs the impact of a security bug. If that’s the case, then your measurements should encapsulate that information and lead you to prioritise bugs with impact in these categories over security issues[3].

There’s one proviso that I feel I need to put in at this point, and it’s about the power of what, in Agile Methodology terms, is called the Product Owner. This is the person who represents the users of the product/project, and should have final say about the direction of development in terms of features, functionality and, most relevant in this discussion, bug-fixing. As noted above, this may be an architect, product manager or someone enjoying another title, but their role should be clear: they get to call the shots. There are times when this person goes against the evidence provided by the triage, and makes a decision to prioritise a particular bug over others despite the outcome of the measurements. This is typically very painful for the technical team[4], but, when it comes down to it, as the product owner, they get to decide. The technical team – after appropriate warnings and discussion[5] – must be ready to step aside and accept the decision. Such decisions (and related discussions) should be recorded, and the product owner must be ready to stand or fall based on the outcome, but that is their job. Triage is a guide, and there are occasions when there are measurements which cannot be easily made objectively, and which sit outside the expertise or scope of knowledge of the technical team. If this sort of decision keeps being made, and you think you know better, you may have a future in technical product management, where people with a view of both the technical and the business side of technology are much in demand. In the end, though, the product owner will need to justify their decision to management, and if they get it wrong, then they must be ready to take the blame (this is one reason why you should make sure that you’ve recorded the process taken to get to this decision – you don’t want to take the blame for a poor decision which you advised against).

So: go out an design a triage process, be ready to follow it, and be ready to defend it. Oh, and one last point: you might want to buy a set of golf clubs.

—–

1 – this last one is a joke: don’t design your own protocol, or if you do, make it open and have it peer-reviewed[2].

2 – and then throw it away and use an open source implementation of better, more thoroughly-reviewed one.

3 – much as it pains me to say it.

4 – I’ve been on both sides of these decisions: I know.

5 -often rather heated, in my experience.