Intel SGX, AMD SEV, and ARM TrustZone are the three most widely deployed hardware trusted execution environments. SGX gives userspace processes per-enclave memory encryption with the smallest trust boundary; AMD SEV-SNP encrypts entire virtual machines under hypervisor isolation; ARM TrustZone partitions a whole system-on-chip into a Secure World and a Normal World. The three differ in what runs inside the trust boundary, how attestation is rooted, and which workloads they fit. SGX dominates blockchain deployments and confidential applications; SEV-SNP and Intel TDX dominate confidential cloud VMs; TrustZone dominates mobile and embedded devices.
​

Choosing between them depends on three questions: what threat model the application targets, what code needs to execute inside the enclave, and what cloud or device class the workload runs on. The Confidential Computing Consortium estimates the broader confidential computing market — driven primarily by hardware TEE adoption — will reach roughly $54 billion by 2026 according to its 2023 outlook. Picking the right primitive matters more as the deployment surface widens.
​

This article compares the three across attestation model, memory-encryption scope, vulnerability history, ecosystem support, and the workloads each was designed for.
​

The three primitives sit at different layers of the system stack, and that layer choice shapes everything downstream.
​

Intel SGX launched on Skylake processors in 2015 as an x86 extension that lets userspace processes carve out enclaves — encrypted memory regions tagged at the page level. The CPU itself encrypts memory in those regions and refuses external access; the enclave's measurement is taken at load time and used for attestation. Skylake and Kaby Lake supported up to 128MB of Encrypted Page Cache; Ice Lake Xeons in 2021 raised the limit to 1TB. Intel deprecated SGX on consumer chips in 2021 to focus on the Xeon line. Reference implementation and SDK live in the intel/linux-sgx GitHub repository.
​

AMD SEV shipped on EPYC Naples in 2017 and added SEV-Encrypted State (SEV-ES) in 2019 and SEV-Secure Nested Paging (SEV-SNP) in 2020. SEV encrypts entire virtual machines using ephemeral keys held by the AMD Secure Processor. SEV-SNP added integrity protection through Reverse Map Tables, blocking the hypervisor from remapping or replaying guest memory. AMD's developer documentation covers the full architecture.
​

Intel TDX shipped on 4th Gen Xeon Scalable in 2023 as Intel's answer to SEV-SNP. TDX encrypts and integrity-protects entire virtual machines using a TDX module signed by Intel as the security primitive. Microsoft Azure, Google Cloud, and others expose TDX confidential VMs in production. We include TDX alongside SGX in this comparison because both ship from Intel and serve different deployment patterns. Intel's TDX overview is the canonical reference.
​

ARM TrustZone shipped on Cortex-A processors starting in 2004 and on Cortex-M processors (TrustZone-M) in 2016. TrustZone partitions the entire SoC — CPU, memory, peripherals, interrupts — into a Secure World and a Normal World using a 33rd address bit. A small Trusted OS like OP-TEE runs in the Secure World; Trusted Applications execute on top of it. ARM's Confidential Compute Architecture (CCA), announced in 2021, extends this with Realms — a TEE primitive aimed at cloud-scale workloads on ARMv9.
​

The architectural choices map to four properties: what the trust boundary contains, how memory is encrypted, how attestation is rooted, and what software runs inside.

The most consequential difference is the size of the trust boundary. SGX excludes the OS — only the enclave code and data sit inside the trust region. SEV-SNP and TDX include the entire guest OS — kernel, drivers, and application all share the encrypted region. TrustZone's Secure World runs a separate Trusted OS that brokers calls from the Normal World. The boundary choice determines the attack surface.
​

Attestation is what makes a TEE useful to a remote verifier. The signing chain and the key infrastructure differ across vendors in ways that affect production deployment.
​

Intel SGX/TDX attestation. Each Intel CPU is provisioned at manufacture with a unique fused secret. Intel's Provisioning Certification Service (PCS) issues PCK certificates derived from that secret. When an enclave or trust domain produces a quote, the CPU signs it with a key derived from the fused secret; the verifier checks the signature against the PCK chain back to Intel's root. The DCAP (Data Center Attestation Primitives) path lets verifiers run a local PCCS service that caches the certificates, removing the need to call Intel for every verification. Onchain verification of DCAP attestations is implemented in Automata's automata-dcap-attestation contracts; gas costs run in the millions for full chain verification, with a SNARK-compressed path reducing that by an order of magnitude.
​

AMD SEV-SNP attestation. AMD's Key Distribution Service (KDS) plays the role of Intel's PCS. The AMD Secure Processor signs SNP attestation reports with a key chained back to an AMD root certificate. The reports include the launch measurement, the host platform's TCB version, and a guest-supplied nonce. Microsoft Azure publishes documentation for verifying SEV-SNP attestations in their confidential VM offering. Onchain verification is less mature than the SGX/TDX path; most production blockchain projects target Intel SGX or AWS Nitro instead.
​

ARM TrustZone attestation. Unlike Intel and AMD, ARM does not operate a global attestation PKI for TrustZone. Each platform vendor — Qualcomm, Samsung, Apple, NXP — implements its own attestation flow, often signed with vendor-specific keys. This fragmentation has historically limited TrustZone's adoption in cross-vendor verification scenarios. The Confidential Compute Architecture (CCA) introduced in ARMv9 standardizes Realm attestation around the PSA Certified token format, which should improve cross-vendor verification once CCA-capable hardware is widely deployed.
​

AWS Nitro attestation. AWS Nitro Enclaves use AWS's own signing infrastructure rather than Intel or AMD keys. Attestation documents are COSE_Sign1 structures signed by the Nitro Security Chip and chained to AWS root certificates. This makes Nitro the simplest of the four for AWS-native verification flows but ties trust to AWS rather than to a CPU vendor.
​

Each TEE has a published CVE history. The pattern matters for production deployment because attestation policy should reject below-minimum-patch chips.
​

SGX: Foreshadow (CVE-2018-3615, January 2018) extracted enclave secrets through L1 cache side channels. SGAxe (2020) used CacheOut as a primitive to extract Intel's launch enclave attestation key. Plundervolt (CVE-2019-11157) used voltage manipulation to flip bits inside enclaves. ÆPIC Leak (CVE-2022-21233) leaked enclave data through the APIC. Each required microcode updates and TCB recovery. Intel's Security Center publishes ongoing advisories.
​

SEV/SEV-SNP: The "SEVered" attack (2018) demonstrated guest memory recovery via I/O remapping; AMD addressed it in SEV-ES. The "CrossTalk" and "CipherLeaks" attacks targeted SEV cryptographic implementations. SEV-SNP added integrity protection that addressed several earlier classes of attack, though side-channel research continues. AMD publishes advisories at its Product Security page.
​

TDX: Released in 2023, TDX has had a shorter exposure window. Intel disclosed several pre-shipment issues during the SEAM module review process. Researchers from KU Leuven and others have published TDX-targeted side-channel work, with Intel addressing findings through TDX module updates.
​

TrustZone: The longest-deployed of the four, TrustZone has accumulated a long CVE list — from the QSEE Qualcomm trustlet vulnerabilities to the TrustZone-M side-channel attacks. The fragmented platform-specific implementation means each vendor handles its own patching cadence. Mobile-device attestation policies often have to track per-device patch state.
​

The takeaway: every production TEE deployment should include a documented patch policy, an attestation-rejection rule for outdated TCB, and a fallback plan for chain-wide TCB recovery events.
​

Memory encryption adds overhead. The published numbers are roughly consistent across vendors, with workload sensitivity varying.
​

SGX: Compute inside the enclave runs at near-native speed. Page faults that swap pages out of the limited EPC on older Skylake/Kaby Lake hardware cost 10× to 100× per swap. Ice Lake's terabyte-scale EPC removes most of that penalty for workloads under 1TB. Crossing the enclave boundary (entering or exiting) costs a few thousand cycles, which matters for chatty IO-heavy workloads. Gramine LibOS reduces the boundary-crossing overhead by handling more syscalls inside the enclave.
​

SEV-SNP and TDX: Published benchmarks from AMD, Intel, and Google put overhead at 2–15% for typical cloud workloads, with higher overhead for memory-bandwidth-bound applications. Network-IO and GPU passthrough remain the main optimization frontiers; both have improved substantially in 2024–2025 hardware revisions.
​

TrustZone: Performance overhead in the Secure World is platform-dependent. The world-switch operation costs microseconds, which is fine for occasional secure operations (signing, biometric checks) but unsuitable for high-throughput general computation. Most TrustZone-protected operations are short-running by design.
​

The cloud and ecosystem story is what often makes the choice for a developer.
​

Cloud availability. SGX is available on Azure Confidential Computing (DCsv2 and DCsv3 series) and IBM Cloud. SEV-SNP runs on Azure Confidential VMs (DCasv5/ECasv5 series) and Google Cloud Confidential VMs (N2D series), and AWS exposes SEV-SNP via select EC2 instances. TDX is on Azure DCa-series and Google Cloud C3-series. AWS Nitro Enclaves run on most modern EC2 instance families. TrustZone is rare in cloud — the early ARM CCA Realm previews from AWS Graviton4 are the leading edge.
​

SDK and tooling. SGX has the deepest tooling — Intel SGX SDK, Microsoft Open Enclave, Gramine LibOS, EGo for Go programs. SEV-SNP and TDX leverage the existing OS — most workloads run unmodified inside a confidential VM, which is operationally simpler. TrustZone development typically uses OP-TEE or vendor-specific Trusted OS APIs; the workflow looks more like embedded development than cloud development.
​

Blockchain ecosystem. SGX dominates by far. Flashbots, Secret Network, Oasis Sapphire, Phala Network, iExec, Marlin Oyster, and Automata all ship SGX integrations in production. Atoma and parts of Marlin's roadmap target TDX. AWS Nitro is the second-most-deployed primitive in this segment, especially for AI agent workloads where AWS GPU support matters. SEV-SNP's blockchain footprint is smaller. TrustZone is largely confined to hardware wallets like Ledger and Trezor.
​

The decision typically reduces to four questions.

Most blockchain teams that have shipped multiple TEE-based products converge on a portfolio approach: SGX for low-latency intent solvers and MEV-protection workloads, AWS Nitro or Intel TDX for AI inference, and ZK proofs for the long-term auditable settlement path.
​

Eco's stablecoin orchestration network spans 15 chains with multiple cross-chain messaging and settlement primitives. Different components have different threat models, latency requirements, and deployment constraints. Solver execution that handles user intents across cross-chain messaging protocols typically lives in low-latency confidential compute environments where SGX or AWS Nitro fits naturally. Verifiable AI agents that act on Eco-routed intents — see intent-based routing protocols — increasingly target TDX with GPU support. The right hardware primitive depends on the specific component's requirements rather than any blanket "always SGX" or "always TDX" preference.
​

They optimize for different things. SGX has a smaller trust boundary (just the enclave) and per-process memory encryption — better for high-trust workloads where excluding the OS matters. SEV-SNP encrypts entire VMs and is operationally simpler because unmodified Linux runs inside. SGX dominates blockchain deployments; SEV-SNP and TDX dominate confidential cloud VMs.
​

TrustZone partitions an entire SoC into Secure World and Normal World, with a Trusted OS running in the Secure World; SGX carves out per-process enclaves on a regular OS. TrustZone is dominant on mobile and embedded; SGX is dominant on Intel server and laptop chips. TrustZone has no global attestation PKI, which limits cross-vendor verification.
​

Intel SGX, by a wide margin. Flashbots, Secret Network, Oasis Sapphire, Phala Network, iExec, Marlin Oyster, and Automata all ship SGX integrations in production. AWS Nitro Enclaves are the second-most-deployed primitive, especially for AI inference workloads. TDX adoption is growing in 2024–2025 alongside Intel's broader server rollout.
​

Generally no without modification. SGX requires partitioning the application into enclave and non-enclave portions, often via the Intel SGX SDK or a LibOS like Gramine. SEV-SNP runs unmodified Linux inside the encrypted VM. Tools like Gramine and Open Enclave attempt to abstract some of the differences, but cross-deployment without rework is uncommon.
​

Yes. SGX has a multi-year history of side-channel attacks (Foreshadow, SGAxe, ÆPIC Leak), each addressed through microcode and TCB recovery. SEV had the SEVered attack and several cryptographic-implementation issues, with SEV-SNP addressing most earlier classes. TrustZone has had platform-specific issues across Qualcomm, Samsung, and other vendors. TDX, being newer, has a shorter exposure window with several published research findings. Production deployments should include patch and attestation-policy planning.
​