Intel TDX vs AMD SEV-SNP Architecture Differences

Intel TDX and AMD SEV-SNP both claim to protect virtual machines from a hypervisor that has been compromised or simply cannot be trusted. They arrive at that protection through structurally different hardware designs, and those differences carry real consequences for trust, performance, and attestation that a "confidential computing" label does not communicate on its own.

Both platforms grew out of the same frustration with Intel SGX, an earlier enclave-based trusted execution environment, because it demanded invasive changes to application code before it could protect anything. Virtual-machine-level TEEs removed that requirement, so you could run unmodified workloads inside a protected boundary, and that single change is largely what pulled cloud providers toward adopting the technology at scale. But the convergence stopped at the user-facing abstraction. That difficulty is no longer academic. The sections that follow work through each platform component by component, because the tradeoffs here only make sense once the mechanisms behind them are visible.

Intel TDX's trust boundary around the TDX Module in SEAM mode

Intel's central design decision was to put enforcement in one place. TDX concentrates its security logic in a single privileged firmware component called the TDX Module, which runs in a new CPU execution mode called SEAM, positioned below both the guest operating system and the host hypervisor. Every sensitive operation between the hypervisor and a Trust Domain has to pass through that module.

Three components work together to make this arrangement function. The processor's VMX instruction-set extensions were extended so they could express Trust Domain semantics, giving it a vocabulary for the new isolation boundary. Memory encryption is applied per Trust Domain using AES-XTS with 128-bit keys, and when integrity protections are turned on, a MAC built from a SHA-3 variant is generated for private memory; if that MAC check fails, the Trust Domain is terminated outright. The TDX Module itself handles VM lifecycle management, memory protection, state transitions, and secure interrupt handling, all from inside the SEAM privilege layer. Together these three pieces make up what the research community calls TDX's centralized software monitor.

This centralization has a measurable cost that shows up later in the performance data: empirical analysis from TUM points to the TDX Module's mandatory intervention during context switches as the most probable explanation for TDX's higher VMEXIT latency compared to SEV-SNP. Intel rolled TDX out carefully rather than all at once. It arrived first as a limited offering through select cloud service providers on 4th-generation Xeon Scalable Processors, then it became broadly available with the 5th generation.

TDX bootstraps its own trust by using SGX enclaves internally to stand up remote attestation, so SGX's own trust infrastructure becomes a dependency inside TDX's chain of trust. That dependency expands the trusted computing base TDX ultimately relies on, a point that matters more once the attestation and tradeoff discussions later in this piece revisit it.

AMD SEV-SNP's distributed enforcement across hardware without a runtime software monitor

AMD took a different route to the same destination. SEV-SNP achieves memory isolation and integrity with no runtime software monitor; it builds enforcement straight into the hardware datapath through the Reverse Map Table, the AMD Secure Processor, and per-VM memory encryption. This decentralized model lets security guarantees live in silicon rather than in firmware logic that has to run and be trusted at every step.

Understanding what SNP contributes requires looking at the stack it was built on. The original SEV generation encrypted memory per VM, with the AMD Secure Processor managing the keys. SEV-ES added encryption of CPU register state across VM exits, so it shut a channel where sensitive data could otherwise leak to the hypervisor. SEV-SNP then added Secure Nested Paging, implemented through the Reverse Map Table, which tracks who owns each page of memory and blocks two distinct attack classes: memory aliasing, where two guest physical addresses get mapped to the same underlying system physical address, and replay attacks, where an old ciphertext copy of a page gets substituted back in.

The Reverse Map Table is the structural centerpiece of the whole design. It enforces a strict rule that each system physical page belongs to exactly one entity at a time, and when you launch a guest, page validation cryptographically ties every page to the VM's initial image measurement. Formal verification work from the University of Florida, done in collaboration with AMD, models SEV's enforcement guarantees as a set of properties for confidentiality, integrity, and availability that can actually be proven rather than just asserted. That kind of verification is easier to pursue here precisely because the hardware-decentralized model draws a cleaner formal boundary around what needs to be checked. SEV-SNP ships on AMD EPYC processors starting with the third-generation "Milan" microarchitecture, and it is already available across all three major cloud providers.

One architectural feature deserves attention here because it resurfaces later. SEV-SNP supports VMPL-level page permissions, a fine-grained access control scheme operating inside the VM itself. A privileged agent running at VMPL0 can hold pages that the rest of the VM has no access to, which opens design possibilities that a purely centralized monitor does not offer.

How memory protection works in each architecture

Memory is where these two philosophies produce their sharpest, most concrete contrast. TDX enforces memory integrity through the TDX Module's active mediation, backed by cryptographic MAC checking at the hardware level. SEV-SNP enforces the same guarantee structurally, through the Reverse Map Table's ownership invariants, with no equivalent active monitor standing watch. Each approach buys something the other does not, and each pays a price the other avoids.

When integrity protections are enabled, a SHA-3-256 MAC covers private memory, which is also encrypted with AES-XTS 128-bit encryption per Trust Domain using keys inaccessible in SEAM mode to the host, and a failed validation check terminates the Trust Domain outright, a hard stop rather than a graceful degradation. You cannot get direct memory access to Trust Domain memory outside SEAM mode, so an entire category of attack is closed off at the architectural level.

SEV-SNP's mechanics look different because they rely on structure rather than active checking. The Reverse Map Table tracks exactly one owner per system physical page, and any attempt by the hypervisor to remap or alias those pages violates the RMP invariant and gets blocked in hardware before it can do anything. Page validation at launch ties the VM's initial memory state to its attestation measurement, so it functions as a structural defense against replay attacks rather than an active cryptographic check performed on every access. And the VMPL scheme lets you split page permissions within the VM itself, so a hardware-protected agent at VMPL0 can hold pages the rest of the guest cannot touch.

That VMPL capability turns out to matter well beyond memory protection theory. The RealmEye paper describes a system called 00SEVen that restores virtual machine introspection on SEV-SNP by hosting a hardware-protected agent at VMPL0, a capability the paper describes as something that "simply does not exist on Arm CCA." The same paper separately notes that TDX has no equivalent introspection solution. VMPL, in other words, creates an architectural affordance that the centralized enforcement model has no direct way to replicate.

What should a reader take from this? Neither design is strictly better at memory protection. TDX trades flexibility for a hard, auditable enforcement boundary, so you get a single point of mediation. SEV-SNP trades that centralized checkpoint for distributed guarantees that hold up under formal verification and leave room for features like introspection that a monitor-based design forecloses. The same test that separates genuine architectural commitment from surface-level promises applies outside of silicon too. Privacy-preserving AI systems face an identical test: a system that claims to protect data has to be evaluated on how its architecture actually enforces that protection, not on the label it carries, as regulatory pressure from the EU AI Act, FedRAMP modernization efforts, and national data sovereignty mandates turns that evaluation into a compliance-architecture question rather than just a performance one.

How each architecture roots and propagates attestation trust

Memory protection answers the question of what happens inside the VM. Attestation answers a different question: how does anyone outside the VM come to trust what is happening inside it? TDX and SEV-SNP answer that question through genuinely different trust chains. TDX anchors its root of trust in Intel's manufacturing infrastructure and uses SGX enclaves internally to bootstrap the whole process. SEV-SNP anchors its root of trust in the AMD Secure Processor, and it expresses that trust through a machine-unique key derived from hardware secrets. Those different roots carry different operational consequences for anyone deploying either platform.

TDX's attestation chain starts with a centralized root of trust inside Intel's manufacturing infrastructure. SGX enclaves get used internally within that bootstrap process, meaning SGX's trust model is not an optional feature but a dependency that TDX's own attestation relies on. In practice, you can verify that a specific code image is genuinely running inside a TDX-protected VM before you send any sensitive data over, by using a DCAP-style verification stack to check the proof.

SEV-SNP's chain works differently from the first step. A guest VM initiates an attestation request to the AMD Secure Processor using the SNP_GUEST_REQUEST ABI command. The Secure Processor then generates a cryptographically signed report that covers the VM's configuration, its initial memory measurement, and its TCB version. That report gets authenticated using either the VCEK, a machine-unique ECDSA key pair derived from the specific hardware's unique secret combined with its TCB version, or the VLEK. Remote attestation runs through the AMD Key Distribution Service, and that ties the measurement back to AMD's hardware certificate chain. The TCB versioning embedded in that report matters in practice: it lets a relying party distinguish between a VM running on patched, current firmware and one running on an older TCB state, a distinction that becomes operationally important whenever a vulnerability gets patched and attestation needs to reflect which machines actually received the fix.

Neither platform solves this structural limitation: both platforms share it equally. Neither attestation flow binds the cloud provider itself into the report. The report proves which code is running and on which hardware, but it offers no guarantee that the provider has not influenced the surrounding environment in ways the measurement never captures. That gap sets up a natural question for anyone evaluating either platform for a genuinely sensitive workload: what does the attestation actually rule out, and what does it simply not reach? TDX's architectural choice to concentrate enforcement in one trusted component reflects a broader design principle that extends well past silicon: a trust boundary has to be explicit and defensible, with every party inside it named and accounted for. Software systems face the same requirement. Confidant AI's architecture, for instance, is built around minimizing the number of trusted parties and making clear exactly where enforcement happens, which is the same question attestation is trying to answer for TDX and SEV-SNP at the hardware level.

The performance difference between TDX and SEV-SNP

The performance gap between these two platforms is a direct expression of the enforcement model each one chose. TDX's substantially higher VMEXIT latency follows from the TDX Module's mandatory interposition on every context switch, which makes the overhead an architectural fingerprint rather than an artifact of a particular implementation or driver.

The TUM empirical analysis, presented at ACM SIGMETRICS, measured VMEXIT latency for instructions that require an exit and found a substantially larger average increase under TDX than under SEV-SNP. The analysis points to the TDX Module's intervention during context switches as the most probable cause.

The overhead does not distribute evenly across workload sizes, and the shape of that distribution tells its own story about where each design pays its price. Under TDX, overhead concentrates heavily at small workloads, running up to roughly three-quarters additional cost, then drops sharply as workloads grow larger, falling to roughly one-tenth overhead at scale. SEV-SNP's overhead spreads more evenly across workload sizes: a smaller peak at the small end, a larger residual cost at the large end, but microbenchmark results show more efficient thread creation and scheduling, which supports better scalability overall.

What does this pattern actually mean for someone choosing a platform? For latency-sensitive or I/O-heavy workloads that trigger frequent context switches, TDX's centralized enforcement model carries a real, measurable cost. For large, compute-bound workloads, TDX's overhead advantage narrows considerably, and the difference may matter less. A Computers & Security study provides corroborating experimental data across SGX, SEV, and TDX workloads, reinforcing that overhead is workload-dependent rather than a fixed property that favors one platform universally. These numbers are the measurable signature of two different answers to the same design question: where should enforcement live, and what does it cost to put it there?

TDX's heterogeneous compute integration and SEV-SNP's cloud breadth

Architecture eventually becomes deployment reality, and TDX and SEV-SNP have converted their internal design choices into two distinct ecosystem positions. TDX has moved faster toward extending confidential computing beyond the CPU to GPUs and other accelerators through TDX Connect. SEV-SNP has moved faster toward broad multi-cloud availability. For AI workloads specifically, these are not interchangeable advantages, and which one matters more depends heavily on what is actually being built.

Intel is extending TDX Connect on Xeon 6 processors to cover not just the CPU but supporting devices including GPUs, Smart NICs, and storage devices. The problem this solves is specific and concrete: Intel TDX and NVIDIA's Confidential Computing modes both create trusted execution environments, but the PCIe interconnect carrying data between them was previously unprotected, leaving DMA operations exposed to plaintext on an unencrypted channel. The reference implementation pairs Intel TDX-enabled Xeon platforms with NVIDIA H100, H200, Blackwell B200, and B300 GPUs running in Confidential Computing mode, closing that gap for workloads that span both kinds of hardware.

SEV-SNP's advantage runs in a different direction. It is already available across all three major cloud providers, so it is the more broadly accessible of the two mature VM-level confidential computing platforms today. For a team evaluating where to deploy a sensitive workload right now, that breadth often outweighs a feature set still rolling out on newer silicon. For a team building AI infrastructure that spans CPU and accelerator confidential computing together, TDX Connect's reach across the PCIe boundary addresses a problem SEV-SNP's current deployment model does not yet solve in the same way. Neither position makes the other platform wrong. Each one reflects, once again, the same underlying architectural commitment each company made at the very start: concentrate enforcement in one place and extend it outward, or distribute enforcement across hardware and extend it everywhere the hardware already runs.