Beyond Encryption · Part 2 of 7
Comparing the hardware trust boundaries behind AMD SEV-SNP, Intel TDX and Intel SGX.
TL;DR
- AMD SEV-SNP protects a complete virtual machine. It encrypts guest memory and CPU state, and adds integrity controls designed to stop a malicious hypervisor from replaying or remapping private pages.
- Intel TDX also protects a complete virtual machine, called a Trust Domain. It is the closest architectural alternative to SEV-SNP for lift-and-shift workloads.
- Intel SGX protects selected application enclaves inside a process. The boundary can be much smaller, but the application must be designed or adapted for enclave execution.
- A smaller boundary can reduce the trusted computing base, but usually increases engineering complexity.
- Attestation is not a health certificate for the whole application. It is signed evidence about a measured environment. A relying party still needs a policy, trusted reference values, freshness checks and a response such as releasing or withholding a key.
- In Azure, AMD SEV-SNP and Intel TDX back Confidential VM families. Intel SGX on DCsv3 and DCdsv3 is a separate application-enclave VM offering and does not belong in the Azure Confidential VM family table.
Table of contents
- Start with the isolation boundary
- AMD SEV-SNP: a protected virtual machine
- Intel TDX: a protected Trust Domain
- Intel SGX: a protected application enclave
- Comparison table
- Attestation and the trusted computing base
- Current Azure product mapping
- How to choose
- Common architecture mistakes
- Key takeaways
Start with the isolation boundary
The most useful first question is not which processor is newer. Ask what must be protected from what.
SEV-SNP and TDX place the boundary around a virtual machine. The guest operating system, its kernel, services, libraries and applications all run inside the protected VM. This model is attractive when an organisation wants stronger isolation from the cloud host without redesigning an existing workload.
SGX places the boundary around an enclave within an application process. The operating system and ordinary process memory remain outside the enclave. Only the selected code and data entering the enclave receive SGX protection. This can create a smaller and more precisely defined trusted computing base, but it also creates explicit transitions between trusted and untrusted code.
Figure 1. VM-level and enclave-level trust boundaries. Original Interian editorial visual.
The diagram also reveals an important nuance. A confidential VM protects the guest from the host, but it does not automatically protect one application inside the guest from a compromised guest administrator or kernel. An SGX enclave can retain a boundary against that local operating system, provided that the enclave code, its interfaces and its data flow have been engineered correctly.
AMD SEV-SNP: a protected virtual machine
AMD Secure Encrypted Virtualisation uses keys managed by the AMD Secure Processor to separate virtual machines from each other and from the hypervisor. SEV-SNP is the generation that combines memory encryption, encrypted guest register state and stronger integrity protections.
What is protected
The main security unit is the VM. Private guest memory is encrypted with a VM-specific key before it leaves the processor package. Guest register state is protected when control returns to the hypervisor. AMD also adds the Reverse Map Table, or RMP, which records the ownership and state of protected physical pages.
The RMP matters because encryption alone is not sufficient. A hostile hypervisor controls second-level page tables in a conventional virtualisation design. Without additional checks, it might replay old ciphertext or map a guest physical page to an unexpected system physical page. SEV-SNP validates page ownership and mappings to make those classes of attack substantially harder. AMD describes SNP as protecting against replay and memory remapping attacks by a malicious hypervisor.
Pages can be private or shared. Private pages stay inside the encrypted guest boundary. Shared pages support explicit communication with the hypervisor or emulated devices. This transition deserves architectural attention because shared buffers are not confidential merely because the rest of the VM is confidential.
Attestation
An SEV-SNP guest can obtain a signed attestation report. The report includes a launch measurement, security version information, policy fields and caller-supplied report data. The report is signed through AMD’s endorsement hierarchy, using a Versioned Chip Endorsement Key for the processor and firmware state.
This enables a verifier to ask useful questions. Is this genuine SEV-SNP hardware? Is debug disabled? Is the reported firmware security version acceptable? Does the launch measurement match an approved image or workload? Is a nonce or public-key hash bound into the report so that evidence cannot simply be replayed in another session?
Development impact and limitations
For many server applications, the development impact is low. A supported operating system image and drivers do most of the platform work. The application can remain unchanged if the requirement is VM-level isolation.
Low application impact does not mean no architecture work. DMA and device paths, shared memory, boot configuration, image provenance, update policy, observability and key release still need deliberate design. Unsupported platform features can also affect recovery and operations. In Azure, for example, Confidential VMs have feature limitations such as no live migration and no boot diagnostic screenshots. Those service constraints are separate from the processor’s cryptographic properties.
Intel TDX: a protected Trust Domain
Intel Trust Domain Extensions creates an isolated VM environment called a Trust Domain, or TD. The security objective is similar to SEV-SNP: protect guest memory and CPU state from the hypervisor, host software and other VMs while retaining a familiar VM programming model.
What is protected
TDX uses processor extensions and a security module to manage Trust Domains. Private TD memory is encrypted and integrity protected. Access checks prevent ordinary host software from reading or modifying private TD pages. The virtual machine monitor still schedules virtual CPUs and provides I/O, but it is moved outside the confidentiality and integrity boundary for private guest state.
TDX distinguishes private and shared memory. Shared pages remain necessary for selected host interactions. As with SEV-SNP, the host-facing boundary must be treated as untrusted input and output. A protected VM does not make a virtual device or an external service trustworthy.
The TDX Module is a particularly important part of the trusted computing base. It runs in a protected processor mode and manages TD creation, memory assignment and state transitions. Platform firmware and processor microcode also matter. This is one reason why attestation policies should include acceptable security version information, not only a workload measurement.
Attestation
A TD can produce a report containing measurements and attributes of the Trust Domain. That local report is transformed into evidence that a remote verifier can validate through the Intel endorsement chain or a cloud attestation service. Measurements include the initial TD contents and configuration. Runtime measurement registers can extend the evidence model for additional components.
The relying party should still bind freshness and purpose to the evidence. A nonce resists replay. A hash of an ephemeral public key can bind the attested environment to the secure channel or key that will be used next. Without that binding, a valid report and the later secret-delivery channel may describe different endpoints.
Development impact and limitations
Like SEV-SNP, TDX is designed to support VM-level adoption with little or no application refactoring on a supported image. The operational impact is not zero. Image qualification, guest drivers, attestation tooling, regional capacity and unsupported VM features remain relevant.
Microsoft’s current Azure VM pages list DCesv6, DCedsv6, ECesv6 and ECedsv6 as TDX-backed Confidential VM families. Microsoft’s higher-level TEE page still labels the Intel TDX rehosting offering as preview, while current size pages present deployable TDX v6 series without that label. The Confidential VM FAQ also describes post-boot in-guest TDX attestation as preview and says fuller in-guest validation is still evolving. Treat service status and attestation depth as separate checks in an architecture decision.
Figure 2. Cropped official Microsoft sample output from cvm-attestation-tools. The visible claims include x-ms-attestation-type: tdxvm and x-ms-compliance-status: azure-compliant-cvm. Source: Azure Samples Confidential Computing repository. Licence: MIT. This is Microsoft sample evidence, not an Interian test result.
Intel SGX: a protected application enclave
Intel Software Guard Extensions takes a different route. An application creates an enclave and loads selected code and data into protected memory. The rest of the process, operating system, hypervisor and cloud administrator sit outside the enclave trust boundary.
What is protected
Enclave pages live in the Enclave Page Cache, or EPC. SGX checks that only the enclave can access its protected pages and encrypts data when those pages leave the processor package. Enclave identity is derived from measurements of the initial code and data, with signing identity providing another policy option.
This narrower scope is SGX’s architectural strength. A sensitive cryptographic operation, matching algorithm or data transformation can be isolated even if the guest operating system is not trusted. It is also the source of complexity. The application must define enclave entry points and outbound calls, validate everything crossing the boundary and minimise secrets copied into ordinary memory.
Attestation
SGX remote attestation allows a verifier to evaluate enclave identity, signer information, security version and platform trust. Modern deployments use the ECDSA-based Data Centre Attestation Primitives flow and Intel Provisioning Certification Service collateral. Policy can trust an exact enclave measurement or an approved signer plus a minimum security version, depending on the update model.
An exact measurement can be very restrictive because each enclave rebuild may change it. Signer-based policy is easier to operate, but it transfers more trust to release signing and version governance. Neither option removes the need for freshness, channel binding and revocation checks.
Development impact and limitations
SGX normally has the highest application impact of the three technologies. Developers must partition the application, manage enclave interfaces, use an SGX SDK or a compatible framework and reason carefully about data entering and leaving the enclave. System calls and I/O are performed through untrusted components, so return values and buffers require defensive validation.
The enclave also has finite protected memory. Paging EPC content is possible, but it can add overhead and complicate performance planning. Side channels, denial of service and unsafe enclave code remain concerns. SGX protects the enclave from privileged software reading its memory. It does not make the enclave code correct, hide every access pattern or guarantee service availability.
Comparison table
| Dimension | AMD SEV-SNP | Intel TDX | Intel SGX |
|---|---|---|---|
| Isolation unit | Complete virtual machine | Complete Trust Domain VM | Application enclave |
| Primary adoption model | Rehost or modernise inside a protected VM | Rehost or modernise inside a protected VM | Build or adapt an enclave-aware application |
| Protected memory | Private guest memory | Private TD memory | EPC pages assigned to the enclave |
| CPU state protection | Guest register state protected on VM exits | TD CPU state protected from the VMM | Enclave state protected across enclave transitions |
| Integrity approach | RMP-backed ownership and mapping checks, plus SNP integrity controls | TDX access controls, metadata and integrity protection for private TD state | Enclave page access control, integrity and measurement |
| Host interaction | Explicit private and shared pages | Explicit private and shared pages | Enclave calls and outbound calls through untrusted code |
| Typical TCB inside the workload boundary | Guest OS, drivers, services and application | Guest OS, drivers, services and application | Enclave code, selected libraries and enclave runtime |
| Application changes | Usually low | Usually low | Usually significant |
| Attested identity | VM launch and platform state | TD measurements and attributes | Enclave measurement or signer identity |
| Best fit | Existing sensitive VM workloads and broad guest isolation | Existing sensitive VM workloads on Intel-backed CVMs | Small high-value functions needing isolation from the guest OS |
This table compares security models, not absolute security. The right answer depends on the threat model, operational controls and quality of the implementation.
Attestation and the trusted computing base
Memory encryption answers one question: can an unauthorised component directly read protected memory? Attestation answers a different question: what environment produced this cryptographic evidence, and does it satisfy my policy?
A useful remote attestation flow has five parts:
- The verifier sends a fresh nonce or another challenge.
- The TEE creates signed evidence that includes measurements, attributes, security versions and challenge-bound data.
- The verifier validates signatures, certificate chains, revocation information and freshness.
- Policy compares claims with approved reference values.
- Only after a successful decision does a relying service release a key, token, model, dataset or job.
Attestation therefore belongs in an authorisation flow. Logging a successful token and then giving every VM the same long-lived secret does not materially use the evidence.
The trusted computing base, or TCB, is every component that must behave correctly for the security claim to hold. With SEV-SNP and TDX, the protected guest OS and its privileged software are generally inside the workload TCB. With SGX, the enclave can exclude the guest OS, but enclave code, SDK components and the boundary marshalling logic become critical. Outside the workload, processor microcode, TEE firmware or modules, attestation verification code and key-release policy also matter.
Smaller is often easier to reason about, but not automatically safer. A tiny enclave with a broad, weakly validated interface can be less trustworthy than a well-hardened confidential VM with simpler data flows.
Current Azure product mapping
Last technical review: 18 August 2026
The Azure portfolio is easier to understand when the two programming models are kept separate.
Azure Confidential VM families
The following table contains only Azure Confidential VM families. These protect the whole VM through AMD SEV-SNP or Intel TDX.
| TEE | General-purpose families | Memory-optimised families | Model |
|---|---|---|---|
| AMD SEV-SNP | DCasv5, DCadsv5, DCasv6, DCadsv6 | ECasv5, ECadsv5, ECasv6, ECadsv6 | VM-level Confidential VM |
| Intel TDX | DCesv6, DCedsv6 | ECesv6, ECedsv6 | VM-level Confidential VM |
Azure also lists NCCadsH100v5 Confidential GPU VMs, which combine AMD SEV-SNP with NVIDIA H100 GPUs. That is a specialised accelerator architecture and is outside this CPU comparison.
Regional availability, quota, qualified images and supported features vary. Check the Azure Confidential VM options and query the intended subscription before committing to a design.
Separate Intel SGX application-enclave offering
Intel SGX on Azure is a distinct enclave-based VM offer. DCsv3 and DCdsv3 provide SGX-capable processors and EPC capacity so enclave-aware applications can run inside a VM. They are not AMD or TDX-style Confidential VM families, and they should not be presented in the same CVM table.
The earlier DCsv2 series retired on 30 June 2026. Microsoft directed customers who still required the SGX enclave model towards DCdsv3, subject to regional availability. Microsoft also states that it will not deploy DCsv2, DCsv3 or DCdsv3 in new Azure regions. That makes region strategy and long-term platform direction part of any new SGX decision.
See the current Azure DC family overview and the DCsv2 retirement guidance.
How to choose
Figure 3. A practical selection guide. Original Interian editorial visual.
Choose SEV-SNP or TDX when the security boundary should contain an existing operating system and application stack. This is usually the pragmatic route for a database, middleware server, analytics worker or line-of-business application that cannot be partitioned easily. Select between the two based on verified regional availability, required VM sizes, supported operating systems, attestation requirements, platform features, capacity and organisational processor standards.
Choose SGX when the requirement is specifically to isolate a small, high-value function from the guest operating system itself. Examples include a signing service, protected matching operation or tightly scoped data transformation. Do this only when the team can own enclave development, boundary review, signing, attestation policy, performance testing and lifecycle management.
Consider application redesign before processor choice if sensitive plaintext currently flows through many services. A TEE does not repair a sprawling trust model. Reducing where data is decrypted and which components can request a key can deliver more value than placing an unchanged distributed system inside several confidential VMs.
Common architecture mistakes
Treating encryption as complete integrity protection
Confidentiality and integrity are separate properties. Validate exactly which memory, CPU state, page mappings, firmware state and I/O paths the chosen technology protects.
Trusting every claim in a valid token
A valid signature proves who issued the evidence. It does not prove that every measured value is acceptable. Maintain approved reference values and minimum security versions, and reject debug-enabled or outdated configurations where the threat model requires it.
Releasing a key without binding it to the session
Bind attestation evidence to a nonce and preferably to an ephemeral public key or secure-channel identity. Otherwise, valid evidence can be detached from the endpoint receiving the secret.
Forgetting the guest operating system in a confidential VM
SEV-SNP and TDX reduce trust in the host. They do not remove privileged software inside the guest from the application TCB. Keep patching, identity controls, endpoint protection and least privilege.
Putting too much code inside an enclave
An oversized SGX enclave increases review scope and expands the trusted computing base. Keep enclave interfaces narrow and move non-sensitive parsing, networking and orchestration outside, while treating their outputs as untrusted.
Assuming availability from a product name
TEE-backed compute depends on specific processors, VM families, regions, quotas and qualified images. Azure service documentation can also expose different maturity labels for the VM family and individual attestation features. Verify all of them for the deployment date and region.
Key takeaways
- SEV-SNP and TDX are VM-level TEEs. SGX is an application-enclave TEE.
- SEV-SNP uses memory encryption, encrypted guest state and RMP-backed integrity controls to protect a VM from a malicious host.
- TDX creates a protected Trust Domain and provides a comparable lift-and-shift model on Intel hardware.
- SGX can create a smaller trust boundary that excludes the guest OS, but requires enclave-aware engineering.
- The TCB includes more than the processor. Guest software, enclave code, firmware, attestation verification and key-release policy all contribute.
- Attestation becomes useful when it drives a decision, especially whether a secret or workload is released.
- In Azure, keep the product mapping accurate: SEV-SNP and TDX back Confidential VM families. DCsv3 and DCdsv3 are a separate SGX enclave offering with no expansion into new Azure regions.
Part 3 moves from isolation to proof: how remote attestation, reference values, nonce handling and secure key release turn a TEE into a usable trust decision.
Primary technical sources
- Azure Confidential VM options
- Azure Trusted Execution Environment overview
- Azure Confidential VM overview
- Azure Confidential VM FAQ
- Azure DC family VM sizes
- Azure DCsv2 retirement guidance
- AMD Secure Encrypted Virtualisation
- Intel Trust Domain Extensions documentation
- Intel SGX SDK for Linux
- Intel SGX attestation services
- Confidential Computing Consortium terminology
Community and MVP reading
The following articles are useful for historical context and independent explanation. They should not be used as the source of truth for current Azure families, regions or lifecycle status, because several predate SEV-SNP and TDX availability in Azure.
- Microsoft Azure MVP Marius Sandbu compares Google Cloud Confidential VMs with the Azure confidential computing model and later places confidential computing in the wider Azure data-encryption landscape.
- Microsoft Regional Director and MVP Stefano Tempesta explains Azure confidential computing and Open Enclave. The article is SGX-era material, but its treatment of data in use, TEEs and attestation remains useful background.
- Former Microsoft MVP Thomas Maurer covers the original Azure confidential computing VM preview. It is a helpful record of the first DC-series and should be read as product history.
- Microsoft Azure MVP Aidan Finn covers the launch of the DC-series confidential compute VM preview. Like the Thomas Maurer article, it explains the early SGX offer rather than today’s whole-VM SEV-SNP and TDX families.
