| Encryption stage | What it protects | Confidential computing needed? |
|---|---|---|
| Data at rest (disk, database) | Stored data from theft of physical media or storage-level breach | No, standard disk/database encryption covers this |
| Data in transit (network) | Data moving between systems from network interception | No, TLS and VPNs cover this |
| Data in use (active computation) | Data while a CPU is actively processing it in memory | Yes, this is precisely the gap confidential computing closes |
For roughly three decades, the encryption industry solved two-thirds of the data protection problem extremely well. Data at rest gets encrypted on disk. Data in transit gets encrypted with TLS. But the moment data needs to actually be computed on — decrypted into memory so a CPU can read and manipulate it — it has historically been exposed in plaintext to anyone with sufficient access to the machine: a malicious cloud administrator, a compromised hypervisor, a rogue insider with root access, or an attacker who has broken into the host operating system. Confidential computing is the set of hardware technologies built specifically to close that gap, and by 2026 it has moved from a niche security feature to a standard offering across every major cloud provider.
This explainer walks through what a trusted execution environment actually is, how the major hardware implementations differ, what remote attestation does and why it is the piece that makes the whole model trustworthy, and where confidential computing is genuinely deployed in production today.
What a trusted execution environment actually is
A trusted execution environment, or TEE, is an isolated region of a processor where code and data are protected from everything outside that region, including the operating system, the hypervisor, and anyone with physical access to the machine. The isolation is enforced by the CPU itself, using a combination of memory encryption, access control checks built into the silicon, and cryptographic measurement of the code running inside. The core promise is this: even if the entire software stack surrounding the TEE is compromised, including the operating system kernel and the hypervisor, the data and code inside the TEE remain confidential and tamper-evident.
This matters enormously for cloud computing specifically, because the traditional cloud trust model requires you to trust your cloud provider’s administrators, their patching discipline, their hypervisor security, and their supply chain, all at once. A TEE moves the root of trust from “trust the cloud provider’s entire software stack” to “trust the hardware vendor’s chip,” which is a meaningfully smaller and more auditable trust boundary.
Two generations of TEE design
Early TEE designs, most notably Intel SGX, introduced fine-grained, process-level isolation called enclaves. A developer would carve out a specific region of an application, the enclave, and only that carved-out code and data received hardware protection. This gave very precise control over what was protected, but it also meant existing applications had to be substantially rewritten to work inside an enclave, which limited adoption significantly. SGX’s complex development model and software compatibility limitations became the primary criticism of the first generation of confidential computing.
The second generation of TEEs, including Intel TDX, AMD SEV-SNP, and ARM CCA, shifted the isolation boundary up to the level of an entire virtual machine. Instead of protecting a small carved-out enclave inside an application, these technologies protect an entire guest operating system and every unmodified application running inside it. This is the design that unlocked mainstream cloud adoption, because it means an existing application can often run inside a confidential VM with little or no code modification.
| Technology | Vendor | Isolation granularity | Introduced |
|---|---|---|---|
| SGX (Software Guard Extensions) | Intel | Process-level enclave | 2015 |
| SEV / SEV-ES / SEV-SNP | AMD | Full virtual machine | 2016 onward, SEV-SNP added encrypted state and integrity protection |
| TDX (Trust Domain Extensions) | Intel | Full virtual machine (Trust Domain) | May 2021 |
| CCA (Confidential Compute Architecture) | ARM | Full virtual machine (Realm) | 2021 architecture announcement |
How a confidential virtual machine isolates a workload from its own host
In an Intel TDX deployment, the CPU creates a Trust Domain, a hardware-isolated virtual machine whose memory is encrypted with a key the hypervisor never sees. Even the cloud provider’s own virtual machine manager, which controls scheduling and resource allocation for the Trust Domain, cannot read its memory contents or tamper with its execution undetected, because CPU-enforced integrity checks would reveal any tampering attempt.
Remote attestation: how a client knows the enclave is real
Isolation alone is not enough. A TEE that nobody can verify is just a locked room — you have no way of knowing whether the code actually running inside it is the code you intended to run, on genuine hardware, in an unmodified configuration. Remote attestation solves this by allowing the TEE to produce a signed, cryptographic proof of exactly what code and configuration are running inside it, which a remote party can verify before trusting the enclave with any sensitive data.
The attestation process generally works like this: the hardware manufacturer embeds a unique attestation key into each chip during manufacturing, protected by the same hardware root of trust as the TEE itself. When a client wants to verify a TEE before sending it sensitive data, the TEE generates a “quote” — a signed report containing a cryptographic measurement (essentially a hash) of the exact code and initial data loaded into the enclave, along with information about the hardware and firmware state. The client sends this quote to a verification service, typically operated by the hardware vendor, which checks the signature chain back to a trusted hardware root and confirms the measurement matches an expected, approved value. Only after this verification succeeds does the client establish a secure channel directly into the enclave and release sensitive data to it.
Why attestation is the piece that makes the trust model work
- Without attestation, a client has no cryptographic way to distinguish a genuine, correctly configured enclave from a compromised or spoofed one.
- Attestation lets a client verify not just that a TEE exists, but exactly which version of the code is running inside it, which enables use cases like verifiable confidential AI inference where the client needs proof a specific, audited model is what actually processed their data.
- Attestation reports are typically time-bound and tied to a specific session, preventing replay of an old attestation to vouch for a different, potentially compromised session.
Common mistake
Teams frequently treat “we deployed our workload inside a TEE” as equivalent to “our data is protected,” without ever implementing or verifying the remote attestation step. An enclave with no attestation check is still isolated from casual snooping, but a client connecting to it has no cryptographic guarantee that the enclave is running the expected code on genuine hardware rather than a compromised or emulated environment. Skipping attestation quietly discards most of the actual security benefit confidential computing is supposed to provide.
Where confidential computing is deployed in production today
By 2026, confidential computing has moved well past hardware demonstrations into standard cloud service offerings from every major provider, and the driving use cases fall into a few clear categories.
| Cloud provider | Offering | Typical use case |
|---|---|---|
| AWS | Nitro Enclaves | Isolating sensitive secrets and key material processing, such as cryptographic key handling and credential processing, from the rest of an EC2 instance |
| Microsoft Azure | Azure Confidential Computing (confidential VMs, confidential containers) | Regulated workloads in finance and healthcare, confidential multi-party data collaboration |
| Google Cloud | Confidential Space, Confidential VMs | Multi-party data clean rooms, confidential AI training and inference collaboration |
Concrete production use cases include processing of sensitive data such as credit card numbers, medical records, and cryptographic keys inside isolated environments where even the cloud operator cannot access the plaintext values. Healthcare and finance are the two industries most frequently cited as adoption drivers, because both face strict regulatory requirements around data handling and both increasingly want to unlock joint analytics value from sensitive data without exposing it to partner organizations or even to their own cloud provider.
A newer and fast-growing use case is confidential AI inference. As large language models are deployed at scale, running inference over sensitive prompts (medical questions, financial details, proprietary business data) inside an unprotected cloud environment creates real exposure. Composite attestation architectures that extend the trust chain across both the CPU TEE and the GPU, covering hardware like NVIDIA’s H100 and H200 confidential computing modes, allow an entire AI inference pipeline, from prompt to output, to run under verifiable hardware isolation. Reported inference throughput overhead for this composite CPU-plus-GPU confidential AI setup is in the range of roughly 1 to 7 percent, which is a strikingly small cost for the security guarantee it provides, compared to some other privacy-preserving computation techniques.
- Confidentiality plus integrityModern TEEs like SEV-SNP protect not just against reading memory contents but also against undetected tampering with them, a distinction that matters against active attackers, not just passive eavesdroppers.
- Attestation is the trust anchor, not the isolationIsolation keeps data private from outsiders; attestation is what lets an outsider verify the isolation is genuine before trusting it.
- VM-level TEEs unlocked mainstream adoptionThe shift from process-level enclaves (SGX) to full VM isolation (TDX, SEV-SNP, CCA) is what made confidential computing practical for existing, unmodified applications.
- GPU confidential computing is the newest frontierExtending attestation and isolation from the CPU to the GPU is what makes confidential AI inference over sensitive prompts possible at production scale.
- Side-channel risk never fully disappearsHardware-based isolation reduces but does not eliminate the risk of sophisticated side-channel attacks against the TEE itself, which is why ongoing security research and firmware patching remain essential.
- Trust shifts, it does not vanishConfidential computing moves the trust boundary from the cloud operator to the hardware vendor; it reduces the attack surface substantially but does not remove the need to trust someone.
What worked
Organizations that got real value from confidential computing typically started with a narrow, high-value workload where the trust story matters most, such as isolating a signing key or processing regulated healthcare data for a specific joint analytics project, implemented full remote attestation from day one rather than treating it as optional, and validated their threat model against what a TEE actually protects against (a compromised hypervisor or malicious cloud insider) rather than against unrelated threats like application-level bugs, which a TEE does not fix.
Recent security developments worth knowing about
Confidential computing is not a solved, static field, and staying current on its limitations matters. Security researchers have demonstrated attacks, sometimes called side-channel or physical attacks against TEE hardware, that in some cases have reconstructed private signing keys from recovered cryptographic nonces, which could in theory allow an attacker to forge valid attestation quotes and impersonate a genuine TEE. These findings do not mean confidential computing is broken as a category; they mean the security guarantees are tied to the current state of hardware and firmware, and organizations relying on TEEs need to keep firmware patched and stay current on vendor security advisories the same way they would for any other security-critical infrastructure component.
This is one reason confidential computing is often deployed alongside, rather than instead of, other cryptographic protections. Combining a TEE with strong key management practices supported by hardware security modules gives a layered defense where a single TEE side-channel finding does not immediately compromise the underlying cryptographic key material. Similarly, organizations pursuing broader confidentiality goals often combine confidential computing with techniques discussed in our explainer on fully homomorphic encryption and our piece on secure multi-party computation for cross-organization analytics, since each technique makes different trade-offs between performance and trust assumptions.
Confidential computing versus other privacy-preserving approaches
It is worth being precise about what confidential computing is and is not. It is not a replacement for encryption at rest and in transit, which remain necessary. It is not a substitute for good application security practices, since a TEE protects the confidentiality and integrity of the execution environment but does nothing to fix bugs, logic flaws, or vulnerabilities in the application code running inside it. It also does not remove the need for careful crypto-agility planning, since the cryptographic primitives used for attestation and memory encryption inside a TEE will themselves eventually need updating, including an eventual transition toward quantum-safe attestation signatures as part of a broader post-quantum cryptography migration. What confidential computing does uniquely well is close the “data in use” gap, providing hardware-enforced confidentiality and integrity for the moment data is actually being computed on, which neither traditional encryption nor application-level security controls address on their own.
Getting started: a practical adoption checklist
- Identify the narrowest workload with the highest trust sensitivity. Key management, credential processing, and regulated data analytics are common strong starting points.
- Choose VM-level TEEs over process-level enclaves unless you have a specific reason not to. TDX, SEV-SNP, and confidential VM offerings from major clouds require far less application rewriting than enclave-based SGX development.
- Implement remote attestation as a hard requirement, not an optional add-on. A TEE deployment without a verified attestation step in the client connection flow is providing substantially less security than it appears to.
- Plan for firmware and microcode updates as an ongoing operational responsibility. TEE security guarantees are tied to current hardware and firmware state, not a one-time configuration.
- Match the technology to the actual threat model. Confidential computing defends against a compromised host, hypervisor, or malicious cloud insider; it does not defend against a vulnerability in your own application logic.
Key Takeaways
- Confidential computing closes the “data in use” gap, protecting data while a CPU is actively processing it, which traditional at-rest and in-transit encryption do not cover.
- Trusted execution environments have evolved from process-level enclaves like Intel SGX to full virtual-machine isolation with Intel TDX, AMD SEV-SNP, and ARM CCA, which is what enabled mainstream cloud adoption.
- Remote attestation is the mechanism that lets a client cryptographically verify a TEE is genuine and running the expected code before trusting it with sensitive data; skipping it undermines most of the security benefit.
- All three major cloud providers now offer confidential computing as a standard service: AWS Nitro Enclaves, Azure Confidential Computing, and Google Confidential Space and Confidential VMs.
- Confidential AI inference, extending attestation across both CPU and GPU hardware, is a fast-growing use case with reported overhead as low as roughly 1 to 7 percent.
- Recent security research has found side-channel weaknesses in some TEE implementations, underscoring that firmware patching and vendor advisory monitoring remain essential ongoing practices.
- Confidential computing complements rather than replaces encryption at rest and in transit, application security practices, and other privacy-preserving computation techniques.
Glossary
- Trusted Execution Environment (TEE)
- An isolated region of a processor where code and data are protected from the operating system, hypervisor, and physical access to the machine, with isolation enforced directly by the CPU hardware.
- Enclave
- A process-level isolated region within a TEE, as implemented by technologies like Intel SGX, where only a specifically carved-out portion of an application receives hardware protection.
- Remote attestation
- The cryptographic process by which a TEE proves to a remote party exactly what code and configuration are running inside it, on genuine hardware, before that party trusts it with sensitive data.
- Quote
- A signed report generated by a TEE containing a cryptographic measurement of its running code and configuration, used as the core evidence in a remote attestation exchange.
- Trust Domain
- Intel TDX’s term for a hardware-isolated virtual machine whose memory is encrypted and integrity-protected from the host hypervisor and virtual machine manager.
FAQs
What problem does confidential computing actually solve?
It protects data while it is actively being processed in memory by a CPU, a gap traditional encryption misses since encryption at rest and in transit both require data to be decrypted into plaintext for computation. Confidential computing keeps that computation isolated from the operating system, hypervisor, and cloud operator.
What is the difference between Intel SGX and Intel TDX?
Intel SGX provides process-level enclave isolation, protecting only a specifically carved-out portion of an application, which requires significant code rewriting. Intel TDX provides full virtual-machine isolation, protecting an entire unmodified guest operating system and its applications, which requires far less application-level change.
What is remote attestation and why does it matter?
Remote attestation is the process by which a trusted execution environment cryptographically proves to a remote party what code it is running and that it is genuine hardware, before that party trusts it with sensitive data. Without attestation, a client has no way to verify the enclave has not been spoofed or tampered with.
Do all major cloud providers support confidential computing?
Yes. AWS offers Nitro Enclaves, Microsoft Azure offers Azure Confidential Computing including confidential virtual machines and containers, and Google Cloud offers Confidential Space and Confidential VMs, all as standard production services as of 2026.
Does confidential computing protect against all security threats?
No. It specifically protects data confidentiality and integrity during active computation against a compromised host, hypervisor, or malicious cloud insider. It does not fix vulnerabilities or logic flaws in the application code running inside the trusted execution environment.
How much performance overhead does confidential computing add?
Overhead varies by workload and hardware generation, but composite CPU-plus-GPU confidential AI inference setups have reported overhead as low as roughly 1 to 7 percent, which is dramatically lower than the overhead associated with alternative privacy-preserving computation techniques like fully homomorphic encryption.
Is confidential computing vulnerable to any known attacks?
Security researchers have demonstrated side-channel and physical attacks against some TEE implementations, in certain cases recovering private signing keys used for attestation. This underscores the need for ongoing firmware patching and vendor security advisory monitoring rather than treating a TEE deployment as permanently secure by default.
How is confidential computing different from fully homomorphic encryption?
Confidential computing relies on hardware-enforced isolation, trusting the chip vendor’s silicon and firmware, and runs with relatively low performance overhead. Fully homomorphic encryption protects data mathematically with no hardware trust assumption at all, but currently carries a much higher computational overhead, typically 100x or more versus plaintext processing.
References
- Microsoft Learn, “Trusted Execution Environment (TEE)”
- BleepingComputer, “TEE.Fail attack breaks confidential computing on Intel, AMD, NVIDIA CPUs”
- arXiv, “EnclaveX: End-to-End Confidential AI with CPU/GPU TEEs”
- eco.com, “Intel SGX vs AMD SEV vs ARM TrustZone”
- arXiv, “Flexible remote attestation of pre-SNP SEV VMs using SGX enclaves”
- arXiv, “Remote attestation of SEV-SNP confidential VMs using e-vTPMs”
- AppScale Blog, “Confidential Computing for AI Inference 2026: TEEs, Nitro Enclaves, NVIDIA H100/H200”
- decentriq.com, “What is confidential computing? Definition and use cases”
- oneuptime.com, “How to Use AWS Nitro Enclaves for Sensitive Data Processing”
