Confidential Computing Guide: TEEs and Attestation

Encryption at rest and in transit stops at the moment data is processed: in memory, it is readable by the hypervisor, the host operating system and anyone who controls them. Confidential computing closes that gap by running workloads inside hardware trusted execution environments (TEEs) whose memory the host cannot read, and by proving to a remote party, through attestation, exactly what is running before secrets are released to it. This guide compares Intel SGX, Intel TDX, AMD SEV-SNP, Arm CCA, AWS Nitro Enclaves and NVIDIA GPU TEEs, explains confidential VMs and containers in the major clouds, walks through remote attestation using the RFC 9334 architecture and key release on attestation, and is candid about the threat model's limits. It is for security architects, cloud platform teams and the people approving sensitive AI and data-sharing workloads.

Key takeaways

Attestation is the control, not encryption: memory encryption without a verified attestation only tells you a TEE might exist; key release bound to attested measurements is what removes the host operator from the trust boundary.
Confidential VMs are the practical default for lift-and-shift workloads (AMD SEV-SNP, Intel TDX); process enclaves (Intel SGX) and isolated enclaves (Nitro Enclaves) suit small, high-value functions such as key handling.
The trust boundary moves, it does not vanish: you still trust the CPU vendor, your own code inside the TEE, the guest operating system in a confidential VM, and the verifier that judges evidence.
Side channels and denial of service are not solved: the Confidential Computing Consortium says TEE assurance rests on there being "no exploitable side-channels", and availability attacks are out of scope.
Attestation is a workload identity: a verified measurement can replace the static secrets baked into images, and the key broker that releases keys on evidence becomes a privileged system in its own right.

What confidential computing protects

The Confidential Computing Consortium (CCC), a project community at the Linux Foundation, defines it as protecting "data in use by performing computation in a hardware-based, attested Trusted Execution Environment". Its technical analysis lists three core TEE properties, data confidentiality, data integrity and code integrity, and optional ones: code confidentiality, authenticated launch, programmability, attestability and recoverability. The CCC deliberately excludes TEEs that rely only on software roots of trust.

Threat	CCC threat model	Practical meaning
Software attacks on the host stack (hypervisor, host OS, firmware, other tenants)	In scope	The main reason to adopt: a compromised or malicious host cannot read or alter TEE memory
Protocol attacks on attestation and data transport	In scope	Attestation must be fresh and bound to the channel that receives secrets
Basic physical attacks (cold DRAM extraction, devices plugged into ports)	In scope	Memory encryption defeats a stolen DIMM or bus probe of this kind
Sophisticated, long-term or invasive physical attacks	Out of scope	Data centre physical security still matters
Upstream hardware supply chain (chip manufacturing)	Out of scope	You trust the silicon vendor and its endorsement keys
Availability (denial of service)	Out of scope	The host can still stop, starve or refuse to schedule a TEE
Side channels	An assumption: "there are no exploitable side-channels"	Vendors mitigate through microcode and firmware; verifiers must require patched TCB versions

Confidential computing does nothing for vulnerabilities in the code inside the TEE. A memory disclosure bug such as MongoBleed, which let remote clients read secrets from MongoDB server memory, works just as well inside a confidential VM, because the attacker is talking to the trusted code through its own interface.

TEE technologies compared

Technology	Isolation unit	How isolation works	Evidence and endorsement	Fits
Intel SGX (Software Guard Extensions)	Application enclave inside a process	Enclave memory in the Enclave Page Cache; "only the code or functions inside the protected enclave can access confidential data"	SGX quote, verified with Intel attestation services or DCAP	Small trusted components: key handling, signing, matching logic; requires partitioning the application
Intel TDX (Trust Domain Extensions)	Whole VM ("trust domain")	The TDX module runs in Secure Arbitration Mode (SEAM) "as a peer virtual machine manager"; memory encrypted with TME-MK	TD quote; Intel Trust Authority as an attestation service	Unmodified applications in a confidential VM
AMD SEV-SNP (Secure Encrypted Virtualization, Secure Nested Paging)	Whole VM	One key per VM managed by the AMD Secure Processor; SEV-ES encrypts register state; SNP adds integrity protection against replay and remapping	Attestation report signed with the chip's VCEK; certificates from AMD's Key Distribution Service	Unmodified applications in a confidential VM
Arm CCA (Confidential Compute Architecture)	Realm VM	Armv9-A Realm Management Extension; the Realm Management Monitor runs at Realm EL2 and controls memory transitions, while the host hypervisor keeps scheduling decisions	CCA attestation token	Arm servers and edge; check silicon and cloud availability
AWS Nitro Enclaves	Constrained VM carved from an EC2 instance	Nitro Hypervisor isolates enclave vCPUs and memory; "no persistent storage, interactive access, or external networking"	Attestation document with PCR measurements	Key handling and tokenisation beside an existing EC2 workload
NVIDIA Hopper GPU confidential computing	GPU, paired with a CPU confidential VM	On-die hardware root of trust; encrypted bounce buffers across PCIe	Device certificate (ECC-384) checked against NVIDIA's CA; NVIDIA Remote Attestation Service	AI training and inference on sensitive data or models

Memory encryption is not confidential computing

AMD SME and TSME: Secure Memory Encryption and its transparent form, TSME, protect DRAM. TSME "uses a single key to encrypt system memory", generated by the Secure Processor at boot and enabled in BIOS. It protects against physical memory theft but not against the hypervisor or host OS, and offers no attestation.
Intel TME and TME-MK: Total Memory Encryption, and its multi-key form (formerly MKTME), encrypt DRAM. TDX uses TME-MK as a building block; on its own it is not an attested TEE.
Use them anyway as a cheap baseline against physical attacks, but do not count a host with memory encryption enabled as a confidential computing platform.

Confidential VMs and containers in the cloud

Microsoft Azure: confidential VMs on AMD SEV-SNP or Intel TDX create "a hardware-enforced boundary between your application and the virtualization stack". Optional confidential OS disk encryption binds disk keys to a dedicated vTPM, cannot be changed after deployment and is limited to disks under 128 GB. VMs boot only after the platform is successfully attested. Microsoft lists live migration, dynamic memory and Azure Site Recovery as unsupported, and only offline key rotation. GPU sizes with NVIDIA H100 exist.
Google Cloud: Confidential VM supports AMD SEV (vTPM boot-time attestation), SEV-SNP (attestation reports on demand), Intel TDX and NVIDIA confidential computing on attached GPUs. Live migration is supported only for AMD SEV on N2D and C3D. Confidential GKE Nodes enforce confidential VMs for every node, and Confidential Space lets parties share data with a mutually agreed workload.
AWS: Nitro Enclaves isolate a hardened VM from its parent instance, and "the data and applications inside the enclave cannot be accessed by the processes, applications, or users (root or admin) of the parent instance". Communication is only a local socket to the parent.
Kubernetes: the CNCF Confidential Containers project "encapsulates pods inside of confidential virtual machines" and provides Trustee, an attestation and key-management engine, so secrets reach a pod only after the pod VM is attested. Confidential GKE Nodes protect the whole node instead, which keeps the node's kubelet and other pods inside the trust boundary. See the Kubernetes NHI Security Guide.

Read the cloud provider's own feature matrix before committing: confidential VM sizes, regions, live migration, backup and disk encryption options differ by technology and change often.

Remote attestation and the RATS architecture

RFC 9334, the IETF Remote ATtestation procedureS (RATS) architecture, gives the vocabulary every vendor scheme maps onto. Evidence is "A set of Claims generated by an Attester to be appraised by a Verifier".

RATS role	Definition (RFC 9334)	Confidential computing example
Attester	Entity "whose Evidence must be appraised"	A TDX trust domain, SEV-SNP VM, SGX enclave or Nitro enclave
Endorser	Entity (typically a manufacturer) whose Endorsements help Verifiers	Intel, AMD (VCEK certificate chain), NVIDIA device CA
Reference Value Provider	Supplies values against which Claims are compared	Your build pipeline publishing expected launch measurements; firmware vendors
Verifier	"appraises the validity of Evidence about an Attester"	Intel Trust Authority, Microsoft Azure Attestation, Trustee, NVIDIA Remote Attestation Service
Relying Party	"depends on the validity of information about an Attester"	A KMS or key broker deciding whether to release a key
Verifier Owner / Relying Party Owner	Configure the two appraisal policies	Your security team, not the workload team

Passport model: the attester obtains an Attestation Result from the verifier and presents it to relying parties, as most cloud attestation services do with signed tokens.
Background-check model: the attester sends raw evidence to the relying party, which forwards it to a verifier for appraisal. AWS KMS is a compact variant: it receives the Nitro attestation document with the request and appraises it against the key policy itself.
Freshness: RFC 9334 describes timestamps, nonces and epoch IDs. Use a relying-party nonce, carried in the evidence's user data field, so captured evidence cannot be replayed.
What the appraisal policy must check: genuine hardware chained to the vendor root; minimum TCB or security version numbers (this is how side-channel fixes are enforced); debug mode disabled; launch measurements matching your reference values; and that the public key receiving secrets is bound into the evidence.

Key release on attestation

The pattern that turns attestation into protection: data stays encrypted everywhere, and the key that decrypts it is released only to a TEE whose evidence satisfies policy, encrypted to a key that exists only inside that TEE. Three concrete implementations:

AWS KMS and Nitro Enclaves: key policy condition keys kms:RecipientAttestation:ImageSha384 (which corresponds to PCR0) and kms:RecipientAttestation:PCR<n> work with Decrypt, GenerateDataKey, GenerateDataKeyPair, DeriveSharedSecret and GenerateRandom. KMS encrypts the response under the public key in the attestation document, so it "can be decrypted only by using the private key in the enclave". A request without a valid attestation document fails the condition.
Azure confidential VMs: secure key release creates a "cryptographic binding between the platform's successful attestation and the VM's encryption keys".
Confidential Containers: Trustee attests the pod VM and then provisions secrets and image decryption keys.

Pin measurements of an image you built and reviewed, not "any enclave". When the workload is updated the measurement changes, so key policies must be updated through change control as part of each release. Key hierarchy, rotation and custody are covered in the Cryptographic Key Management Guide.

Where identity fits

Attestation as workload identity: a verified measurement says what code is running on which hardware, a stronger claim than a service account name. Bind short-lived credentials to the attestation result rather than baking API keys or certificates into the image, where any host administrator could copy them. See the Cloud Workload Identity Guide.
The key broker is privileged: whoever can edit the KMS key policy, the attestation policy or the reference values can release keys to their own code. Separate those roles from workload operators, require two-person change and alert on every edit.
Secrets still leave the TEE: logs, crash dumps, telemetry and outbound calls are outside the protected boundary unless you encrypt them. See the Secrets Management Guide.
AI infrastructure: GPU clusters running model training often hold cloud and model registry credentials; confidential GPU nodes reduce exposure to the host, not to the workload's own service identity. See the AI Infrastructure Workload Identity Guide.

Confidential AI and GPU TEEs

AI workloads drove much recent adoption: model owners want to protect weights, and data owners want assurance that prompts and training data are not visible to the platform operator. NVIDIA describes Hopper H100 confidential computing as follows:

Modes: CC-On enables full protections and disables performance counters to reduce side-channel risk; CC-DevTools relaxes protections for profiling; CC-Off is normal operation. Never run production in DevTools mode, and make the mode part of attestation policy.
Data path: the driver inside the CPU confidential VM moves data through an encrypted bounce buffer; command buffers and CUDA kernels are encrypted and signed before crossing PCIe.
Attestation: each GPU has a device identity certificate verified against NVIDIA's CA and checked for revocation; NVIDIA Remote Attestation Service is the primary verifier, with local verification for air-gapped sites at the risk of stale revocation data.
Pairing and performance: the GPU TEE pairs with an SEV-SNP or TDX confidential VM. NVIDIA reports GPU compute and memory bandwidth at parity, but CPU-to-GPU transfer is limited by encryption (about 4 GB/s measured in its 2023 post), so workloads with little compute per input byte suffer most.

Confidential AI protects the model and data from the infrastructure. It does not stop prompt injection, data leakage through outputs or an over-privileged agent. See the LLM Security Guide.

Choosing an approach

Use case	Recommended form	Why
Regulated workload in public cloud, operator access is the concern	Confidential VM (SEV-SNP or TDX) with attested key release for disks and secrets	No application changes; removes hypervisor and host admins from the memory trust boundary
Key handling, tokenisation, signing	Nitro Enclave or SGX enclave	Small trusted code base; easy to measure and review
Multi-party analytics or data clean room	Attested workload whose measurement all parties approve (for example Confidential Space)	Each party releases keys only to agreed code
Sensitive AI inference or fine-tuning	Confidential VM plus GPU TEE in CC-On mode	Protects weights and prompts from the platform
Kubernetes multi-tenant clusters	Confidential Containers for per-pod isolation; confidential nodes for cluster-wide baseline	Choose by whether cluster administrators are inside or outside your trust boundary
Protecting against stolen hardware only	TSME or TME	Cheaper; no attestation needed for that threat

Small organisations: use the cloud provider's confidential VM and its attestation service with provider-managed keys bound to attestation. Building your own verifier is rarely worth it.
Large or highly regulated organisations: consider an independent verifier or one you operate, so the cloud provider is not both the infrastructure and the party vouching for it, and publish reference values from your own build pipeline.
Trade-offs to budget for: lost live migration or backup options on some platforms, I/O overhead, fewer VM sizes and regions, and a release process that must update measurements.

Implementing confidential computing

Define the adversary: write down which parties (cloud operator, host administrators, other tenants, your own platform team) must not see the data. If the answer is "nobody but us", confidential computing may add little.
Pick the TEE form from the table above and confirm sizes, regions and feature limits with the provider.
Pilot with attestation in report mode: deploy a non-production workload, collect evidence and verify it, but do not yet gate keys. Record the measurements your build produces.
Bind keys to attestation: move disk, data and secret keys behind attestation-gated release with pinned measurements, minimum TCB versions and debug disabled. Keep a parallel non-attested key path only for the pilot.
Integrate with release: have the build pipeline publish reference values for each image, and update key policies through change control.
Roll out in rings by data sensitivity; remove the non-attested key path per ring once stable.
Rollback: rollback is redeploying on standard VMs with the data keys re-wrapped, an operation that itself should need approval and leave an audit trail. Test it once before production.

Detection and measurement

Attestation failures: log every verifier decision with the reason (measurement mismatch, TCB below minimum, debug enabled, stale nonce).
Key release events: KMS or key broker decrypt calls, which identity made them and whether attestation was present.
Policy changes: edits to key policies, attestation policies and reference values, which should be rare and approved.
TCB advisories: vendor security bulletins that raise the minimum TCB version, and how many hosts fall below it.

Metrics:

Percentage of in-scope workloads running in an attested TEE with attestation-gated key release.
Number of keys for in-scope data that can still be released without attestation (target zero after rollout).
Time from a vendor TCB advisory to the minimum TCB being raised in attestation policy.
Attestation failure rate, separated into expected (new release) and unexpected.
Count of unapproved changes to key or attestation policies.

Common failure patterns

Encryption without attestation: running confidential VMs but releasing keys the normal way, so a host-side attacker who can impersonate the workload still gets them.
Policies that accept any measurement: checking that evidence comes from genuine hardware but not which code produced it.
Ignoring TCB versions: never raising the minimum TCB after side-channel fixes, so unpatched platforms keep receiving keys.
Debug or developer modes in production: SGX debug enclaves or GPU CC-DevTools mode weaken protections; both must fail attestation policy.
Forgetting the guest: in a confidential VM the whole guest OS is trusted; an unpatched guest or an exposed management agent hands the attacker everything inside the boundary.
Data leaking at the edges: logs, swap, crash dumps and unencrypted connections to services outside the TEE.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	PR.DS-10	Confidentiality, integrity and availability of data in use are protected
NIST SP 800-53 Rev. 5	SC-39, SC-51, SC-12, SI-7, SA-8	Process isolation, hardware-based protection, key management, integrity verification, security engineering principles
NIST IR 8320	Hardware-enabled security	Platform security as the first layer for cloud and edge workloads
ISO/IEC 27001:2022 Annex A	A.5.23, A.8.24	Information security for use of cloud services; use of cryptography
CIS Controls v8.1	Control 3	Data protection
GDPR	Article 32	Appropriate technical measures, including encryption, considering the state of the art

Practitioner checklist

Name the parties the TEE must protect against, and confirm confidential computing addresses that adversary.
Choose confidential VMs for general workloads and enclaves for small, high-value functions.
Release keys only on verified attestation, with pinned measurements, minimum TCB versions and debug disabled.
Bind a fresh nonce and the receiving public key into evidence to prevent replay.
Publish reference measurements from your build pipeline and update key policies through change control.
Separate ownership of key policies, attestation policies and reference values from workload operators.
Replace secrets baked into images with credentials provisioned after attestation.
Run GPUs in CC-On mode and include GPU attestation in policy for confidential AI.
Track vendor TCB advisories and raise minimum versions promptly.
Patch and harden the guest OS, and encrypt logs and connections that leave the TEE.

Confidential Computing Guide