What Is Confidential Computing

Introduction

Encryption has long covered two of the three states of data: at rest (data on disk is encrypted with AES-256) and in transit (data over the network is protected by TLS). But the third state — data in use, while the CPU is actively processing it — has historically required trusting the entire software stack from the operating system up through the application. In a cloud environment — the exact case that confidential computing was invented to secure — that trust chain includes the cloud provider’s hypervisor, management plane, and the humans who operate the infrastructure. For many workloads — medical records, financial models, AI training on proprietary datasets, regulated financial data — that is an unacceptable exposure. Confidential computing closes this gap. By leveraging hardware-enforced memory encryption built into modern CPUs from Intel, AMD, and ARM, confidential computing lets workloads run in Trusted Execution Environments (TEEs) that the cloud provider, its hypervisor, and even its privileged administrators cannot read — even with physical access to the server. All three major cloud providers — AWS, Azure, and Google Cloud — now offer confidential computing instances, and the Confidential Computing Consortium, hosted by the Linux Foundation, is driving standards and tooling for the ecosystem.

What Is Confidential Computing?

Confidential computing is the hardware-based protection of data in use — ensuring that code and data are encrypted in CPU memory even from the operating system, hypervisor, and cloud provider. It extends the traditional “encrypt everything” security model to cover active computation, not just storage and transmission.

The enabling technology is the Trusted Execution Environment (TEE) — a hardware-isolated region of memory where the CPU enforces that only authorized code can access the contents. The CPU’s memory encryption engine encrypts all memory belonging to the TEE with keys that exist only inside the CPU package. Any attempt to read TEE memory from outside — including from the hypervisor, from a DMA-capable device, or by probing physical memory chips — yields only encrypted ciphertext.

TEEs also support remote attestation: a TEE can generate a cryptographically signed report containing the hash of its code and configuration, signed by a key that can only have been generated inside a genuine hardware TEE. A remote party can verify this report — via the CPU manufacturer’s attestation service — to confirm that specific, unmodified code is running in a real, hardware-isolated enclave before sending it sensitive data.

How Confidential Computing Works

The confidential computing workflow typically follows this pattern:

1. TEE instantiation: A CPU instruction creates a new TEE — such as a secure enclave in Intel SGX or an encrypted VM in AMD SEV-SNP. The CPU allocates memory for the TEE and generates an ephemeral encryption key for that region.
2. Code and data loading: The application or runtime loads code and initial data into the TEE. Each page is measured (hashed) as it is loaded, building a cumulative measurement of the enclave’s initial state.
3. Attestation: The TEE generates a signed attestation report containing the measurement of its loaded code, signed by the CPU’s hardware-rooted attestation key. A remote party (a key management service, a data provider, or an auditor) verifies the attestation report via the CPU manufacturer’s attestation service to confirm the code is what it claims to be and runs in a genuine TEE.
4. Secure key provisioning: After attestation succeeds, the remote party provisions decryption keys or sensitive data directly to the TEE’s encrypted memory. The TEE decrypts, processes, and re-encrypts the data — the plaintext never leaves the TEE’s hardware-isolated memory region.
5. Compute and output: The TEE performs its computation and produces results, which are encrypted before being written outside the enclave boundary.
6. TEE destruction: When the workload completes, the CPU destroys the TEE and the ephemeral encryption keys, leaving no recoverable plaintext in memory.

VIDEO · READY 16:9

PLAY

Confidential Computing and Trusted Execution Environments | Intel Technology

Intel SGX vs AMD SEV vs ARM TrustZone

Real-World Use Cases

Privacy-preserving machine learning: Training AI models on sensitive data — patient records, financial transactions, proprietary source code — has historically required the data owner to trust the model trainer completely. With confidential computing, the training computation runs inside a TEE. The data owner verifies via attestation that the correct, audited training code is running and that no data exfiltration path exists before releasing the data. This enables federated learning and collaborative ML across organizations that cannot legally share raw data.

Secure multi-party computation in the cloud: Multiple organizations can contribute encrypted datasets to a confidential computing workload that performs joint analysis — a joint fraud detection model between competing banks, for instance — without any party ever seeing another’s raw data. The TEE enforces that only the agreed computation runs on the combined data. This is complementary to the cryptographic approach described in the broader Zero-Knowledge cluster; see Zero-Knowledge Encryption: What It Is and How It Works for the mathematical side.

Regulatory isolation for cloud workloads: Industries subject to data residency and access control regulations — healthcare (HIPAA), financial services (PCI DSS), and government contracts (FedRAMP) — often cannot move sensitive workloads to public cloud because the cloud provider’s access constitutes a disclosure risk. Confidential computing instances, combined with attestation-based key management, allow these workloads to run in public cloud while giving compliance auditors verifiable proof that the cloud provider cannot access the data. For compliance context, see PCI DSS Compliance: What You Must Implement.

Common Mistakes to Avoid

Assuming the TEE eliminates all attack surfaces: TEEs protect against hypervisor and OS-level access, but they have their own attack surface. Intel SGX has been the subject of multiple serious academic attacks — Foreshadow (2018), Load Value Injection (LVI, 2020), and SGAxe (2020) — that exploited CPU microarchitectural behavior to leak enclave data. Confidential computing is a powerful tool, not a silver bullet. Always check the CPU’s firmware microcode version and apply available mitigations.

Forgetting to verify attestation before provisioning secrets: The security model of confidential computing depends entirely on verifying the attestation report before sending sensitive data into the TEE. Skipping or weakly implementing attestation verification — for example, trusting the enclave’s own report of its code hash without checking it against an expected value — completely defeats the purpose. Attestation verification must be implemented at the data-provisioning side, not just trusted on the TEE side.

Treating TEE memory limits as fixed: Intel SGX originally limited enclave memory to 128 MB (the Enclave Page Cache). Workloads that exceed this size incur expensive page swapping that can degrade performance by 10×. SGX2 and newer hardware increase this, but you must architect your application with memory constraints in mind. AMD SEV has no such limit — the entire VM memory is encrypted.

Ignoring side-channel attacks within the TEE boundary: Even inside a TEE, code that is not written to be constant-time can leak information through cache timing — the same risk described in Side-Channel Attacks Explained. The TEE boundary protects against external reads of memory, but internal timing behavior is still observable by a co-located attacker through shared CPU resources.

Getting Started

To explore confidential computing for your workloads:

First, identify your highest-risk computation. Confidential computing is most valuable for code that processes sensitive data that you currently cannot run in cloud environments due to trust concerns. AI inference on regulated medical data, cryptographic key processing, and multi-party data analysis are prime candidates.

Second, choose the right TEE technology for your workload size. For small, high-security workloads (key management, authentication services) where a full rewrite is feasible, Intel SGX with the Open Enclave SDK or Gramine library OS is a mature choice. For lifting existing Linux workloads into the cloud with minimal changes, AMD SEV-SNP VMs (available on Azure DCasv5 and Google Cloud C2D) require only a confidential-VM-enabled guest OS.

Third, implement attestation rigorously. Use a hardware-rooted attestation service — Intel’s DCAP, AMD’s KDS, or a cloud-managed attestation service like AWS Nitro Attestation, Azure Attestation Service, or GCP Confidential Space — and verify the TEE’s measurement against a known-good reference value before provisioning any secrets. Never ship code that skips attestation in production.

Fourth, plan for a defense-in-depth architecture. Combine confidential computing with encryption at rest, key management services, and network isolation. TEEs protect the computation; the surrounding infrastructure must still be hardened. Confidential computing is one layer in a complete security architecture, not a replacement for it.