Intel.com

Intel confirmed on October 9, 2026 that Xeon Diamond Rapids — its next-generation server platform, expected to reach data centers in mid-2027 — will be the last Intel CPU family to include Software Guard Extensions (SGX), ending an eleven-year run for the enclave technology that helped establish confidential computing as a serious enterprise discipline. Going forward, Intel is concentrating its entire confidential computing roadmap on Trust Domain Extensions (TDX), the VM-level isolation technology it introduced with Sapphire Rapids in 2023. For enterprise and cloud teams running workloads that depend on SGX attestation, the migration window is open — but a concrete first deadline already exists: Microsoft set October 31, 2027 as the retirement date for SGX enclaves in Azure SQL Database.

SGX Has Reached a Different Kind of End of Life

SGX arrived on Intel's Skylake processors in 2015 as a hardware-enforced answer to a specific problem: how do you run sensitive code in a cloud environment where you do not fully trust the infrastructure operator? The mechanism it used is elegant. SGX lets developers carve out protected "enclaves" — small isolated memory regions managed directly by the CPU — where selected code and data run encrypted in a way that the operating system, the hypervisor, and other VMs on the same physical server cannot read or modify. Application code outside the enclave is treated as untrusted; the CPU enforces the boundary in hardware.

That boundary was repeatedly penetrated. Foreshadow (CVE-2018-3615), published at USENIX Security in August 2018, demonstrated that speculative execution could be used to read the contents of SGX-protected memory and extract a machine's private attestation key — the cryptographic credential that proves to a remote party that a genuine, unmodified enclave is running. Researchers at the time concluded that a single compromised SGX machine was enough to erode trust across the entire SGX ecosystem. Foreshadow-NG extended the damage to hypervisors and co-resident VMs through CVE-2018-3620 and CVE-2018-3646. SGAxe (2020) and ÆPIC Leak (2022) followed.

The most recent chapter arrived at the 2025 ACM Conference on Computer and Communications Security, where researchers from Georgia Tech and Purdue University presented the WireTap DDR4 interposer attack. Using a passive interposer inserted between the CPU and DDR4 memory modules — an apparatus requiring roughly $1,000 in components — the team extracted an SGX attestation signing key in 45 minutes by exploiting the deterministic AES-XTS encryption that Xeon Scalable SGX uses for its Quoting Enclave. Intel acknowledged the findings but declined to issue a CVE, noting that physical bus access falls outside the SGX threat model. Web3 infrastructure firm Phala Network reached a different conclusion: it announced on September 30, 2025 that it was shutting down all SGX compute infrastructure and migrating to Intel TDX and Nvidia Confidential Computing.

Intel notably does not cite security concerns as its official rationale for the SGX exit. The company frames the decision as a market judgment: the industry voted for VM-level isolation at cloud scale, and SGX's application-enclave model could not keep up with that demand without requiring developers to explicitly redesign their code around protected memory regions. TDX can protect existing workloads without those code changes.

What TDX Does Differently — and Why the Architecture Matters

The distinction between SGX and TDX is not simply a version upgrade. They solve the same problem — protecting data while it is being processed on infrastructure you do not fully trust — through structurally different isolation models, and the choice between them involves real tradeoffs.

SGX operates at the process level. Developers partition their applications so that the most sensitive computations happen inside small, explicitly defined enclaves; everything else remains outside in untrusted memory. The protected surface is small — sometimes just kilobytes of code — which means the trusted computing base (TCB) is minimal. The engineering burden is significant: building for SGX requires explicitly designing around the enclave boundary.

TDX operates at the virtual machine level. Intel's hardware — specifically the SEAM (Secure-Arbitration Mode) module resident in CPU firmware, combined with Total Memory Encryption Multi-Key (TME-MK) providing per-TD encryption keys — creates hardware-isolated "Trust Domains" that encrypt an entire VM's memory and block hypervisor memory access to its contents. An existing Linux VM can be lifted into a TDX Trust Domain without any changes to the applications running inside it. The hypervisor — including the cloud provider's management stack — is excluded from the trusted computing base at the VM boundary.

The lift-and-shift property is why hyperscalers chose TDX over SGX for broad cloud deployment. Microsoft Azure made four new VM series backed by Intel TDX generally available on February 26, 2026 — the DCesv6, DCedsv6, ECesv6, and ECedsv6 families, based on 4th-Gen Xeon (Sapphire Rapids) with TDX enabled. TDX is also generally available through Alibaba Cloud, Google Cloud, IBM Cloud, and Volcano Cloud.

What You Trade Away

There is a cost to TDX's operational simplicity that the migration planning literature rarely surfaces directly. By protecting an entire VM instead of a small enclave, TDX substantially enlarges the trusted computing base. Every process running inside a Trust Domain — the OS kernel, all services, all application code — is now inside the security boundary rather than explicitly excluded from it.

That matters because a vulnerability anywhere in the VM's software stack can potentially undermine the protection that TDX's hardware boundary was supposed to guarantee. This is not hypothetical: a Google-Intel joint security audit of TDX Module 1.5, published in February 2026, found CVE-2025-30513 — a flaw that allowed an untrusted cloud operator to fully compromise TDX's security guarantees by converting a migratable Trust Domain into a debuggable one during the live migration process. Intel patched the vulnerability. The audit found four additional information-disclosure CVEs alongside it.

The practical implication for compliance-sensitive workloads in financial services, healthcare, and government: TDX does not automatically inherit the security properties that an SGX deployment had. Organizations that built attestation-based compliance pipelines around SGX — cryptographic proof that specific code was running in a verified enclave — will need to re-validate those pipelines against TDX's attestation model, which is structurally different. TDX's trust proof covers the whole VM rather than specific enclave code; auditors who accepted SGX attestation as a compliance control must evaluate whether TDX attestation satisfies the same requirement.

This is where a narrow class of workloads may find continued value in SGX until its support actually ends. Applications that require the smallest possible trusted surface — cryptographic key management, specific medical-device computation, high-security financial algorithms — benefit from SGX's application-level granularity even when its operational complexity is a burden. Those workloads have until the early 2030s, when Intel's security update support for SGX-enabled platforms ends, to find TDX-based or alternative solutions.

Diamond Rapids: What the Last SGX Xeon Actually Is

Diamond Rapids, Intel's Xeon 7 platform built on the 18A-P process node with Foveros Direct 3D packaging, is a substantial architecture. Intel presented it at Hot Chips 2026 in August featuring up to 256 Panther Cove P-cores across 16 compute chiplets, 1.28 GB of last-level cache, 16-channel DDR5 memory at up to 12,800 MT/s, and 128 lanes of PCIe Gen 6 with CXL 3.0 support. Coverage from ServeTheHome confirms the architecture as Intel's most ambitious Xeon design. Both TDX and SGX appear in the security feature set for Diamond Rapids, making it a transitional platform rather than an abrupt end. Intel expects data center launch in mid-2027.

Intel will provide security updates and technical support for SGX-enabled platforms into the early 2030s. That means organizations with current Sapphire Rapids or Granite Rapids deployments — which support TDX but not SGX — already have no hardware path to SGX, while organizations running earlier Ice Lake or older Xeon platforms still on SGX have a support window to manage.

TDX's Roadmap: Trusted I/O, Post-Quantum Attestation, and Agentic AI

Intel outlined three areas of planned TDX investment alongside the announcement, none of which have specific availability dates yet.

TDX Connect and Trusted I/O. The most immediate gap in TDX's current architecture is the device boundary. Hardware-enforced isolation inside a confidential VM does not automatically extend to data moving between the VM and connected accelerators — GPUs, SmartNICs, and CXL-attached storage — over PCIe or CXL links. TDX Connect, introduced with Xeon 6 Granite Rapids, addresses this by extending the trust boundary to authenticate connected devices and encrypt data in transit across that boundary. Intel is working with Nvidia to coordinate CPU-GPU confidential computing for AI workloads, extending TDX Connect's trusted I/O model into multi-chip inference and training pipelines.

Post-quantum attestation. TDX's current attestation mechanism relies on classical elliptic-curve cryptography. This creates a specific long-term vulnerability: adversaries can collect and store TDX attestation records now and potentially forge or repudiate them once cryptographically relevant quantum computers exist — what the security research community calls "harvest now, decrypt later." NIST published the first post-quantum cryptography standards in August 2024 — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — marking the beginning of a formal migration timeline for any cryptographic system that must remain secure over a decade-long horizon. Intel's plan to integrate post-quantum primitives into TDX attestation is directly responsive to this standard. Organizations operating regulated workloads with long confidentiality requirements — healthcare records, financial contracts, government data — should treat Intel's post-quantum attestation roadmap as a planning input alongside NIST's recommended migration timelines.

Agentic AI. Intel positions TDX as a natural security layer for autonomous AI agent deployments, where agents access sensitive enterprise data across multiple systems, execute actions without real-time human oversight, and orchestrate other agents in pipelines. Each agent in such an architecture can run in a separate, hardware-isolated TDX Trust Domain on shared infrastructure — providing strong inter-agent isolation while preserving the operational economics of multi-tenancy. This is architecturally straightforward for TDX in a way it was not for SGX: TDX can protect an entire agent execution environment — the model, its memory context, tool-access credentials, and output buffers — without requiring the agent framework to be rewritten around enclave boundaries.

How Do I Know If My Workload Is Ready for TDX?

Attestation pipeline validation is the primary technical challenge for enterprise migrations. Organizations that built compliance workflows around SGX DCAP attestation — audit trails, zero-trust policy enforcement gates, regulatory evidence packages — need to re-validate those pipelines against TDX's attestation architecture. The attestation quote structure is different, the trust anchors are different, and the evidence a TDX attestation report provides covers a different scope (the whole VM, not specific enclave code). Engage your ISV and compliance team before assuming SGX attestation compliance evidence transfers to TDX.

The confidential computing market reached $8.6 billion in 2025 and is projected to approach $14 billion in 2026, according to Fortune Business Insights estimates cited by industry analysts. That growth is driven overwhelmingly by VM-level isolation adoption at cloud scale — exactly what TDX delivers. Red Hat, Canonical, and VMware have all added TDX platform support for private cloud and enterprise environments, removing one of the last friction points for on-premises TDX adoption. OpenStack Nova 2026.2 Hibiscus, released September 30, 2026, also included the TDX libvirt blueprint — meaning TDX workloads can now be orchestrated through the OpenStack management stack that powers many private cloud deployments.

For cloud architects already on Azure, Google Cloud, or IBM Cloud, the path is well-documented and the hardware is available today. The harder work falls on enterprises running SGX in private on-premises data centers, where hardware refresh cycles are slower and where Sapphire Rapids (the earliest TDX-capable platform) may not yet be universally deployed.

Frequently Asked Questions

What is the difference between Intel SGX and Intel TDX?

SGX and TDX both protect sensitive data while it is being processed — a problem called data-in-use security — but they do it at different levels of the software stack. SGX creates protected "enclaves" inside specific applications, isolating small pieces of code and data from everything else, including the operating system. Developers must explicitly partition their applications to use SGX, which requires significant engineering effort. TDX protects entire virtual machines by blocking the hypervisor and other VMs from accessing a VM's memory. Existing workloads can be moved into a TDX confidential VM without any code changes. TDX is operationally simpler at cloud scale; SGX offers a smaller trusted surface for workloads where minimal code exposure is the priority.

Why is Intel ending SGX support, and is TDX actually more secure?

Intel's stated reason is market alignment, not security failure: cloud providers and enterprises adopted VM-level isolation overwhelmingly because it requires no application redesign. TDX is not strictly "more secure" than SGX — it protects a larger scope but trusts a larger scope. A severe vulnerability (CVE-2025-30513) discovered in a 2026 Google-Intel audit allowed an untrusted cloud operator to fully compromise a Trust Domain's security guarantees by exploiting the live migration process; Intel patched it. TDX's larger trusted computing base means that software vulnerabilities inside a protected VM can potentially undermine the protection, which is less true of SGX's small-enclave model. Organizations with narrow, high-sensitivity workloads should evaluate whether TDX's attestation properties satisfy their specific compliance requirements before treating the migration as automatic.

When do I actually have to move off SGX?

The timeline has multiple milestones. Diamond Rapids, expected in mid-2027, will be the last Intel Xeon to include SGX — but you do not need Diamond Rapids to move to TDX; Sapphire Rapids (4th-Gen Xeon) and later already support it. The most concrete near-term deadline for enterprise database teams: Microsoft set October 31, 2027 as the retirement date for Intel SGX enclaves in Azure SQL Database. Intel will continue providing security updates for SGX-enabled platforms into the early 2030s, giving organizations a longer window for private on-premises deployments — but cloud-hosted SGX workloads face service-level retirement dates that vary by provider and workload type. Begin attestation pipeline re-validation now rather than at the deadline.

What is TDX Connect, and why does it matter for AI workloads?

TDX's VM-level isolation protects data inside a confidential VM, but data flowing between the VM and connected accelerators — GPUs for AI inference, SmartNICs for networking, CXL-attached storage — passes through the PCIe or CXL bus outside that protected boundary. TDX Connect, available on Xeon 6 Granite Rapids platforms, extends hardware-enforced trust to those connected devices, authenticating them and encrypting the data path across the boundary. For GPU-accelerated AI workloads — including autonomous agent pipelines that process sensitive enterprise data through large language model inference — TDX Connect is what allows the confidential computing guarantee to cover the full compute pipeline rather than stopping at the CPU boundary.