Intel TDX vs AMD SEV-SNP Architecture Differences

AMD's path to SEV-SNP is worth tracing because the architecture reflects the path. The original Secure Encrypted Virtualization, introduced in 2016, addressed the most obvious exposure: a host with physical memory access could read plaintext guest memory. SEV encrypted guest memory with a key inaccessible to the hypervisor. That was the starting point, and it was deliberately narrow. But encryption alone raises an uncomfortable question: what stops an adversary from tampering with memory they cannot read?

SEV-ES extended protection to CPU register state and execution context. A malicious host could no longer observe register contents at VM exit boundaries, closing an information-disclosure gap that SEV left open. Each generation addressed one discrete layer of the attack surface, and that incrementalism turned out to matter architecturally.

SEV-SNP, introduced in 2020, added the integrity layer the prior generations lacked. Encryption without integrity is insufficient: an adversary who cannot read encrypted pages can still remap them, substituting or duplicating memory beneath a running guest. The Reverse Map Table addresses this directly. The RMP lives in secure memory and maps system physical addresses to guest physical addresses, enforcing a strict one-to-one relationship. A memory page cannot be simultaneously mapped into multiple guests, and it cannot be mapped more than once within a single guest. This constraint operates at the hardware level, not through software policy. Remapping attacks that exploit the gap between encryption and integrity are structurally precluded.

The AMD Secure Processor, an ARM Cortex-A5 coprocessor integrated into the AMD SoC, handles key management and attestation. Main memory encryption runs through dedicated hardware in the on-die memory controllers. Each protected VM receives a unique VM Encryption Key generated by the AMD-SP; that key never leaves the coprocessor and is inaccessible to any x86 software. ASID tagging further isolates each VM's data within the processor and cache hierarchy. SEV-SNP raised the supported ASID key count to 1,006, up from 509 on the prior EPYC 7003 generation, meaningfully expanding multi-tenant capacity at scale.

The generational arc is not just historical context. It explains why AMD's enforcement model looks the way it does. Protections were added layer by layer into the hardware datapath itself: memory encryption in the controllers, integrity enforcement in the RMP, key isolation in a separate coprocessor. There is no single software monitor mediating these operations. The architecture evolved by distributing enforcement across hardware subsystems, and that distribution became a structural property rather than a design preference.

How Intel Designed TDX Around a Centralized Firmware Security Monitor from the Start

Intel proposed TDX in May 2021, first shipping in 4th Generation Xeon Scalable processors and expanding coverage with the 5th Generation. The design philosophy differs at its foundation, and that difference is intentional.

The central structural element is the TDX Module: a privileged firmware-based security monitor running in a new CPU execution mode called Secure Arbitration Mode. SEAM sits above both the guest and the host VMM in privilege level; neither can directly access or interfere with the TDX Module. All sensitive operations flow through it, including VM lifecycle management, memory protections, state transitions, and secure interrupt handling. The module resides in a reserved memory region defined by the SEAM Range Register.

Before any of this operates, the SEAM Loader, an authenticated code module integrated into Intel's TXT stack, verifies and loads the TDX Module into the SEAM memory range. This is the attestation anchor for the entire architecture: the security guarantee begins with the integrity of what the SEAMLDR places into SEAM. If that chain breaks, everything downstream of it is open to question.

Memory encryption runs through Multi-Key Total Memory Encryption, using AES-256-XTS. TDX is built on Intel VMX infrastructure rather than a separate security coprocessor; the security boundary is enforced entirely within the main CPU's privilege architecture. Intel consolidated enforcement into one well-defined place rather than distributing it, and that consolidation is as much a security philosophy as it is an engineering decision.

One operational property worth noting: TDX requires no application-level changes. Support is needed only at hardware and OS levels, and operating systems that do not natively support TDX can run as nested VMs inside a Trust Domain. For organizations working across diverse workload portfolios, that reduces adoption friction considerably.

The Central Divide: Centralized Software Monitor Versus Enforcement Embedded in the Hardware Datapath

The most precise statement of the architectural difference is this: TDX enforces security through a centralized, measurable software component, the TDX Module, that mediates every interaction between the hypervisor and a Trust Domain; SEV-SNP achieves equivalent enforcement through hardware mechanisms and the AMD-SP without any equivalent runtime software monitor. To understand why this works, you have to examine what each model asks the deployer to trust and what it asks them to verify.

Intel's centralization has a specific security property: the attack surface is well-defined. The TDX Module can be versioned, updated, and formally reasoned about as a discrete artifact. A security auditor can examine one thing, produce a report on that thing, and have confidence that their analysis covers the enforcement mechanism. The trust boundary is explicit. It is also, by construction, a single point of scrutiny: if the TDX Module contains an exploitable vulnerability, isolation is weakened across all Trust Domains it mediates. The surface is bounded but consequential.

AMD's decentralization distributes enforcement, and with it, the risk profile. Memory encryption running through dedicated on-die controllers is not reachable through a software vulnerability in the same way a software monitor is. The RMP enforces ownership at the hardware level. The AMD-SP operates as a physically separate coprocessor. No single software component holds all the keys, figuratively and literally. A software-layer vulnerability in AMD's stack is less likely to unravel memory isolation precisely because the isolation is enforced below that layer.

The tradeoff is auditability. Hardware correctness is harder to independently verify than firmware source. An organization doing formal compliance review can diff two versions of the TDX Module. They cannot diff two silicon revisions of the RMP in the same way. I have sat in rooms where that distinction was the whole argument, and I have seen it go both ways depending on whether the organization's primary concern was demonstrating assurance to an auditor or actually limiting blast radius in a breach scenario.

Those are not the same concern. Which one you prioritize will largely determine which architecture fits your requirements. Both assumptions are defensible; the question is which maps onto your actual threat model rather than the one you would prefer to have.

How SEV-SNP Structures Isolation Within a Single VM Using Virtual Machine Privilege Levels

VMPL, Virtual Machine Privilege Levels, is an optional SEV-SNP feature that subdivides a confidential VM's address space into four hardware-isolated layers. VMPL0 carries the highest privilege; VMPL3 the lowest. Each hardware context, expressed as a VM Save Area, is associated with a specific VMPL, and memory pages carry different permissions depending on which level is accessing them. This is not software-managed separation layered over a flat hardware surface; the privilege distinctions are enforced in hardware.

AMD has standardized the software running at VMPL0 as the SVSM, the Secure VM Service Module. SVSM is designed to absorb services that a VMM traditionally provides, including vTPM functionality and live migration support, without requiring the guest to trust the host for those services. Moving the vTPM inside the guest's own isolation boundary is architecturally consequential: it removes a trust dependency that has historically been difficult to eliminate cleanly.

In practice, a guest OS can run at VMPL1 while a more privileged in-guest security monitor runs at VMPL0. Attestation and policy enforcement can be layered entirely within the confidential VM. For workloads that require internal trust hierarchies, such as confidential containers or multi-tenant enclaves where different tenants share a VM boundary, VMPL provides a structural capability without reaching outside the isolation boundary.

TDX does not expose an equivalent intra-VM privilege layering mechanism. The TD boundary is flat from the guest's perspective; policy enforcement comes from the TDX Module outside. For designs that require layered trust inside the VM, SEV-SNP provides it natively and TDX does not. Whether that matters depends entirely on the workload architecture you are trying to build.

Where the Two Attestation Models Diverge in Online Dependency and Per-Device Granularity

Attestation is how a workload proves to a remote verifier that it is running on genuine confidential hardware in a trustworthy state. Both architectures support it; the mechanisms differ in ways that carry real operational weight.

The AMD-SP contains a Chip Endorsement Key derived from secrets fused into the chip at manufacture. The Versioned Chip Endorsement Key, VCEK, is derived from the CEK combined with the current SP firmware and CPU microcode version numbers. The attestation report therefore carries proof of both hardware identity and software stack version in a single artifact. Crucially, VCEK derivation is deterministic from chip ID and firmware version. A verifier can confirm attestation offline using only AMD's public certificate chain, without contacting AMD's service at verification time. The guest communicates directly with the AMD-SP to produce the report; no VMM involvement is required in that path. AMD also introduced the VLEK, Versioned Loaded Endorsement Key, which identifies a specific cloud provider rather than an individual chip. That trades per-device granularity for operator-controlled identity, a deliberate design choice for deployments where provider identity is the relevant binding.

TDX bootstraps remote attestation through SGX infrastructure. A TD-quoting enclave converts the TDX attestation report into a quote that the VMM must relay. Each Intel CPU is provisioned at manufacture with a unique fused secret; Intel's Provisioning Certification Service issues PCK certificates derived from that secret, and the verifier checks the quote's signature against the PCK certificate chain back to Intel's root CA. DCAP, Data Center Attestation Primitives, allows operators to run a local cache of PCK certificates, reducing but not eliminating the dependency on Intel's online service. The attestation path involves more parties: the guest, the TDX Module, the TD-quoting enclave, and the VMM all participate.

The offline verification question is where this gets practically consequential. SEV-SNP's deterministic VCEK derivation makes fully offline verification achievable in a straightforward way. TDX's model requires infrastructure to manage the PCK certificate cache, and that infrastructure has dependencies. Every verification event that requires reaching an external service is an operational variable that an air-gapped or high-sensitivity deployment may simply be unable to accept. That is not a theoretical concern; it is a deployment constraint that eliminates one architecture from consideration before any other evaluation criterion comes into play.

What Each Architectural Choice Implies for the Trust Surface a Deployer Is Accepting

Choosing between these architectures is ultimately a question of which trust surface you are willing to accept and which kind of security assurance you have the operational capacity to verify.

With TDX, the deployer trusts a specific, versioned, Intel-signed firmware artifact, the TDX Module, that can be measured and audited. They trust Intel's certificate infrastructure for attestation verification. They trust the integrity of the SEAM execution environment within the main CPU. The advantage is that the trust boundary is explicit and diff-able across versions. For organizations conducting formal security reviews or compliance audits, a discrete software artifact is easier to reason about than distributed hardware mechanisms. You can point to a thing, measure it, and produce evidence that you did. That evidentiary property matters in regulated environments, and anyone who tells you otherwise has not spent time in one.

With SEV-SNP, the deployer trusts the AMD-SP coprocessor and its firmware, a physically separate processor with its own attack surface. They trust the correctness of the RMP hardware implementation and the on-die memory encryption controllers. They trust AMD's root CA for certificate chain verification, though offline validation is achievable. The structural advantage is the absence of a single runtime monitor: there is no software component whose compromise unravels all isolation simultaneously. The disadvantage is that hardware correctness is inherently harder to independently verify than firmware source, and that difficulty does not disappear simply because the design is elegant.

VMPL adds an intra-VM trust structuring capability on the AMD side with no TDX counterpart. For multi-layer confidential workloads, that capability may be the deciding factor. SEV-SNP's offline attestation verification may be the deciding factor for air-gapped or privacy-sensitive deployments. TDX's explicit, auditable enforcement boundary may be the deciding factor for organizations doing formal compliance work where a discrete software artifact is a prerequisite for review.

The architectural divergence between these two technologies reflects distinct theories about where security is best anchored. AMD distributed it across hardware. Intel consolidated it into auditable firmware. Both choices carry implications that propagate through deployment architecture, operational tooling, and the kinds of assurances you can make to the parties relying on your infrastructure. What I find unresolved, even after working through both architectures in detail, is whether the industry's growing preference for attestation-heavy verification workflows will eventually favor TDX's explicit auditability or whether the structural depth of SEV-SNP's hardware enforcement will prove more durable as the threat landscape evolves. That question does not have a clean answer yet. Being clear about which one you are actually optimizing for requires understanding what each architecture decided, why it decided it, and what you are implicitly accepting when you choose either.