Platform security engineers evaluating confidential VM options regularly ask us the same question: should we standardize on AMD SEV-SNP or Intel TDX? The honest answer is that they protect against different parts of the threat model in architecturally different ways, and the right choice depends on where your threat boundary sits, what attestation properties your relying parties require, and which CPU your workloads already run on. This piece compares the two architectures at the level of detail that actually matters for design decisions — not marketing abstractions, but the specific mechanisms that define what each platform can and cannot prove.
Memory Encryption: How Each Platform Isolates Guest Memory
Both platforms use hardware memory encryption to prevent a malicious hypervisor from reading guest VM memory. But the encryption key management architectures are significantly different.
AMD SEV-SNP (Secure Encrypted Virtualization — Secure Nested Paging) maintains per-VM encryption keys managed by the AMD Secure Processor — a dedicated ARM Cortex-A5 core integrated on the AMD CPU die. Each VM gets a unique VM Encryption Key (VEK) generated by the Secure Processor and never accessible to the hypervisor or host CPU. Memory encryption uses AES-128 in XEX mode with physical address-derived tweaks, providing ciphertext diversity across memory lines even for repeated writes of the same plaintext. The SNP extension added Reverse Map Table (RMP) checks that prevent a malicious hypervisor from remapping guest physical pages to host physical addresses the guest didn't expect — addressing the "SEV-ES memory aliasing" attack class from 2021.
Intel TDX (Trust Domain Extensions) uses a different approach: the Trust Domain Encrypted Physical Memory (TDMR) is managed by the TDX Module, a software component that runs in a new CPU privilege level higher than the hypervisor (SEAM mode). Each Trust Domain gets a 128-bit ephemeral key generated by the processor at TD creation time using an on-die TRNG. Memory encryption is AES-128-GCM with Galois/Counter mode, providing not just confidentiality but also integrity and replay protection for each 64-byte cache line. The integrity tags are stored in a dedicated Integrity Check Value (ICV) memory region that the TD cannot access and the hypervisor cannot modify without detection.
The Attestation Architecture Comparison
This is where the architectures diverge most significantly in practice. Attestation — the process by which a remote party verifies that the TEE is running unmodified code on genuine hardware — uses different trust anchors and verification paths in each platform.
| Property | AMD SEV-SNP | Intel TDX |
|---|---|---|
| Hardware attestation root | VCEK (Versioned Chip Endorsement Key), unique per chip, derived from AMD root CA | TDQE (TD Quoting Enclave), signs TD measurements using ECDSA P-256 with Intel-provisioned key |
| Measurement format | ATTESTATION_REPORT signed via AMD Secure Processor; includes MEASUREMENT, HOST_DATA, REPORT_DATA fields | TD Quote with TCB_INFO, TD_REPORT, TDQE_REPORT; signature generated via the Quoting Enclave (TDQE) |
| TCB recovery | VCEK rotates to new VLEK per TCB level; old attestations become invalid after grace period | TCB Recovery updates TDX Module; affected TDs produce quotes with lower TCB status |
| Verification service | AMD KDS (Key Distribution Service) for VCEK certificates | Intel PCS (Provisioning Certification Service) for quote collateral |
| Offline verification | Possible with cached VCEK certificate chain | Possible with cached Intel PCS collateral (expires) |
Both platforms require trusting the chip vendor's certificate infrastructure. AMD's KDS and Intel's PCS are externally operated services that must be available for first-time certificate retrieval. Neither architecture allows a relying party to verify attestation with no dependency on vendor infrastructure.
Trust Boundaries: What Each Platform Actually Protects
Understanding what each TEE protects — and what it explicitly does not — is more useful than comparing feature lists.
AMD SEV-SNP trust boundary
SEV-SNP is designed to protect against a malicious hypervisor and cloud provider. The SNP RMP prevents the hypervisor from aliasing guest physical memory to other physical addresses. The Secure Processor enforces that VEKs are never exported to host software. A guest VM running under SEV-SNP can verify, via remote attestation, that its initial memory state matches the expected digest and that the firmware version meets a minimum TCB level.
What it doesn't protect against: side-channel attacks from co-located workloads using shared CPU micro-architectural state (the research covered in our earlier analysis of TEE side channels), physical attacks on DRAM (DRAM is encrypted but the encryption happens at the memory controller, not at the DIMM — advanced cold-boot techniques targeting the memory controller are out of scope for SEV-SNP's threat model), and compromised firmware within the encrypted guest VM itself.
Intel TDX trust boundary
TDX's key architectural difference is the per-cache-line integrity checking via GCM tags. This provides cryptographic assurance that DRAM contents haven't been modified, not just that they haven't been read. A physical attacker who can write to DRAM receives detectable integrity failures rather than silent corruption. This makes TDX's memory integrity guarantees stronger than SEV-SNP's against certain physical attack classes.
The GCM overhead is non-trivial: approximately 4% memory bandwidth reduction in memory-intensive workloads in Intel's published benchmarks, with latency penalties for the integrity check path on cache misses. For crypto-heavy workloads, this overhead can be higher.
Attestation Freshness and TCB Recovery in Production
Both platforms require handling TCB recovery events — firmware updates that change the TCB level and invalidate attestations produced under the old TCB. In our conversations with platform engineering teams, this is consistently the operational friction point that's underestimated at design time.
AMD's model: when AMD releases a microcode update that changes the SVN (Security Version Number), the VCEK rotates to reflect the new TCB. Workloads attested under the old SVN produce different VCEK-signed reports. Relying parties configured to require a minimum SVN will reject old attestations. Workloads continue running but attestation-dependent operations (key unwrap from KMS, re-authentication with remote services) may fail until the guest is relaunched under the updated microcode.
Intel's model is similar but uses a TCB status field in the Quote: OUT_OF_DATE, SW_HARDENING_NEEDED, CONFIGURATION_NEEDED, etc. Relying parties can implement policy-based acceptance of lower TCB states with reduced trust levels rather than hard rejection, which gives more operational flexibility at the cost of additional policy complexity.
"In practice, we've seen teams underestimate TCB recovery operations by a factor of three in their runbooks. A firmware update that takes 30 minutes per host can translate to hours of attestation-dependent service disruption if re-launch sequences aren't automated."
Where a Hardware Co-Processor Extends Coverage
Neither platform addresses persistent key storage outside the encrypted guest VM. If your architecture requires keys that survive VM re-launches — for database encryption, HSM-backed certificate authorities, or code-signing pipelines — both SEV-SNP and TDX rely on external key management infrastructure. The key material leaves the encrypted memory boundary when it's retrieved from that infrastructure and loaded into the running workload.
This is the gap a hardware co-processor fills. When key derivation and storage live in a dedicated chip with its own isolated execution environment — physically separate from the general-purpose CPU, with no shared cache hierarchy — the key material never exists in the CPU's encrypted memory region at all. The attestation path becomes: verify the CPU TEE, then verify the HSM co-processor's attestation, then bind the key release policy to both. The combined trust boundary is stronger than either component alone.
For teams building on AMD SEV-SNP or Intel TDX today, our recommendation is to treat them as what they are: strong protections against hypervisor and cloud-provider-level access to running workload memory. That's a real and valuable security property. For key management, code signing, and long-lived secret storage, a hardware root of trust that operates outside the general-purpose CPU boundary provides defense-in-depth that neither platform's native attestation architecture covers by design.
