facebook
loader
Learn

Intel SGX vs TDX: which TEE do you need?

SGX protects individual processes; TDX protects entire virtual machines. That one architectural difference shapes development effort, performance, and which workloads each fits.

Intel offers two Trusted Execution Environment (TEE) technologies for confidential computing: SGX (Software Guard Extensions) and TDX (Trust Domain Extensions). Both protect data during processing using hardware isolation, but they take fundamentally different approaches.

SGX protects individual processes. TDX protects entire virtual machines. This architectural difference shapes everything: development effort, performance, security guarantees, and which workloads each technology fits.

Architecture comparison

Intel SGX: process-level isolation

SGX creates enclaves — encrypted memory regions within a user-space application. Only the code running inside the enclave can access the enclave's memory. Everything outside — the operating system, hypervisor, other applications, even other enclaves — is excluded.

The enclave runs as part of your application process, but its memory is encrypted by the CPU. The CPU decrypts enclave memory only when the enclave code accesses it, and only within the CPU itself. Data never leaves the CPU in plaintext.

How you use it: You split your application into trusted (enclave) and untrusted (host) components. The enclave handles sensitive operations. The host handles everything else. The two communicate through defined interfaces (ECALLs and OCALLs).

Intel TDX: VM-level isolation

TDX creates Trust Domains — entire virtual machines with hardware-encrypted memory. The hypervisor can manage the VM's lifecycle (start, stop, migrate) but cannot read its memory, CPU registers, or internal state.

TDX introduces a new CPU mode called SEAM (Secure Arbitration Mode) that sits between the hypervisor and the Trust Domain. The TDX Module runs in SEAM mode and enforces isolation, filtering all data that crosses the boundary between the VM and the hypervisor.

How you use it: You run your existing application inside a TDX-protected VM. No code changes required. The VM's entire memory space is encrypted and isolated — your operating system, application, and data are all protected.

Side-by-side comparison

DimensionIntel SGXIntel TDX
Isolation scopeSingle process (enclave)Entire virtual machine
What's protectedCode + data inside the enclaveFull VM: OS, apps, and data
Trusted Computing BaseApplication enclave only (smallest possible TCB)Guest OS + application (larger TCB)
Code changes requiredYes — partition code into trusted/untrustedNo — run existing apps unchanged
Memory limitsHistorically 128–256MB per enclave (improved in recent generations)VM-level — GBs of protected memory
Performance overheadHigher (283–1971% for small workloads in benchmarks)Lower (9–73% depending on workload)
AttestationSGX DCAP (enclave-level quotes)TDX attestation (VM-level quotes)
Development effortHigh — requires SGX SDK, code partitioningLow — standard VM deployment
Best forHigh-assurance, focused security functionsGeneral-purpose confidential workloads
Cloud availabilityAzure DCsv2/DCsv3, IBM CloudAzure DCesv6, GCP C3-series
CPU support3rd–4th Gen Xeon and earlier4th Gen Xeon Scalable and newer

When to use SGX

Choose SGX when you need the smallest possible attack surface and strongest isolation guarantees:

  • High-assurance key management — Protecting cryptographic keys where even a compromised OS must not gain access.
  • Confidential computing protocols — Systems like Ethernity Cloud's three-enclave architecture use SGX to enforce separation between validation (TrustedZone), execution (SecureLock), and attestation (Validator). The process-level isolation ensures each enclave is independent.
  • Multi-tenant execution — Running multiple isolated workloads from different users on the same machine, where VM-level isolation isn't granular enough.
  • Verifiable execution — When you need to prove that a specific function (not a whole VM) ran on attested hardware — as in Ethernity Cloud's Proof of eXecution.

When to use TDX

Choose TDX when you need confidential computing without modifying your application:

  • Lift-and-shift migration — Moving existing enterprise applications (databases, ERP systems, analytics pipelines) into confidential VMs without rewriting code.
  • Full-stack confidential workloads — Running an entire application stack (web server, database, application logic) inside a single protected VM.
  • AI/ML workloads — Training and inference on large models where enclave memory limits are a constraint.
  • Compliance-driven deployments — Organizations that need confidential computing but don't have the engineering resources to partition code for SGX.

The convergence path

SGX and TDX aren't competing technologies — they're complementary layers in Intel's confidential computing strategy.

SGX provides the strongest isolation for focused, high-security functions. TDX provides broader protection for general-purpose workloads. Many architectures will use both: TDX for the VM-level baseline, with SGX enclaves inside for the most sensitive operations.

Ethernity Cloud's EC 2.0 protocol is adopting this approach — adding TDX support alongside existing SGX enclaves. This expands the hardware base for node operators (TDX is available on newer Intel Xeon processors that may not support SGX) while maintaining the process-level isolation of the three-enclave pipeline where it matters most.

Also consider: AMD SEV-SNP

AMD's Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) is AMD's answer to TDX. It provides VM-level encryption with integrity protection. Like TDX, it requires no application changes.

Key differences from TDX:

  • Available on AMD EPYC processors (different hardware ecosystem)
  • Currently more widely deployed in cloud (Azure, GCP, AWS all offer SEV-SNP VMs)
  • Slightly different attestation model (AMD Secure Processor vs. Intel SEAM)

For a broader overview of all confidential computing technologies, see What is confidential computing?

Follow our latest updates
discordgithubyoutuberedditfacebooktwitterinstagramtelegramlinkedinmail
© 2018-2026. Ethernity CLOUD Ltd. All rights reserved.

This site uses cookies to deliver our services. By using our site, you acknowledge that you have read and understood our Cookies Policy and our Privacy Policy Your use of Ethernity's Website is subject to these policies and terms.

I have read and accepted the Cookies Policy