9/2/2025
5 min read

Confidential AI: From SGX to TDX

Tech
Privacy
Confidential AI: From SGX to TDX

From SGX to TDX: Why Intel is Redefining Confidential Computing


Intel is shifting from SGX enclaves to TDX trust domains in its confidential computing roadmap. Why? Let’s break down the differences, SGX’s limitations, and how TDX is poised to power secure cloud and AI workloads.


1 - Intel SGX (Software Guard Extensions)

SGX introduced enclaves: protected memory regions inside an application. They create a small trust boundary, enclave code and data are isolated even from the operating system (intel.com), minimizing the attack surface.


2 - SGX Drawbacks

Enclaves came with strict memory limits and a challenging programming model (canarybit.eu), making adoption difficult. Porting applications was often slow and error-prone. Over the years, researchers also discovered numerous vulnerabilities in SGX.


3 - Intel TDX (Trust Domain Extensions)

TDX uses virtualization-based isolation. Instead of protecting just a process, it treats an entire virtual machine as a secure Trust Domain (TD). The guest OS and apps run inside this hardware-protected TD, while the hypervisor and host remain untrusted (wikipedia).


4 - Trust Boundary Shift

  • With VM isolation (TDX), the cloud host and hypervisor are outside the TEE, while the entire guest VM is inside.
  • With process enclaves (SGX), even the OS was outside, only the enclave itself was inside the TEE.

  • 5 - TDX Advantages: Usability

    Applications and operating systems can run unmodified inside a TD, no need to rewrite them for enclaves (intel.com). This “lift-and-shift” approach makes adoption far easier. SGX, by contrast, often required redesigning and partitioning applications.


    6 - Memory & Scale

    TDX isn’t constrained by SGX’s small enclave memory.

    A TD can use gigabytes of RAM with memory encryption protecting it (github.com).

    This allows large workloads, such as big datasets and ML models, to run confidentially, which was infeasible with SGX’s limited EPC.


    7 - I/O Performance

    TDX supports standard VM I/O, unlike SGX which had to exit enclaves for OS calls.

    SGX’s context switches for I/O were costly (github.com); TDX avoids that by running a full OS inside the TEE.

    Result: I/O-heavy workloads (databases, web services) perform significantly better under TDX.


    8 - Security Gains

    TDX was designed with side-channel defenses in mind. It includes mitigations for timing and interrupt-based leakage attacks identified during SGX’s lifecycle (flashbots).

    TDX also encrypts a VM’s memory and CPU state, with integrity checks, to block hypervisor-level attacks (redhat.com).


    9 - Cloud Impact

    With TDX, an entire VM becomes a secure enclave. Even a cloud provider’s administrators or a compromised hypervisor cannot access its data (intel.com).

    This makes it possible to move sensitive workloads, databases, analytics, and more, into cloud VMs with confidence.


    10 - Confidential AI

    TDX enables training or running AI on private data in the cloud.

    For example: a hospital could train an ML model on patient records inside a TDX VM, the data remains encrypted and invisible to the cloud provider (intel.com).

    This opens new opportunities for confidential AI on sensitive datasets.


    11 - Adoption

  • Azure: Confidential VMs based on Intel TDX (DCesv5/ECesv5 instances) for lift-and-shift protection (Microsoft Learn).
  • Google Cloud: C3 machines use 4th Gen Xeon with TDX, with memory encryption enabled by default (cloud.google.com).

  • 12 - Limitation: TCB Size

    TDX’s trust boundary is larger than SGX’s. With TDX, you trust the entire VM (guest OS + apps) inside the TD.

    If malware runs inside that VM, it can still steal data, TDX doesn’t prevent bugs within the TD.

    (SGX enclaves had a much smaller TCB) (github.com).


    13 - Performance

    TDX introduces some overhead:

  • Memory accesses have slightly higher latency due to encryption (intel.com).
  • Entering/exiting a TD is slower than a normal VM exit because of extra state saving.

  • For most workloads, the overhead is modest, but it’s a trade-off worth noting.


    14 - Developer Considerations

  • No special coding required: run applications in a TDX VM without modification.
  • Plan for remote attestation: use Intel’s Trust Authority or a cloud attestation service to verify the TD’s authenticity before provisioning secrets (wikipedia).

  • 15 - Security Inside the TD

    Keep your OS and applications inside the TD updated and hardened.

    TDX keeps outsiders out, but it doesn’t eliminate vulnerabilities within the TD itself.

    In short: TDX drastically reduces external threats, but developers still need to secure the software they run inside.


    ---


    Final Thought

    Confidential computing has matured from a niche technology (SGX enclaves used by only a few) into a cloud-wide capability (TDX confidential VMs available to anyone).


    For developers and technology leaders, now is the time to revisit threat models and data-handling practices.

    If your workloads involve sensitive data or algorithms, consider giving them the confidential computing treatment.


    The transition from SGX to TDX has lowered the barrier:

    It’s no longer “maybe we can redesign everything for enclaves” but rather “let’s deploy on a confidential VM and we’re largely done.”


    The age of “trust no one but the CPU” computing is here, and it’s ready to protect AI and beyond.

    Enjoyed this article?

    Follow me for more Web3 developer insights.