Transition Paths for Intel® SGX Applications to Intel® TDX

Introduction

Intel® Software Guard Extensions (Intel® SGX) was the founding technology for Confidential Computing in the data center starting in 2017. With strong isolation of cryptographically attested application code or functions, it was adopted by security-focused developers across a range of usages and industries. The ensuing years saw the introduction of Virtual Machine (VM)-isolation Confidential Computing technologies like Intel® Trust Domain Extensions (Intel® TDX), which quickly ramped due to their superior ease-of-use, flexibility, scalability, and lower TCO.

In October 2026, Intel disclosed it will focus future Confidential Computing investments exclusively on Intel TDX, and the next-gen Intel® Xeon® platform code-named "Diamond Rapids" will be the last to support Intel SGX. With Intel SGX support well into the 2030s, developers have plenty of time to determine their migration strategy to Intel TDX and technologies like confidential containers.

Many customers used Intel SGX for its security characteristics: a minimal Trusted Computing Base (TCB) and cryptographic attestation of the enclave's software contents. The following migration options offer benefits and trade-offs with respect to simplicity and security characteristics.

A practical migration begins by identifying the architecture of the Intel SGX application that should be moved to Intel TDX. The next chapter, Main Intel SGX Application Architectures, classifies the two common architectures of Intel SGX applications. Afterwards, chapters Transitioning Applications Based on a Library OS and Transitioning Applications Based on the Intel SGX SDK describe several likely migration paths for the two common architectures. It is not an exhaustive list of possibilities but will show the major directions an organization could take. The final chapter, References and Technologies to Watch, then gathers the supporting material and emerging technologies that are relevant to the selected migration path.

Terminology

The following terms and acronyms are used in this document.

Term	Description
Intel SGX	Intel Software Guard Extensions. An Intel Confidential Computing technology that provides hardware isolation and attestation at the application level.
Intel SGX Enclave	Hardware-enforced Trusted Execution Environment when using Intel SGX.
Intel TDX	Intel Trust Domain Extensions. An Intel Confidential Computing technology that provides hardware isolation and attestation at the virtual machine level.
Trust Domain (TD)	Hardware-enforced Trusted Execution Environment when using Intel TDX.
Confidential Virtual Machine (CVM)	Hardware-enforced Trusted Execution Environment when using Intel TDX. Managed like other Virtual Machines on the system. In the context of Intel TDX, it may also be called a Trust Domain (TD).
Trusted Computing Base (TCB)	In this paper, the Trusted Computing Base refers to all software inside an Intel SGX Enclave or an Intel TDX Trust Domain. Software in the TCB may be cryptographically attested for integrity or simply assumed to be trusted.
Intel SGX SDK	Software Development Kit for Intel SGX. Provides developers tools to call Intel SGX functions and APIs directly from applications.
Library OS (LibOS)	In the context of this article, a Library OS is a lightweight, Intel SGX-enabled operating system personality that intermediates between an application and the Intel SGX functions and APIs. A Library OS allows applications to execute in the enclave with little or no modifications.
Confidential Container (CoCo)	Confidential Containers (CoCo) is an open-source project under the Cloud Native Computing Foundation that enables hardware-isolated and attested containers based on Kata container technology. In an Intel TDX context, Confidential Containers run as Trust Domains. A note on formatting: This document uses the capitalization "Confidential Containers (CoCo)" when referring to the architecture specified by the Confidential Containers open-source project. If no capitalization is used, "confidential containers" is a generic concept not specifically affiliated with the CoCo project.

Table 1. Terminology

Main Intel SGX Application Architectures

Applications that use Intel SGX generally come in two forms:

1. Applications developed using a Library OS such as Gramine or Occlum. In this case, the Library OS (LibOS) abstracts the application code from the Intel SGX APIs and function calls. In theory, the application could successfully run outside an Intel SGX enclave with little or no modification. This architecture was often used to port non-native Intel SGX applications into an enclave.

   

   Figure 1.Intel SGX Application with Library OS

2. Applications natively coded for Intel SGX using the Intel SGX SDK or comparable tools such as Open Enclave SDK. These applications directly call Intel SGX functions and APIs facilitated by the SDK. They were specifically developed to operate inside an Intel SGX enclave and cannot successfully operate outside without modifications.

   

   Figure 2.Intel SGX Application Built with Intel SGX SDK

This distinction matters because the migration approach differs substantially. If the Intel SGX application is built using a Library OS, potential migration options are described in the chapter Transitioning Applications Based on a Library OS. If the application is natively built with the Intel SGX SDK or comparable tools, potential migration options are described in the chapter Transitioning Applications Based on the Intel SGX SDK.

Transitioning Applications Based on a Library OS

From a functionality perspective, applications that use a Library OS (LibOS) should be relatively straightforward to port to an Intel TDX environment. Since the LibOS intermediates Intel SGX APIs and function calls, these applications can normally run standalone outside an enclave, including in an Intel TDX Confidential VM (CVM).

Note that some LibOSes provide convenience functionalities for enclaves, e.g., automatic encryption/decryption of files or automatic attestation. These functionalities have to be replaced when separating the application from LibOS. In the remainder of this section, we assume that this process was done.

Option A1

The most straightforward option is to provision the application inside an ordinary Intel TDX-protected CVM with a full-featured Guest OS. This is close to a "lift and shift" transition, with a possible validation cycle to confirm the application is compatible with the Intel TDX-enabled Guest OS.

Although straightforward, the TCB in this option is much larger compared to an Intel SGX enclave as it includes the CVM's virtual firmware and the entire Guest OS. These components may be orders of magnitude more code than the application itself. The authenticity and integrity of the CVM can be attested by Intel TDX, but Intel TDX does not natively attest the integrity of applications running inside the CVM. Additional development or service integrations would be required to attest the application(s).

Figure 1. Port the Confidential Application to a CVM

Option A2

In this option, the developer reduces the TCB by minimizing the code size of the Guest OS. An Intel TDX-enabled, minimal Linux kernel could be acquired or built that includes only the necessary functions for the application if a full-featured enterprise Linux OS is not required.

This option reduces the TCB versus Option A1, but it doesn't inherently offer attestation of the application inside the CVM. This capability would require additional development or service integration.

Figure 2. Port the Confidential Application to a CVM with a Reduced Kernel

Option A3

This option more closely replicates the small TCB and granular software attestation of Intel SGX using the open-source Confidential Containers (CoCo) project. Building on Kata Containers and related attestation components, CoCo enables confidential container workloads in Kubernetes, with each pod running inside its own CVM. In this model, the application is packaged as a container image within a pod, and CoCo can combine guest CVM attestation with policy-based verification of signed or encrypted container images. After successful attestation, secrets such as decryption keys or certificates can be released to the workload according to policy, while access control can still be applied at a fine-grained level. Like Option A2, the guest OS could be a dedicated, reduced OS for cloud native workloads to reduce the TCB.

This option offers a smaller TCB compared to Option A1, together with advanced access control and a stronger attestation and policy framework for containerized workloads. On top of the open-source CoCo project, Red Hat offers a productized version with Red Hat OpenShift Confidential Containers. Additionally, Edgeless Systems' "Contrast" follows a similar architecture.

Figure 3. Porting the Confidential Application to an Attested Confidential Container

Transitioning Applications Based on the Intel SGX SDK

Applications based on the Intel SGX Software Development Kit (SDK) or similar SDKs are coded specifically for Intel SGX enclaves. The application natively calls Intel SGX APIs and functions without any abstraction layer such as a Library OS. Consequently, porting them into a non-SGX environment will require a new architecture and significant code modifications.

Intel SGX SDK-based applications are usually divided between a "standard security" portion, that runs outside the Intel SGX enclave, and one or more "high security" portions that process confidential data inside SGX enclaves. Some documentations call these "untrusted" and "trusted" parts. Developers that use the Intel SGX SDK must decide whether to combine the high- and standard-security portions into a unified application or maintain the two-tier segmentation. Option B1 explores unification, while Option B2 proposes a solution that maintains the segmentation.

Option B1

In this case, the developer unifies the "standard-security" and "high-security" portions into a single application and protects it inside an Intel TDX Confidential VM.

To execute this strategy, the developer removes the "glue code" that connects the high- and standard-security portions and removes calls to Intel SGX-native APIs and functions enabled by the Intel SGX SDK. This includes code defined in Enclave Definition Language (EDL) and generated by the Edger8r. The developer may choose to use other programming techniques to limit access to the high-security portion of the unified application, but any separation is software-based. The resulting unified application can then be deployed into an Intel TDX Confidential VM, similar to Option A1. If a smaller TCB is desired, the unified application could be deployed using a reduced, simplified kernel as in Option A2 or Option A3.

Figure 1. Consolidating All Parts into One Unified Application in a CVM

Option B2

In this option, the developer retains the segmented "standard-security" and "high-security" architecture, but each portion is modified into a standalone application and deployed in a container or pod inside an Intel TDX Confidential VM.

As in option B1, the developer removes the "glue code" between the high- and standard-security portions and removes all native calls to Intel SGX APIs and functions. The resulting standalone applications are placed in their own containers (or pods if using Kubernetes). Communication and access between standard- and high-security containers/pods can be restricted on the network level and container/pod access permissions via the associated Container Management System.

This option separates high- and standard-security functions, even if the separation is only software-enforced. The TCB of this option is larger than option B1, due to the introduction of the Container Management System inside the Confidential VM. Attestation is limited to the integrity of the Confidential VM, and attestation of the software inside the VM would require additional development or service integration. However, this option preserves security-based separation versus a unified application, but that isolation is only software-enforced.

Figure 2. Segmenting Application Using Containers and Restricted Access Policies

To conclude, developers have a range of options to transition Intel SGX-based applications to an Intel TDX environment. The best choice is a function of the starting point (LibOS or SDK), desired security characteristics of the transitioned application, and resources available to support the effort.

References and Technologies to Watch

Technology or Document	Link
Intel TDX Enabling Guide	https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/01/introduction/
Confidential Containers Project	https://confidentialcontainers.org/
Edgeless Systems Contrast (Confidential Containers)	https://www.edgeless.systems/products/contrast
Red Hat OpenShift (Confidential Containers)	https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.10/html/deploying_confidential_containers/about-confidential-containers

Table 1. Technologies and Reference Documents