When a procurement team asks "should we run our confidential VMs on AMD or Intel," the honest answer is that both chips solve the same problem with different plumbing. AMD SEV-SNP vs Intel TDX is no longer a theoretical debate — AWS, Azure, and Google Cloud all sell both, and the choice affects your attestation pipeline, your key management, and your incident-response playbook. SEV-SNP shipped commercially in 3rd Gen EPYC "Milan" processors in March 2021; TDX arrived almost two years later in 4th Gen Xeon "Sapphire Rapids" in January 2023. Under the hood, they encrypt memory differently, attest differently, and have accumulated different CVE histories. This post breaks down the concrete technical differences that matter when you're deciding where to place a workload that handles secrets, customer data, or regulated financial information.
What actually is AMD SEV-SNP vs Intel TDX at the architecture level?
AMD SEV-SNP isolates individual virtual machines by encrypting each VM's memory with its own ephemeral AES key managed by an on-die AMD Secure Processor (a separate ARM Cortex-A5 core embedded in the silicon), while Intel TDX isolates VMs inside "trust domains" managed by a CPU-resident module called the TDX Module that runs at a new privilege level below the hypervisor. SEV-SNP is the fourth iteration of AMD's confidential computing line — after SEV (2016), SEV-ES (2017), and SEV-SNP itself (2020 spec, 2021 silicon) — and it adds Secure Nested Paging specifically to close the memory-remapping and replay attacks that plagued the earlier two versions. TDX, by contrast, is Intel's first production confidential-VM technology; there was no direct predecessor shipped at scale (SGX addressed enclaves, not whole VMs). That history matters: SEV-SNP's design is a patch on top of three prior generations, while TDX was designed from a blank sheet with knowledge of what had already gone wrong with AMD's and Intel's own earlier enclave work. Both models keep the hypervisor out of the VM's memory and register state, but they draw the trust boundary in slightly different places — SEV-SNP still allows a malicious hypervisor to control scheduling and I/O timing, and so does TDX, so neither eliminates side-channel risk from a compromised host.
How does memory encryption technology differ between the two platforms?
AMD SEV-SNP encrypts memory per-VM with AES-128 in XEX mode using a unique key generated and held by the AMD Secure Processor, while Intel TDX uses Intel's Multi-Key Total Memory Encryption (MKTME) with AES-XTS-128 keys assigned per trust domain by the TDX Module. Neither vendor currently ships AES-256 for the per-VM data path in mainstream parts, which has drawn criticism from cryptographers who note that 128-bit keys, while still computationally infeasible to brute-force, offer a smaller security margin than the AES-256 used by some competing memory encryption technology in HSMs and confidential storage products. A more practically important distinction is integrity protection: SEV-SNP adds a reverse map table (RMP) checked on every memory access to prevent the hypervisor from remapping or replaying encrypted pages, closing the class of attacks (like the 2021 "CipherLeaks" side channel) that affected plain SEV and SEV-ES. TDX achieves comparable integrity guarantees through its own extended page tables enforcement inside the TDX Module, plus MKTME's built-in ciphertext integrity checks introduced specifically for TDX (branded "TME-MK integrity"). In practice, both now block the memory-remapping attacks that made headlines in 2020-2021; the remaining gap is that SEV-SNP's protections are bolted onto an older base architecture, whereas TDX's were native to the design from day one.
How does an attestation comparison between SEV-SNP and TDX actually shake out?
An attestation comparison shows AMD relying on a signed hardware report chained back to a versioned key hierarchy (ARK to ASK to VCEK), while Intel TDX relies on a quote generated by the TDX Module and verified through the same DCAP infrastructure Intel built for SGX. AMD's chain-of-trust runs through the AMD Root Key, an AMD Signing Key, and a Versioned Chip Endorsement Key that's unique per-chip and per-firmware-version, which lets a relying party check the exact microcode patch level the CPU is running before trusting a report. Intel's TDX quotes carry TCB (trusted computing base) info that must be verified against Intel's Provisioning Certification Service, and because DCAP was reused from SGX, cloud tooling and open-source attestation verifiers (like Intel's own tdx-attest libraries) matured faster — TDX attestation tooling had roughly a year's head start in ecosystem terms despite shipping in silicon after SEV-SNP, since Intel reused SGX's remote-attestation stack rather than building one from scratch. Both models expose the measurement of the initial VM image plus runtime measurement registers, so a verifier can confirm both "what booted" and "what patch level the CPU firmware is at" — but AMD's key hierarchy is publicly documented in more implementation detail, while Intel gates some TCB recovery data behind its certification service, which has occasionally caused verification lag when Intel pushes microcode updates faster than certificate data propagates.
What CVEs have hit each platform, and how serious were they?
AMD SEV-SNP and its predecessors have had more publicly disclosed, higher-severity CVEs than TDX, largely because SEV has existed since 2016 and drawn more research attention. Notable examples: CVE-2023-20592 ("CacheWarp," disclosed October 2023) let an attacker roll back memory writes inside an SEV-SNP guest, potentially enabling privilege escalation inside the VM; CVE-2023-20583 (a SQUIP scheduler-queue issue) affected Zen 3 EPYC parts running SEV workloads; and CVE-2020-12967 demonstrated that early SEV (pre-SNP) allowed a malicious hypervisor to inject arbitrary code by exploiting the lack of integrity protection — the exact gap SEV-SNP was built to close. Intel TDX's disclosed issues have so far been narrower: CVE-2024-21925 and CVE-2024-27457 involved TDX Module and SEAM (Secure Arbitration Mode) boundary-check bugs patched in Intel's Q1 2024 microcode updates, and researchers have also shown Meltdown/Spectre-class transient-execution issues can still leak data across the TDX boundary under specific conditions, since TDX inherits Intel's general speculative-execution attack surface. Neither company's confidential computing chip security has been immune to side-channel research; the practical takeaway is that AMD's longer market presence means a longer, more battle-tested CVE list, not necessarily a less secure design — and both vendors have shipped fixes within weeks of disclosure in every case above.
Which cloud providers support each, and does the choice actually matter for procurement?
Yes, it matters, because availability and default configuration differ by provider and region. Google Cloud was first to general availability with AMD SEV in 2020 and added SEV-SNP support on N2D machine types in 2022; it followed with Intel TDX general availability on C3 machine types in September 2023. Microsoft Azure shipped SEV-SNP-backed confidential VMs (the DCasv5 and ECasv5 series) to general availability in 2022, and added TDX-backed DCesv5/ECesv5 confidential VMs to general availability in 2023. AWS has taken a different path entirely: its Nitro Enclaves and Nitro System provide memory isolation and attestation through AWS's own custom hypervisor and Nitro Security Chip rather than licensing either AMD SEV-SNP or Intel TDX directly, which means "AMD SEV-SNP vs Intel TDX" isn't even the relevant question if you're deploying on AWS-only infrastructure. For teams running mixed or multi-cloud fleets, this means your confidential computing chip security posture can quietly change when a workload migrates between providers or even between instance families on the same provider — a workload attested against a VCEK chain on Azure DCasv5 needs an entirely different attestation-verification path if it's later moved to a TDX-based DCesv5 instance.
How Safeguard Helps
Safeguard treats the choice of confidential computing hardware as a supply-chain attestation problem, not just an infrastructure decision. When your build and deployment pipeline spans both AMD SEV-SNP and Intel TDX fleets, Safeguard normalizes attestation evidence from both chains — AMD's VCEK-based hardware reports and Intel's DCAP-verified TDX quotes — into a single provenance record attached to each artifact and workload identity. That means your SBOM, your signing keys, and your deployment gates don't need separate logic for "if AMD" versus "if Intel"; Safeguard validates the TCB level, firmware version, and measurement register state against your policy regardless of which vendor's silicon is underneath, and flags any workload running on a CPU microcode version with a known open CVE (including the CacheWarp and TDX Module issues discussed above) before it ships. For teams building on confidential computing to meet SOC 2, FedRAMP, or customer data-isolation commitments, Safeguard also keeps an auditable trail showing which attestation chain verified which deployment, so a compliance review doesn't turn into a manual reconciliation between two vendors' documentation. If you're weighing AMD SEV-SNP vs Intel TDX for a new workload, Safeguard can tell you, from your own pipeline data, which platform your existing tooling already attests cleanly against — and where you'd need new verification logic before you commit.