Confidential VMs: Intel TDX vs AMD SEV-SNP vs Arm CCA and Remote Attestation Architecture (2026)

A virtual machine has always trusted its host. The hypervisor can read every page of guest memory, patch guest code, replay disk blocks and snapshot CPU state, and the guest has no way to object. Confidential VMs remove that assumption: the CPU itself encrypts and integrity-protects guest memory, and the hypervisor is demoted from a trusted manager to an untrusted resource allocator.

That sounds like one feature, but Intel TDX, AMD SEV-SNP and Arm CCA make very different architectural bets about who enforces isolation, what is measured, and what a remote party must verify before handing over a secret. Those differences decide your attestation code, your key-release policy and the failure modes you inherit. The encryption is the easy part. The hard part is proving to a remote service, with evidence it can check, that a given workload is running inside the right hardware with the right software.

This post compares the three designs at the mechanism level, then builds the vendor-neutral attestation and key-release architecture that sits on top of them.

What this covers: the threat model, how each CPU protects memory, the trust boundaries, the IETF RATS attestation model (RFC 9334), real quote and certificate flows, cloud availability as of November 2026, performance and side-channel caveats, and the key broker pattern.

Context and Background

Confidential computing grew out of a decade of attempts to shrink the trusted computing base (TCB). Intel SGX (2015) protected small enclaves inside a process, which demanded application rewrites and imposed tight memory limits. The industry then moved the isolation boundary outward to the whole virtual machine, so that unmodified Linux or Windows guests could run protected. That is the idea behind confidential VMs, sometimes called trusted execution environment (TEE) VMs: lift and shift a workload, accept a larger guest TCB, and gain protection from the host.

AMD introduced the first generation, SEV, with memory encryption only (first on EPYC ‘Naples’ in 2017), then added SEV-ES to protect register state and SEV-SNP (Secure Nested Paging) to add integrity protection against a malicious hypervisor. Intel followed with Trust Domain Extensions (TDX), built on its multi-key total memory encryption engine and a signed software component that runs in a special CPU mode. Arm announced the Confidential Compute Architecture (CCA) with the Armv9 Realm Management Extension (RME), which adds new security states to the processor rather than bolting a secure processor onto the side.

The cloud picture has also become concrete. Microsoft announced general availability of Intel TDX confidential VMs on Azure on February 26, 2026, in the DCesv6, DCedsv6, ECesv6 and ECedsv6 series on 5th Gen Xeon, with the first regions being West US, West US 3, West Europe, East US and South Central US (Azure Confidential Computing announcement). Google Cloud documents attestation for AMD SEV, SEV-SNP and Intel TDX confidential VMs (Google Cloud attestation docs). Amazon EC2 offers AMD SEV-SNP on a limited set of M6a, C6a and R6a instance types.

What the cloud vendors sell, and what you are entitled to claim, are different things. A confidential VM is a promise about confidentiality and integrity against the infrastructure operator, not a promise that your application is bug-free, that the guest OS is hardened, or that every physical attacker is excluded. If you are building toward container workloads, the same hardware primitives underpin the stack described in our Confidential Containers on Kubernetes architecture guide, and if the workload is GPU-bound, the GPU trust extension is covered in confidential AI inference with TEE GPUs.

The vocabulary matters, so fix it now. A guest is the confidential VM. The host is the hypervisor plus host OS plus the machine operator. Measurement is a hash of code or configuration loaded into the guest. Evidence is a signed statement from hardware or firmware containing measurements. Attestation is the process of a verifier appraising that evidence against a policy. These terms come from the IETF Remote ATtestation procedureS (RATS) architecture, standardised as RFC 9334, and we will use them precisely.

Threat Model and Reference Architecture for Confidential VMs

Confidential VMs defend against a privileged software attacker on the host: a compromised hypervisor, a malicious cloud administrator, a rogue management controller or a co-tenant exploiting a hypervisor bug. They do not, by vendor design, defend against an attacker with physical access to the memory bus, nor against all microarchitectural side channels.

The three CPU families share this contract. The differences lie in how the contract is enforced.

Figure 1: Trust boundaries. The hypervisor, host OS, devices and operator tooling sit outside the guest’s trust. Each vendor places the enforcement point in a different layer of hardware or signed firmware.

Figure 1 shows the shape. The host still schedules vCPUs, assigns physical pages and brokers I/O, but it manages the guest through a narrow, vendor-defined interface rather than direct access. In TDX the interface is the TDX module executing in SEAM (Secure Arbitration Mode) root; in SEV-SNP it is the AMD Secure Processor (PSP) firmware plus the CPU’s reverse map table; in Arm CCA it is the Realm Management Monitor (RMM) running in the new Realm world, with the Root world firmware underneath it.

What the attacker can and cannot do

Spell out the capabilities, because “confidential” is meaningless without them. The in-scope attacker can read and modify any memory the hypervisor controls, remap guest-physical pages, inject interrupts and exceptions, control the clock the guest sees, replay old memory contents, boot the guest with modified firmware, present fake devices and observe the guest’s network and disk traffic. Every capability becomes an attack class: remapping and replay break integrity unless the hardware tracks page ownership; modified firmware breaks trust unless it is measured; fake devices and interrupts break the guest unless it validates them.

The out-of-scope list is just as important. Physical probes on the DRAM bus, voltage glitching of the secure processor, and most cache and timing side channels are explicitly excluded or only partly mitigated by vendors. We return to this in the trade-offs section, because the October 2025 TEE.Fail result sharpened exactly this boundary.

Three enforcement models

Intel TDX: a signed module in a new CPU mode. A Trust Domain (TD) is the TDX guest. The CPU adds a new processor mode, SEAM, in which Intel’s signed TDX module runs. The host VMM calls into the module using SEAMCALL instructions to create TDs, add pages and schedule vCPUs. The TD calls out to the module and the VMM using TDCALL. Memory is encrypted with AES-XTS using keys from the multi-key total memory encryption engine (MKTME), with a per-TD key held in the memory controller and never visible to software. Integrity comes from the module’s tracking of which physical pages belong to which TD (its Physical Address Metadata Table) combined with hardware checks that tag memory with its owning key, so a host cannot silently map a TD page into another VM.

AMD SEV-SNP: a secure processor plus a reverse map. SEV-SNP uses the AMD Secure Processor (PSP), an on-die Arm-based coprocessor, to manage launch and keys, and each guest gets a memory encryption key managed by the memory controller. Integrity is enforced by the Reverse Map Table (RMP): a system-wide table with one entry per 4 KB system physical page recording the owner, the expected guest-physical address and validation state. On every nested page-table walk the CPU checks the RMP, so a hypervisor that remaps a page or aliases it to two guests triggers a fault. SEV-SNP also defines Virtual Machine Privilege Levels (VMPL0 to VMPL3) inside the guest, enabling a paravisor or virtual TPM inside the same encrypted guest.

Arm CCA: new worlds and a granule protection table. Arm RME adds two security states, Realm and Root, to Non-secure and Secure, giving four physical address spaces. Memory is assigned to a world through the Granule Protection Table (GPT), checked by hardware on every access after stage-2 translation. Root-world firmware (the trusted-firmware monitor at EL3) manages GPT transitions; the RMM runs in the Realm world and manages realms on behalf of the non-secure hypervisor. The Trusted Firmware-A project documents RME support from TF-A 2.6 onward, with the RMM and the GPT library described in its docs (TF-A RME documentation). Notably, the architecture itself is about access control by physical address space; protection against bus snooping depends on the SoC implementing memory encryption (the architecture defines optional Memory Encryption Contexts for this, which I have not verified against a shipping part), a distinction worth remembering when comparing “CCA” to “TDX”.

Memory encryption is not memory integrity

Teams routinely conflate the two, and the history of this field is the history of fixing that. Encryption alone (original SEV) stops a passive reader of RAM but does not stop a hypervisor from copying an encrypted page from one address to another, replaying an older ciphertext of the same page, or remapping a guest page to attacker-chosen data. Several published attacks against first-generation SEV and SEV-ES exploited exactly those gaps.

Integrity protection adds a second question to every access: “is this page currently owned by this guest, mapped at this address?” That is what the RMP answers for SEV-SNP, what the TDX module’s page metadata and key-ownership checks answer for TDX, and what the GPT answers for CCA. Note what this buys and what it does not. It prevents software-level remapping, aliasing and replay of whole pages by the host. It does not, by itself, authenticate every cache line against a physical attacker who can record and replay bus traffic, because the data encryption used is AES-XTS, a tweakable but unauthenticated mode that is deterministic for a given key, address and plaintext.

Side by side

Property	Intel TDX	AMD SEV-SNP	Arm CCA (RME)
Guest unit	Trust Domain (TD)	SNP guest	Realm
Isolation enforcer	Signed TDX module in SEAM mode	PSP firmware plus CPU RMP checks	RMM in Realm world plus Root-world monitor, GPT in hardware
Memory encryption	AES-XTS via MKTME, per-TD key	AES per-guest key in memory controller	Implementation-defined by SoC, architecture is access control by PAS
Page ownership tracking	Module metadata plus key-ownership checks	Reverse Map Table (RMP)	Granule Protection Table (GPT)
In-guest privilege layers	L1/L2 nesting via module partitioning	VMPL0 to VMPL3	Not equivalent, realm personalisation by RMM
Evidence signer	TDX module measurement quoted by SGX-based Quoting Enclave or equivalent	PSP signs report with VCEK or VLEK	Realm Attestation Token signed with a platform-bound key plus realm token
Measurement registers	MRTD plus RTMR0 to RTMR3	Single launch measurement plus host data, ID block and report data	Realm Initial Measurement plus Realm Extensible Measurements
Vendor cert service	Intel Provisioning Certification Service (PCS)	AMD Key Distribution Service (KDS)	SoC vendor defined
Production cloud availability (verified)	Azure GA (Feb 2026), Google Cloud C3 documented	AWS (M6a, C6a, R6a), Google Cloud, Azure	Not verified in a public cloud

Comparison reflects architectures as documented; register counts and token formats are taken from vendor specifications and should be re-checked against the current revision before you build a verifier.

Why the attestation story diverges

The enforcement differences cascade into evidence format. SEV-SNP is the simplest: the PSP is a single trust anchor, and its report is signed directly by a chip-specific key whose certificate chain AMD publishes. TDX needs an additional step, because the TDX module itself cannot sign with a hardware root key. It produces a TD Report, a MAC-protected structure that can only be verified on the same platform, which a separate quoting component then converts into a signed quote that a remote party can check. CCA splits evidence into a platform part, attesting the hardware and firmware including the RMM, and a realm part, attesting the realm’s own measurements, which are combined in one token defined by an IETF draft built on the Entity Attestation Token (EAT) family.

That is why “which CPU” is an architecture decision for your verifier, not just a procurement line. A verifier that accepts one evidence format will not accept another, which is the practical motivation for unifying the verification layer, the subject of the next section.

Remote Attestation Architecture: From Quote to Key Release

Remote attestation is a protocol where a relying party gets cryptographic evidence about the state of a remote system and decides whether to trust it. For confidential VMs the usable form is: a fresh nonce goes in, a signed statement of hardware identity, firmware versions and boot measurements comes out, and a verifier checks signature, freshness, certificate chain, revocation and measurements against policy.

The RATS architecture, RFC 9334 (published January 2023), gives this a vocabulary that works across all three CPU families, and it is what most modern confidential-computing stacks now use, explicitly or implicitly.

Figure 2: RATS roles mapped to a confidential VM deployment. The vendor acts as Endorser, an image pipeline supplies reference values, and a key broker acts as Relying Party.

RATS roles, mapped to real components

The Attester is the confidential VM, specifically a guest agent that asks the hardware or firmware to produce evidence. The Verifier appraises that evidence. It needs endorsements (the vendor’s statement that this signing key belongs to a genuine chip at a given TCB level) and reference values (what measurements a good workload should have) plus an appraisal policy. The Relying Party consumes the verifier’s result and decides, for example, to release a database encryption key. RFC 9334 describes two topologies. In the passport model the attester carries the verifier’s signed result to the relying party. In the background-check model the relying party forwards the evidence to a verifier itself. Most key brokers use background-check, because the broker also wants to control the nonce.

The Endorser role is played by Intel for TDX (through its Provisioning Certification Service), by AMD for SEV-SNP (through the Key Distribution Service) and by the SoC vendor for CCA. The Reference Value Provider is you: your build pipeline that produces a firmware image, kernel and initrd, and computes their expected measurements. Treat that pipeline as part of your TCB; a compromised pipeline that publishes bad reference values makes attestation succeed on a malicious image.

Evidence versus attestation results

Do not collapse evidence and results. Evidence is hardware-specific and bulky. An attestation result is the verifier’s normalised, policy-evaluated output, commonly a signed JSON Web Token carrying claims. Google’s attestation service and Microsoft Azure Attestation both return tokens of that shape, and the IETF Entity Attestation Token (EAT) work provides a common claims framework. The point of the split is that relying parties should write policy against claims such as “debug disabled”, “TCB at or above version N” and “measurement equals X”, not parse hardware structures.

Binding the channel to the evidence

An attestation that is not bound to the secure channel is a replay or relay waiting to happen. The standard fix is to put a hash of something fresh in the report’s user-data field. For SEV-SNP the report contains a 64-byte REPORT_DATA field; for TDX the TD Report carries 64 bytes of REPORTDATA; both are chosen by the guest. The robust pattern is to include the verifier’s nonce and a hash of an ephemeral public key generated inside the VM. The relying party then encrypts the secret to that key, so only the attested VM can use it.

Deeper Analysis: Quote Flows, Certificates and Cloud Differences

SEV-SNP: report, VCEK or VLEK, chain

An SEV-SNP attestation report is generated by the PSP on request from the guest and signed with an ECDSA P-384 key. Which key depends on where you run. On a bare dedicated host the report is signed with the VCEK (Versioned Chip Endorsement Key), a per-chip key that is also bound to the reported TCB version; AMD’s Key Distribution Service issues a certificate for it, selected by chip ID and TCB. In shared AWS tenancy the report is signed with a VLEK (Versioned Loaded Endorsement Key) that AMD issues to the cloud provider, and AWS states this explicitly in its documentation (AWS SEV-SNP attestation guide). VLEK matters because it lets a cloud provider avoid revealing per-chip identifiers to every tenant while still chaining to AMD’s root.

The AWS guide demonstrates the flow with the open-source snpguest tool, and the sequence below reproduces its documented steps for a Dedicated Host:

# Build and use snpguest (from virtee/snpguest), per AWS documentation
./snpguest report report.bin request-file.txt --random
./snpguest fetch vcek pem ./ ./report.bin --processor-model milan
./snpguest fetch ca PEM ./ milan --endorser vcek
./snpguest verify certs ./
./snpguest verify attestation ./ report.bin

The verifier must check four things in order. First, the certificate chain from VCEK or VLEK up through the AMD SEV Key (ASK) to the self-signed AMD Root Key (ARK). Second, the report signature. Third, that the TCB fields in the certificate extensions match the report. Fourth, the report contents: the 48-byte launch measurement, the guest policy (debug bit off, migration agent restrictions), the REPORT_DATA binding, the platform version, and optionally the ID block and author key for image-signing workflows. AWS notes that the currently supported processor model in that guide is Milan.

A practical operational note from the same documentation: on Dedicated Hosts, firmware updates are applied when you allocate a host, so to get the latest firmware you release and re-allocate the host. This shows up in attestation as a changed TCB version. Your policy needs a minimum TCB, not an equality check, or you will reject legitimately updated hosts.

TDX: TD report, quote, PCK certificate

TDX evidence is a two-stage object. A guest issues a TDG.MR.REPORT call to the TDX module and receives a TD Report containing, among other fields, the build-time measurement register MRTD (the measurement of the initial TD contents, including virtual firmware), four runtime measurement registers RTMR0 to RTMR3 that firmware and the OS extend during boot much like TPM PCRs, the TD attributes, and the 64-byte REPORTDATA. The report is only locally verifiable. A quoting component on the host, using the SGX-based Quoting Enclave in Intel’s DCAP architecture or a vendor service that wraps it, converts it into a signed quote using an attestation key whose certification chains to the Provisioning Certification Key (PCK) for that platform. Intel’s DCAP documentation defines the quote-generation library interface for TDX (Intel TDX DCAP Quoting Library API).

Verification then needs the PCK certificate chain, a PCK CRL for revocation, and the signed TCB Info and QE Identity collateral from Intel’s PCS. The collateral gives a TCB status such as up to date, out of date or requiring configuration changes, and your policy decides which statuses to accept. This status-based model is where TDX operations differ most from SEV-SNP’s simple minimum-TCB rule, and why mature deployments use a verification service rather than hand-rolled code. Intel Trust Authority is Intel’s hosted verifier for this (Intel Trust Authority docs).

Figure 3: Generic evidence flow. Hardware firmware signs a report that includes the verifier nonce, a quoting step or certificate fetch adds the chain, and the verifier consults the vendor certificate service for revocation and TCB status before producing a result.

Figure 3 abstracts a pattern shared by both vendors. The guest asks firmware for a signed report, the host-side proxy or quoting component helps with certificates (necessarily untrusted, because it cannot forge the signature), and the verifier fetches freshness-critical collateral directly from the vendor rather than trusting what the host supplies. That last property matters: revocation data from the host is advisory, revocation data from the vendor is authoritative.

Arm CCA: two tokens, one chain

For CCA, the Realm Attestation Token combines a platform token and a realm token, both EAT-based CBOR Web Tokens in a COSE envelope, specified in the IETF draft draft-ffm-rats-cca-token. The platform token attests the hardware and firmware stack; the realm token contains the Realm Initial Measurement (RIM), up to four Realm Extensible Measurements (REMs), the realm personalisation value and a challenge. The platform token’s binding to the realm token is by hashing the realm public attestation key into the platform token’s challenge, so the two cannot be mixed and matched across realms. Two caveats apply: I could not verify the current final RFC status of that draft, and I did not find a public cloud service that offers CCA realms. Software development today rests on the Fixed Virtual Platform (FVP) models and the Trusted Firmware-A and TF-RMM projects.

Cloud services in practice

All three hyperscalers offer verification services, but they differ in scope. Google Cloud documents a layered model: the vTPM, which is Google-managed software, signs a quote for boot-chain integrity, while the AMD Secure Processor or Intel TDX module root the hardware and firmware claims; the Go-TPM tools (0.4.4 or later for SEV-SNP and TDX) fetch the reports and a quote goes to Google Cloud Attestation, which returns a token you check against your policy (Google Cloud docs). For TDX, firmware measures into MRTD and the rest of the boot chain into RTMRs. Microsoft Azure offers confidential VMs on AMD SEV-SNP and Intel TDX with Microsoft Azure Attestation as the verifier, plus a paravisor (OpenHCL for the TDX series, per the GA announcement) that sits inside the guest’s trust boundary and provides services such as a virtual TPM. AWS documents SEV-SNP attestation as a raw report plus snpguest and leaves the verification logic and policy to you, with EC2 NitroTPM attestation as a separate mechanism for the Nitro system.

The difference is not cosmetic. Where a paravisor or a vTPM is in the picture, part of the trust chain is the cloud provider’s own software inside your guest. That software is open source in some cases (Microsoft describes OpenHCL as open source) and measured into the evidence, but it enlarges the TCB beyond the CPU vendor.

The Key Broker Pattern: Releasing Secrets Only to Attested Workloads

Attestation is only useful if something changes as a result. The dominant production pattern is attestation-gated key release: the encrypted data or container image sits anywhere, including untrusted storage, and the decryption key lives in a key broker service that releases it only after the requesting VM proves its state. The CNCF Confidential Containers project calls its components Trustee, consisting of a Key Broker Service (KBS), an Attestation Service (AS) and a Reference Value Provider Service (RVPS); the terms are useful beyond that project.

Figure 4: Attestation-gated key release. The broker issues a nonce, the workload returns evidence bound to the nonce and an ephemeral key, the attestation service produces claims, policy is evaluated, and the secret returns wrapped to the ephemeral key.

The request-challenge-attestation-response loop

The loop in Figure 4 has five security properties worth checking in any implementation. Freshness: the broker generates the nonce, so old evidence cannot be replayed. Binding: the evidence’s user-data field commits to the nonce and the guest’s ephemeral public key, so a man in the middle cannot swap keys. Appraisal: the attestation service validates the signature chain, collateral and TCB status and emits normalised claims. Policy: the broker’s resource policy, written against claims such as measurement, TCB level and debug state, decides which secrets this identity may read. Confidential delivery: the secret is wrapped to the ephemeral key, so even an operator sniffing the network, or reading the broker’s logs, sees nothing useful.

A concrete policy sketch, in the Rego style used by several open-source attestation services, makes the idea tangible. This is an illustrative policy, not a copy of any product’s schema:

package keybroker

default allow = false

allow {
    input.tee == "snp"
    input.claims.debug_allowed == false
    input.claims.reported_tcb_snp >= 8
    input.claims.measurement == data.reference.approved_image_hash
    input.claims.report_data == input.nonce_key_binding
}

The tcb threshold is a placeholder you set from the vendor’s security bulletins. The critical details are the comparison operators: measurement is an equality against a signed allow-list, TCB is a minimum, and debug is a hard fail. In production the allow-list should hold several measurements (current and previous image), signed by your release pipeline, so rollouts do not lock out half your fleet.

Measuring what actually matters

The launch measurement proves what was loaded, not what is running a week later. For SEV-SNP the measurement covers initial memory and vCPU state, which means you must also measure the kernel, initrd and kernel command line, typically by using direct boot and including them in the measured firmware volume or via a measured boot chain. TDX allows runtime extension: firmware and the OS extend RTMRs as stages load, which gives a TPM-like event log you can replay. In either case, an attestation is only as strong as the coverage of the measurement. If your VM boots an unmeasured root filesystem, the evidence proves the kernel is genuine and says nothing about the packages that follow.

Strong designs close the gap with dm-verity-protected read-only roots and an encrypted data volume whose key is released by the broker, so the measured kernel command line pins the verity root hash. Then the single measurement transitively covers the entire OS image. This is the approach taken by several confidential-VM distributions and by Kata-based confidential containers.

Workload identity after attestation

Once the VM has proven itself, you rarely want it to keep presenting hardware evidence on every connection. The common bridge is exchanging attested identity for a short-lived workload credential, such as an X.509 SVID or an OIDC token, which downstream services already know how to verify. The patterns for issuing and rotating such credentials are discussed in our comparison of Kubernetes pod certificates, SPIFFE/SPIRE and cert-manager; the confidential-VM twist is that the identity is issued only to workloads whose evidence passed policy, so identity itself becomes hardware-rooted.

Performance Overhead: What the Evidence Actually Says

Vendor marketing tends to say “single-digit percent”. The independent literature is more nuanced, and the correct answer is that overhead is workload-shaped.

A SIGMETRICS 2025 study on confidential VMs (SEV-SNP and TDX, “CVM Explained”) reports several specific penalties in its published abstract (CVM Explained, SIGMETRICS 2025 abstract). Booting a CVM can take more than twice as long as a standard VM. Initial memory allocation can grow by up to 92% because each page must be accepted by the guest. Frequent vCPU sleep and wake (HLT) events produced the worst slowdown, up to 431% in one NPB benchmark case, which guest-side polling reduced. Heavy network processing such as iperf TCP showed up to a 60% drop because of bounce buffers. The same abstract does not give a single average overhead, and neither should you.

Those numbers cluster around three mechanisms. First, page acceptance and encryption costs show up at boot and on memory growth. Second, exits become expensive: because the host cannot read guest registers or memory, every VM exit passes through the TDX module or the SNP exit-handling path with state save and restore, so workloads that exit frequently (timers, HLT, MMIO) pay more. Third, I/O needs bounce buffers: devices cannot DMA into private memory, so the guest copies data through shared pages, which hurts high-bandwidth networking and storage unless devices become trusted (the aim of TDISP and TDX Connect, SEV-TIO).

For compute-bound and memory-bound workloads, the encryption cost itself is small on current hardware. One academic SEV-SNP measurement (NestedSGX, an enclave-in-CVM research system) reported memory bandwidth at 98.7% of baseline and about 2.1% average overhead on nbench, though that system is a research prototype and measures SEV-SNP only, so treat it as one data point rather than a TDX comparison (arXiv 2402.11438). Azure’s GA post claims nearly 5x throughput and about 16% lower latency for local NVMe versus the previous SCSI generation, but that compares storage generations, not confidential versus non-confidential.

My practical guidance: benchmark your own workload with the same instance type, with and without confidential mode, and measure p99 latency rather than means, since exit-heavy tail behaviour is where regressions hide. Use the illustrative decision table below as a screening aid, not as measured data.

Workload shape	Expected sensitivity (qualitative)	First mitigation
Batch compute, large heap	Low	Pre-fault memory, use hugepages
Latency-sensitive RPC with many timers	Medium to high	Tune idle polling, reduce timer wakeups
High-throughput network or storage	High	Use vendor-offered accelerated or trusted I/O paths, batch I/O
Short-lived many-VM burst	High (boot and allocation)	Warm pools, snapshot-free fast boot images

Trade-offs, Gotchas, and What Goes Wrong

Physical attacks are out of scope, and this is now demonstrated. In October 2025 researchers disclosed TEE.Fail, an attack using a DDR5 interposer built from off-the-shelf equipment costing under $1,000 that observes memory traffic. They report that deterministic AES-XTS encryption is the weak point and that the attack extracted attestation keys from Intel’s provisioning enclave and affected SGX, TDX and SEV-SNP including Ciphertext Hiding. Both AMD and Intel responded that physical attacks of this class are out of scope (The Hacker News coverage). The lesson is architectural: if your adversary includes an insider with datacentre access, today’s confidential VMs do not fully cover you, and attestation keys themselves become a target.

Side channels are only partly mitigated. Cache, branch predictor and page-fault controlled-channel attacks exist against all VM-level TEEs. Hardware vendors deliver mitigations through microcode and TCB updates, which is exactly why your policy needs a minimum TCB and why unpatched platforms should fail attestation. I have not enumerated individual CVEs here because the list moves faster than this article; check the vendors’ security advisories for the TCB version you accept.

The guest TCB is large. The SIGMETRICS study cited above notes that CVM TCBs often include a full guest OS, measured in millions of lines of code, and reports that a large share of the analysed vulnerabilities involved firmware and improper input validation. Confidential VMs protect the guest from the host; they do not protect the host from the guest, nor the guest from itself. Input from the hypervisor (virtio descriptors, interrupts, MMIO, CPUID) is hostile and must be validated.

Attestation theatre. The commonest real-world failure is a verifier that checks the signature and ignores policy: accepting debug-enabled guests, any TCB, or any measurement. The second most common is unbound evidence, where nonce and key are not in the report data. The third is availability coupling: if your verifier or the vendor’s certificate service is down, new VMs cannot get keys. Cache collateral with an expiry, and design a break-glass path that is itself audited.

Lock-in and portability. Evidence formats differ, cloud paravisors differ, and CCA lacks a public cloud today in my search. Normalising at the claims layer, and holding reference values per platform, keeps migration possible.

Practical Recommendations

Choose the technology by deployment reality first. If you are on a public cloud today, your options are what your provider offers: SEV-SNP is the broadest across AWS, Google Cloud and Azure, and TDX is now generally available on Azure and documented on Google Cloud. Arm CCA is, as of this writing, something to prototype against on FVP models and to plan for, not to deploy, unless your silicon vendor says otherwise.

Next, separate the three layers of the design. Pick the hardware and image layer (which CPU, which measured distro). Pick the verification layer (a managed attestation service where it fits, an open-source verifier where you need portability). Pick the policy and key release layer (a broker you control). Keep the third layer vendor-neutral, because it holds your actual secrets.

Checklist before production:

• Threat model written down, with physical attacks and side channels explicitly accepted or mitigated by other means.
• Measured boot chain covers firmware, kernel, initrd and command line; root filesystem protected by dm-verity or equivalent.
• Verifier enforces debug off, minimum TCB, signed measurement allow-list with at least two image versions.
• Nonce from the relying party; report data binds nonce and an in-guest ephemeral key.
• Secrets wrapped to the ephemeral key; no long-lived secret baked into images.
• Collateral (CRLs, TCB info) cached with expiry and monitored; verifier outage runbook exists.
• Performance tested on your workload, p99 measured, exit-heavy paths tuned.
• Reference-value pipeline treated as TCB, with signing and review.

Frequently Asked Questions

What is the difference between Intel TDX and AMD SEV-SNP?

Both encrypt guest memory and protect it from the hypervisor, but they enforce it differently. TDX uses a signed Intel module running in a special CPU mode (SEAM) with MKTME-managed keys, while SEV-SNP uses the AMD Secure Processor and a Reverse Map Table to track page ownership. Evidence also differs: TDX produces a report converted to a quote by a quoting component, whereas the SEV-SNP firmware signs the report directly.

Is Arm CCA available in the cloud?

I could not verify a generally available Arm CCA confidential VM from a major public cloud. The documented path today is development on Fixed Virtual Platform models using Trusted Firmware-A and the TF-RMM project. CCA adds Realm and Root worlds and a Granule Protection Table, and an IETF draft defines its attestation token. Check your SoC and cloud vendor roadmaps before planning any production dependency on it.

What is remote attestation in confidential computing?

Remote attestation lets a relying party verify the state of a remote workload before trusting it. The CPU or its firmware produces signed evidence containing measurements and a verifier-supplied nonce; a verifier checks the certificate chain, signature, freshness and policy and issues a result. RFC 9334 defines the roles: attester, verifier, relying party, endorser and reference value provider.

What are VCEK and VLEK in SEV-SNP?

The VCEK is a per-chip, TCB-versioned key that AMD certifies and that signs attestation reports, typically on dedicated hosts. The VLEK is a versioned key issued by AMD to a cloud provider, used on shared tenancy so tenants do not learn per-chip identifiers. AWS documents both: VCEK on Dedicated Hosts, VLEK on shared tenancy. Verifiers must validate the chain up to AMD’s root.

Do confidential VMs protect against a malicious cloud administrator with physical access?

Not fully. They protect against privileged software on the host, but vendors treat physical memory-bus attacks as out of scope, and the 2025 TEE.Fail research showed DDR5 interposition against TDX and SEV-SNP using inexpensive equipment. If physical insiders are in your threat model, add compensating controls such as dedicated facilities, application-level encryption, and short-lived secrets.

How much slower are confidential VMs?

It depends on the workload. Compute- and memory-bound jobs often see small overhead, but the SIGMETRICS 2025 CVM study reported boot more than twice as slow, up to 92% greater initial memory allocation time, up to 60% network throughput loss in iperf, and a worst case of 431% in an HLT-heavy benchmark. Always benchmark your own workload and measure tail latency.

Further Reading

Related posts on this site:

• Confidential containers on Kubernetes architecture for running attested pods on these CPUs.
• Confidential AI inference with TEE GPUs for extending the trust boundary to accelerators.
• Kubernetes pod certificates vs SPIFFE/SPIRE vs cert-manager for turning an attested identity into workload credentials.

External sources:

• RFC 9334, Remote ATtestation procedureS Architecture
• AWS, Attest an EC2 instance with AMD SEV-SNP
• Google Cloud, Confidential VM attestation
• Trusted Firmware-A, Realm Management Extension

By Riju — about