Confidential Computing Explained: Intel TDX vs AMD SEV-SNP 2026

The Missing Third Data State

Security teams talk about two data states almost by reflex: at rest (disk encryption) and in transit (TLS). The third state — data in use, meaning whatever sits decrypted in system memory while a CPU processes it — remained structurally unprotected until hardware vendors shipped silicon capable of computing on encrypted data without ever exposing plaintext to the host operating system. Confidential computing is that missing piece of the encryption lifecycle.

This matters more in 2026 than it did a few years ago because the workloads people want to protect have changed. Running AI inference or training against sensitive data — patient records, transaction histories, defence intelligence — makes plaintext exposure in a shared cloud host unacceptable for a growing number of UK organisations, regardless of how strong the perimeter security around that host is.

How Trusted Execution Environments Actually Work

A Trusted Execution Environment (TEE) is a hardware-enforced boundary. Confidential VMs built on Intel TDX and AMD SEV-SNP cryptographically isolate memory and CPU state so that no host admin and no hypervisor process — including the cloud provider's own operators — can view or modify them. The trust model is effectively inverted: instead of trusting the cloud operator, you trust the silicon.

The proof mechanism is cryptographic attestation. Before a workload is trusted, the platform signs a report containing platform identity, firmware measurements and a verifier-supplied nonce, allowing a remote party to confirm the workload is running genuine, unmodified code inside a real TEE — not a spoofed or tampered environment.

• •Memory encryption — unique per-VM keys prevent the host from reading guest RAM
• •CPU state isolation — registers and execution state are shielded from the hypervisor
• •Attestation reports — signed proof of platform identity and code integrity
• •Hardware-protected virtual TPMs — certify VM health and support hardened key management such as BitLocker on Azure confidential VMs

Intel TDX vs AMD SEV-SNP: The Technical Detail

Intel TDX uses Multi-Key Total Memory Encryption (MKTME) to give each Trusted Domain its own unique AES-128-XTS key, isolating that domain's memory from both the hypervisor and the host OS. Because TDX has no dedicated security processor, its attestation chain relies on a quoting enclave — itself an SGX enclave — using the SEAMREPORT instruction to generate trust quotes. If you're speccing platforms for this, it's worth understanding the underlying silicon; Intel Xeon 6 processors are the current generation carrying TDX support.

AMD SEV-SNP takes a different architectural route, adding Secure Nested Paging to stop hypervisor-based attacks on guest page tables. It encrypts memory at runtime, restructures page tables so the host cannot read or tamper with them, and introduces launch-time attestation to verify guest memory integrity from the moment a VM boots. On the hardware side, this is the confidential-computing feature set built into AMD EPYC Turin processors.

In practice, the two aren't interchangeable choices — they suit different risk profiles. AMD SEV-SNP is generally preferred for CPU-heavy workloads in financial services and healthcare because of its lower performance overhead, while Intel TDX tends to win out for government, defence and high-security AI workloads where its attestation model is considered the stronger assurance.

Real-World Performance Overhead

Confidential computing isn't free, and the overhead varies significantly by workload shape — this is the detail most explainers skip entirely. For AMD SEV-SNP specifically, CPU-intensive workloads see roughly 2–5% overhead, while memory-intensive applications run 5–10% slower, reflecting the extra cost of encrypting and checking memory on every access.

A separate empirical analysis of AMD SEV-SNP found memory access overhead of up to 7% from encryption alone, with memory latency increasing by as much as 5x in some access patterns. More strikingly, worst-case scenarios involving excessive context switching and memory copy operations showed overhead spiking as high as 400% — a figure that applies specifically to that pathological pattern, not to typical steady-state workloads.

The practical takeaway: don't assume a flat overhead percentage. Database or virtualisation-heavy workloads with frequent context switches need benchmarking before migration, because they sit at the extreme end of this range while straightforward CPU-bound analytics or inference jobs sit much closer to single digits.

Cost Implications for UK Buyers

No major provider publishes a specific GBP price list for confidential instances, but industry estimates put confidential VMs at roughly 15–25% more expensive than equivalent standard instances on public cloud. That premium needs to be weighed against what it buys: a technical, auditable answer to "can your provider read our data" — increasingly the question regulators and customers actually ask.

For cross-border trust concerns specifically, UK buyers should push providers on attestation locality — using UK-specific attestation services such as Azure Attestation, and ensuring secure, localized connectivity to attestation endpoints (potentially using services like AWS PrivateLink) rather than accepting a default global attestation endpoint, to avoid introducing an unnecessary offshore trust dependency into an otherwise sovereign deployment.

UK Compliance: GDPR, NCSC and Sector Regulation

Confidential computing gives UK organisations something GDPR Article 32 has always asked for but rarely got: technical, verifiable evidence of security of processing, rather than a contractual promise. Attestation reports provide auditors with cryptographic proof that a workload ran in an isolated, unmodified environment — this is a materially stronger compliance artefact than a cloud provider's standard terms and conditions.

This lands hardest in regulated sectors. NHS bodies running AI against healthcare data, FCA-regulated finance firms processing transaction histories, and MOD-adjacent defence work all share the same underlying problem — needing to run compute against data too sensitive to expose in plaintext to a third-party host. NIS Regulations obligations and emerging AI Act compliance both benefit from TEE-based attestation reducing the audit burden on regulated workloads. If data-in-use protection is part of a wider security review, it's worth pairing with our cybersecurity solutions guidance covering the rest of the stack.

Practical Implementation: Steps and Pitfalls

Migrating a sensitive workload typically follows a similar pattern: identify the workload and its regulatory driver, choose TDX or SEV-SNP based on whether attestation strength or lower overhead matters more, provision the confidential VM instance on your chosen cloud, and build attestation verification into the deployment pipeline rather than treating it as a one-off check. On Azure, this can be paired with a hardware-protected virtual TPM to certify VM health and support hardened key management such as BitLocker.

Underneath the VM abstraction, TDX and SEV-SNP are CPU primitives for hardware-assisted confidential virtualisation — they enforce hardware-level separation between system software and the confidential VM itself, which means the guest kernel has to be built or configured to run inside that isolated mode rather than treated as a drop-in image. AMD SEV-SNP specifically restructures guest page tables to exclude host access and performs launch-time attestation of guest memory integrity at boot, so the measured boot chain — firmware plus initial kernel state — becomes part of what's actually being verified, not something bolted on afterwards. The virtual TPM integration used for BitLocker-style key management on Azure confidential VMs is itself a guest-OS-level touchpoint, not something that happens transparently underneath the operating system.

The pitfalls are operational rather than conceptual. Attestation adds a verification step that has to be automated and monitored, not just run once at deployment. Debugging is genuinely harder — host-level tooling that used to inspect guest memory for troubleshooting simply can't see inside an encrypted enclave, which changes how incident response and performance diagnostics work. Existing security and monitoring agents also often need TEE-aware versions, since standard host-based tooling has no visibility into what it's supposed to be protecting. For organisations weighing cloud confidential VMs against an on-premises or hybrid build using TEE-capable CPUs, it's worth working through the options when you configure a server.

• •Cost: confidential VMs carry a 15–25% premium over standard public cloud instances — on-premises ownership of TEE-capable CPUs (Xeon 6, EPYC Turin) avoids that recurring premium for steady-state regulated workloads, at the cost of upfront hardware investment
• •Attestation control: on-premises deployments keep the entire attestation chain and firmware measurement baseline in-house; public cloud means trusting the provider's attestation service unless you specifically insist on UK-specific endpoints such as Azure Attestation or AWS PrivateLink
• •Audit burden: both models produce the same cryptographic attestation reports as GDPR Article 32 evidence, but on-premises removes any cross-border data residency question entirely — relevant for MOD-adjacent or NHS workloads
• •Workload fit: match Intel TDX (stronger attestation, favoured for government/defence/high-security AI) or AMD SEV-SNP (lower overhead, favoured for finance/healthcare) to the workload, regardless of whether it's hosted in public cloud or on-premises

Confidential AI and the Future Beyond 2026

The clearest driver behind confidential computing's mid-2026 momentum is AI on sensitive data. Running inference or training workloads against regulated datasets without exposing plaintext to the cloud provider is becoming a baseline requirement rather than a nice-to-have, and it's the use case pushing TDX and SEV-SNP adoption fastest across UK cloud deployments.

It's worth being clear-eyed about scope: confidential computing is highly effective against the most common cloud privacy concern — the provider itself accessing customer data — but it leaves residual risks that still require complementary controls such as network security, access management and endpoint protection. It closes one specific, previously-open gap in the encryption lifecycle; it doesn't replace the rest of a security programme.

Sources

Every figure in this article traces to the sources below.

• •Stealth Cloud — confidential computing deep dive and threat model scope
• •Onidel — AMD SEV-SNP vs Intel TDX performance overhead and workload fit
• •Red Hat — Intel TDX quoting enclave and attestation architecture
• •Microsoft Azure Docs — confidential VM FAQ, TDX/SEV-SNP feature comparison
• •Ian Klatzco — cryptographic attestation mechanics
• •Ubuntu — confidential computing trust model explanation
• •ServerMall — TEE tenant isolation and regulated workload use cases
• •Sekyourity Blog — AMD SEV-SNP and Intel TDX hardware primitives detail
• •1C Confidential VMs (YouTube) — empirical memory and context-switch overhead figures