10 years of Confidential Computing at Fortanix

Over the past decade, Confidential Computing has grown from a niche processor feature into an industry. The next ten years will make it the security standard.

In 2018, I explained why Fortanix chose Intel SGX. It was “not only the best choice for our Runtime Encryption® platform, but also currently the only choice”. The post also left the door open: “In the future, it’s entirely possible that Runtime Encryption® will be made available on other platforms that are sufficiently secure.”

You won’t find the words Confidential Computing anywhere in that post. Fortanix had been building it since its founding in 2016, before the term was coined. When the post was published, the term was less than a year old and still closely tied to Microsoft’s Azure offering.

Today, the name is everywhere, and SGX is no longer the only choice. Intel, AMD and Arm have each defined a Confidential Computing architecture, NVIDIA builds the technology into its data center GPUs, and every major cloud provider will rent it to you.

Yet misconceptions that were understandable a decade ago are still widespread, many deployments leave part of the hardware’s protection unused, and some genuine gaps remain.

This post looks back at how the ecosystem took shape, the myths that grew up around it and the limits of what it can do, before looking ahead to the next ten years.

How the Ecosystem Took Shape

Intel announced Software Guard Extensions (SGX) at the HASP workshop on June 23, 2013. Two years later, it shipped in Skylake processors. SGX let applications run in enclaves that neither the operating system nor the hypervisor can see into.

In the same year Fortanix was founded, AMD announced Secure Encrypted Virtualization (SEV) on April 21. Rather than protecting part of an application, SEV aimed to protect an entire virtual machine. It only became a credible option with SEV-SNP (Secure Nested Paging), which AMD described in January 2020 and shipped in its 3rd Gen EPYC (Milan) processors in March 2021. Intel and Arm later followed suit with Trust Domain Extensions (TDX) and the Confidential Compute Architecture (CCA) respectively.

On September 14, 2017, Microsoft Azure CTO Mark Russinovich gave the field its name.

Cloud offerings soon followed. Azure’s SGX-based DC-series virtual machines entered public preview on October 10, 2018. AWS went its own way with Nitro Enclaves, announced on December 3, 2019 and generally available from October 28, 2020. IBM Cloud was also quick to support SGX, while Google Cloud only arrived in earnest once SEV-SNP and TDX hardware became available.

The next major step came from outside the CPU. On March 22, 2022, NVIDIA unveiled its Hopper GPU architecture, with Confidential Computing as a headline feature.

In under a decade, one vendor’s instruction set extension had become an ecosystem spanning CPUs, GPUs and every major cloud.

Drawing the Line

On paper, these technologies all promise the same thing. Code and data stay protected while they’re being processed, and a remote party can verify exactly what is running before trusting it with anything.

In practice, each one draws the line between trusted and untrusted in a different place. Where that line falls determines how much you still have to trust, and how much work it takes to adopt the technology.

SGX draws the line as tightly as possible. An SGX enclave is a protected region inside an ordinary application, shielded from the operating system, the hypervisor, the firmware and whoever operates the machine. Very little remains in the trusted computing base (TCB) besides the processor and the enclave’s own code.

Confidential virtual machines enable moving the line outward. Intel TDX, AMD SEV-SNP, Arm CCA and AWS Nitro Enclaves all protect an entire virtual machine, and everything inside it becomes part of the TCB. A full guest operating system adds a lot of code, but a confidential VM can also be stripped down to little more than the application itself, bringing the TCB much closer to that of an SGX enclave.

Co-processors such as GPUs stretch the line across devices. Once a GPU joins a confidential VM, the TCB includes hardware from more than one vendor, each with its own firmware, update process and root of attestation. A weakness in any of them is a weakness in the whole system, and the number of parties you trust has gone up.

Historically, the precision of SGX and other application-level enclaves came at the developer’s expense. Every application had to be split into a part that runs inside the enclave and a part that doesn’t, and each part had to be built for its side of the boundary. Toolchains such as the Fortanix Enclave Development Platform and lift-and-shift approaches such as Fortanix EnclaveOS have since taken much of that work off developers’ hands.

Confidential VMs can run existing software with far less rework, but rarely completely unmodified. The guest operating system needs support for the technology, and secrets should only be released once the VM has proven what it’s running. The boot chain and disk encryption need careful setup so that what was measured is what actually runs, and I/O needs special handling because devices can’t read the VM’s encrypted memory.

Either way, adopting Confidential Computing is a design decision rather than a configuration setting. It moves the trust boundary of the whole system, not just of one workload. When done well, the payoff of buying into this paradigm is twofold. Whoever runs the infrastructure, or the service, loses access to your data, and security becomes something you verify rather than assume.

Behind the Line

Where the line is drawn is only part of the story, because the implementations behind it differ too.

SGX has the longest track record, having been generally available since 2015. Years of scrutiny by security researchers have tested it thoroughly. Intel also publishes machine-readable information on which platform versions are up to date, so verifiers can check it automatically.

Among TDX, SEV-SNP and CCA, the architectural differences are smaller than you might expect. What sets them apart is maturity, how well attestation works in practice and whether you can actually buy the hardware.

TDX arrived well after SEV-SNP, but it didn’t start from scratch. It inherits much of the maturity of SGX, including its attestation infrastructure.

Maturity is where AMD has had the most ground to make up. SEV-ES (Encrypted State) and SEV-SNP each had to fix weaknesses left behind by their predecessor. The missing integrity protections, which I already pointed out in 2018, only arrived with SEV-SNP. The design has come a long way since, although some gaps remain.

Operating SEV-SNP securely is also harder than it should be. AMD doesn’t publish reference values in machine-readable format. These are the minimum firmware versions a verifier should accept, and attestation verifiers have to piece them together by hand from AMD’s security advisories. Security fixes are slow to arrive as well. AMD’s advisories can appear years after a vulnerability was reported, which shows how long it takes to develop and roll out fixes.

Arm raises a different question entirely. Arm designs the architecture, but other companies make the chips, so every chip maker that adopts CCA implements it independently. With Intel or AMD, a single company stands behind both the hardware and the attestation infrastructure. With CCA, that responsibility is spread across every chip maker. Relying parties have to trust whichever of them built the hardware their workloads run on, and verifiers have to support each one’s attestation infrastructure. And for now, hardware that actually supports CCA remains hard to find.

Nitro Enclaves take yet another approach: each enclave is carved out of a regular EC2 instance, with the Nitro Hypervisor enforcing the isolation and AWS signing the attestation. That’s a meaningful layer of protection, but unlike the other technologies here, it doesn’t take the infrastructure provider out of the picture. It’s a bit like the safe in a hotel room: it keeps out anyone else who gets into your room, but the hotel can still open it. If the infrastructure provider is part of your threat model, AWS Nitro doesn’t protect you from it.

Rather than bringing a confidential environment of their own, GPUs extend an existing one. An NVIDIA GPU in Confidential Computing mode is attached to a confidential VM on the CPU, and data moving between the two is encrypted, as is traffic between GPUs on newer generations. The GPU’s attestation is rooted in NVIDIA and has to be verified alongside the confidential VM’s. Fortanix Confidential Computing Manager (CCM) can check the two together as a single, composite attestation.

From Keys to Inference

Each step in the ecosystem’s evolution opened up new use cases.

Application-level enclaves were a natural fit for small, high-value secrets on machines you don’t control, which made key management the obvious first use case. Privacy-preserving services followed: as early as 2017, Signal used SGX to let users find out which of their contacts are on Signal without revealing their address books to Signal’s servers.

Confidential VMs could handle larger and more general workloads. That made data clean rooms and data sharing practical: several parties pool sensitive data for a joint analysis without any of them, or the infrastructure provider, seeing the others’ raw inputs. Research hospitals can combine patient data to study rare diseases, for example, without handing their patients’ records to each other.

For most of its history, Confidential Computing stopped at the CPU, even as AI moved the most valuable data onto GPUs. GPU support closed that gap: secure inference keeps prompts, results and model weights hidden from the infrastructure. That lets organizations run hosted models on financial data or legal documents without exposing either to the provider. Unlike the earlier examples, secure inference isn’t tied to a single domain. It applies wherever AI is used, and with AI adoption growing as quickly as it is, this use case will scale up quickly.

The Gaps That Remain

Support has spread through every layer of infrastructure, from processors and servers to operating systems, hypervisors and cloud services, but it isn’t universal. On GPUs, Confidential Computing is effectively limited to NVIDIA, and smaller GPUs are largely left out.

A more fundamental problem lies with the cloud providers.

One of the core purposes of Confidential Computing is to remove the infrastructure provider from the TCB, yet many cloud providers manage to re-insert themselves. The provider can reappear in several places: virtual machine firmware that customers can’t inspect, a paravisor it supplies inside the trust boundary, or an attestation service it operates itself. A single offering may well do all three. These components are often mandatory, and the provider can change them at any time, in ways relying parties can’t practically audit.

Every one of these components means trusting the provider again. Since Confidential Computing normally limits your trust to the hardware vendor and whatever you put inside the boundary, the most important question when evaluating an offering is a simple one: who, exactly, are you still trusting?

Coordinated vulnerability disclosure has a similar blind spot, because it wasn’t designed with Confidential Computing in mind. It gives cloud providers and others who deploy fixes early warning, so that users are already protected when a vulnerability becomes public. In the Confidential Computing threat model, however, those are exactly the parties you’re defending against. Warning the infrastructure provider about a flaw in the very protection meant to keep it out, while relying parties hear nothing, turns the process on its head. Disclosure practices need to change to reflect who the adversary actually is.

Growing Awareness, Persistent Myths

Awareness of Confidential Computing has grown enormously over the past ten years, and so have the misconceptions. Most of them fall apart on closer inspection.

“It will slow us down”

Performance is one of the most common concerns, and one of the least examined.

The latest numbers are hard to argue with. NVIDIA has measured inference performance twice this year: DeepSeek-R1 on a DGX B200 system, and Qwen 3.5 on HGX B300 with the traffic between GPUs encrypted as well. With Confidential Computing enabled, the overhead stayed in the single digits, between roughly 1% and 8% depending on load.

That’s a small price to pay for keeping prompts, data and model weights protected wherever inference runs.

“It’s too expensive”

Confidential Computing isn’t free, since cloud infrastructure that supports it can cost more and building a deployment properly takes engineering effort.

But the price tag is only half of the equation. With the built-in security mechanisms keeping infrastructure operators away from your data, least privilege no longer depends on policy alone, and many of the controls designed around those operators become far less critical. Implemented well, it reduces how much security you have to build elsewhere, and that’s where the savings are.

“Our data isn’t that sensitive”

It’s tempting to see Confidential Computing as overkill: appropriate for banks and governments, perhaps, but not for everyday data.

Think about what happens at a car rental counter: the clerk scans your driver’s license, and you probably don’t give it a second thought. In September 2026, it came to light that an identity theft service was selling scans of more than 153 million U.S. and Canadian driver’s licenses, complete with infrared and ultraviolet images. The scans were traced to IDScan.net, an identity verification service used at rental counters and dispensaries. According to the sellers, they had been “continuously exfiltrating new data for over a year.”

A single scan seems harmless, but pooled by the hundreds of millions, those scans are raw material for identity fraud. The problem is only growing, as AI drives a steep rise both in how much sensitive data gets processed and in how many vulnerabilities are found, while conventional defenses fail to keep up. With Confidential Computing, data like this is only ever decrypted inside environments that have proven what they’re running.

“It’s security theater”

At the other end of the spectrum are the skeptics, who see Confidential Computing as security theater. A steady stream of side-channel research over the past decade has helped reinforce that view.

A sufficiently determined or well-funded attacker can breach anything, Confidential Computing included. Yet no major data breach has been publicly attributed to a side-channel attack on it. A fairer test is to ask what the technology would have stopped in practice, and two well-known breaches make the point.

In 2022, attackers compromised the computer of a senior LastPass DevOps engineer. From there, they obtained the secrets that unlocked LastPass’s cloud backup storage, including a decryption key that was stored separately. Had those secrets been released only to attested workloads, and never to individual employees, compromising one engineer’s computer wouldn’t have been enough.

In 2023, a China-based threat actor that Microsoft tracks as Storm-0558 used a stolen Microsoft signing key to forge authentication tokens, giving it access to email accounts at U.S. government agencies, among others. Microsoft’s investigation points to operational errors that let the key leave its secure signing environment, after which the attacker accessed it in a debugging environment through a compromised engineering account. Confidential Computing would most likely have prevented this, because a key that never leaves an enclave can’t end up in a debugging environment.

Neither attack defeated any cryptography. Both succeeded because critical secrets were available in plaintext to people and systems that should never have held them, at services whose users had no choice but to trust them. That is precisely the problem Confidential Computing is designed to solve.

“It isn’t ready yet”

Then there’s the view that the technology works but isn’t mature enough yet.

Confidential Computing has been running production workloads for nearly a decade. Current server processors, data center GPUs and mainstream Linux distributions all support it, as do the major cloud providers. Attestation has a common framework too: the IETF’s Remote Attestation Procedures architecture.

Whether the technology is ready is no longer in doubt. The question now is whether you are ready for it.

“It’s just a switch”

The opposite mistake is to treat Confidential Computing as a box to tick: switch on a confidential VM, note it in the compliance report and move on.

Like any security technology, it only delivers when it’s implemented and configured correctly. Get either wrong, and the protection quietly disappears. It’s like installing a firewall appliance without configuring any policies: the hardware is in place, but it doesn’t block anything.

Two things matter above all. The first is attestation: the platform’s assurances only mean something if you verify what is running, and on what infrastructure.

The second is removing administrative access: a confidential VM that your operations team can still log into does keep the cloud provider out, but still lets anyone who compromises an administrator’s account in.

Just as Confidential Computing isn’t a checkbox for the people using it, neither is it one for the providers offering it. For cloud providers, it takes more than enabling TDX or SEV-SNP in their hypervisors. Offering Confidential Computing is a conscious commitment, and customers rightly expect it to be kept: platforms configured properly, and firmware and microcode updated promptly as security fixes are released. The same holds for software-as-a-service (SaaS) providers that advertise Confidential Computing but keep administrative access to their services. Fortanix architected its own SaaS from the ground up so that its operators never have that kind of access.

Knowing the Limits

Being clear about what Confidential Computing doesn’t do matters as much as understanding what it does.

Confidential Computing isn’t a sandboxing technology. The protection runs in one direction: it keeps the platform out of the workload, not the workload out of the platform. Containing a hostile workload is a different problem, solved by different tools.

Attestation can’t vouch for the code itself. It proves which code is running, not whether that code is any good, so a vulnerable or malicious application enjoys exactly the same protection as a well-written one. What runs inside the trust boundary also needs to be well defined and well behaved, because if an administrator can change the application’s behavior, the attestation no longer describes what actually runs. That’s one more reason to keep that code small, and to build it with the same care as any other security-critical software.

Other security controls are still needed. Confidential Computing protects data while it’s being processed, and only inside the boundary. Data at rest and in transit needs encrypting as before, keys need managing, and the application has to authenticate its users and defend its network interfaces like any other. Data at rest needs particular care, because the infrastructure still controls the storage. It can hand back stale copies of encrypted data, and it can learn a surprising amount from which data is accessed and when. What changes is how those controls fit together: disk encryption keys and TLS private keys can be released only to attested workloads, out of reach of whoever runs the infrastructure. That doesn’t make the rest of the security stack obsolete, but it does considerably reduce how much weight it has to carry.

Physical attacks are out of scope. The original SGX threat model did defend against physical attacks, but Intel later walked back those protections. Since then, all designs from Intel and other vendors have followed this weaker model. In practice, Confidential Computing removes the cloud provider’s software from the TCB, but not the people who can walk up to its servers, or anyone in the hardware supply chain who handled those servers before they got there. Blockchain projects that relied on enclaves to keep keys from node operators were on shaky ground for exactly this reason, since those operators have physical access to their own machines. Until the hardware defends against physical attacks again, physical security still matters.

Looking Ahead to 2036

I’ve long held that anything running on infrastructure you can’t fully trust belongs in Confidential Computing. Seen from the perspective of whoever owns the data, that covers practically all software as a service. From government ID checks to AI inference, users today simply have to take a provider’s word for how their data is handled. Over the next ten years, that principle will go from ambition to default.

You’ll know it has happened when nobody thinks to ask whether Confidential Computing is switched on.

The web has been through a transition like this before. HTTPS was once reserved for login pages and checkout forms, with certificate authorities confirming that a site’s operator controls its domain. It became universal once certificates were free and issued automatically, and once browsers started warning users about unencrypted sites. Today, a site without it looks broken.

Attestation will follow the same path. An attestation service such as Fortanix CCM confirms something richer than a certificate: that an application is the one you expect, that it comes from a party you trust and that the platform it runs on is genuine and up to date. As attestation becomes automatic, invisible and expected, clients will start refusing to hand sensitive data to any service that can’t prove what it’s running.

AI will also change the economics of software security. It has already driven a sharp rise in the number of vulnerabilities being discovered, and that trend will only accelerate. When flaws are found faster than they can be fixed, limiting what an attacker can reach becomes the most effective defense. That’s exactly what Confidential Computing does, by shrinking the set of components you have to trust and keeping data encrypted for more of its life.

Much has been made of workloads moving to the public cloud and, more recently, back into private data centers, but that back-and-forth is small next to how much data now lives with SaaS providers. Regardless of where the infrastructure resides, least privilege should apply: its operators have no business seeing the data it processes, and the infrastructure itself may have been compromised. Confidential Computing will become standard on-premises just as much as in the cloud.

The edge is where the technology has lost the most ground. SGX first appeared in client processors, and Intel later removed it from them. As more sensitive processing moves out of the data center and closer to users, that trend will reverse.

Regulation will follow, too, and within the decade, protecting data while it’s in use will join encryption at rest and in transit on the list of what regulators expect.

Getting There

None of this will happen on its own.

SaaS providers have the most to gain. By running their services in Confidential Computing and designing out administrative access, they make it possible for customers to verify how their data is handled instead of having to take it on trust.

Cloud providers, in turn, need to provide a platform worth building on. That goes for the traditional hyperscalers and the newer, GPU-focused neoclouds alike. They need to step out of the TCB of the confidential services they sell, and offer those services on every instance type and in every region. They also need to get far more serious about vulnerability patching, because an unpatched platform leaves their customers’ workloads, and everyone relying on those workloads, exposed to every vulnerability that has already been disclosed.

Hardware vendors need to make Confidential Computing available in every market where sensitive data is processed, from the cloud to the edge, and bring physical attacks back into scope. They also need to rework their disclosure processes so that relying parties aren’t the last to know.

Everyone else has a part to play as well. Ask your providers for Confidential Computing, verify attestation and close off administrative access to your confidential workloads.

Ten years ago, the question people asked was what an enclave is. Today, they ask why anyone would bother running in one. Ten years from now, the question should be why anyone wouldn’t.