TL;DR: Intel’s decision to end SGX in its next Xeon generation pushes confidential computing teams toward hardware portability, because enclave trust now depends on attestation and key-release workflows that survive CPU transitions, according to Fortanix. The real control problem is no longer one chipset, but whether workloads can move without weakening identity, policy, or data protection.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Fortanix's blog post: Intel's plan to retire SGX support in its next Xeon generation means confidential computing strategies now need to outlive a single enclave technology.
Why it matters: It matters because IAM and platform teams that rely on attestation, key release, and workload identity must make sure their controls still work when the underlying hardware changes.
Context
Secure enclaves let software prove it is running on trusted hardware before sensitive keys or data are released. That model is now under pressure because SGX is no longer a stable long-term hardware assumption, and confidential computing programmes need to survive platform turnover rather than depend on a single instruction set.
For identity and key governance teams, the issue is not just chip support. It is whether attestation, workload trust, and key release remain enforceable across CPUs, GPUs, and future enclave designs without creating a new portability gap.
Key questions
Q: How should teams govern confidential computing when enclave hardware support changes?
A: Teams should treat enclave hardware as an implementation detail and govern the attestation and key-release policy as the durable control. If the trust decision only works on one chipset, the architecture is brittle. The goal is to prove that workloads can move across hardware generations without changing who can obtain keys or what conditions must be met.
Q: Why does SGX retirement create governance risk for confidential computing programmes?
A: It creates risk because many programmes have implicitly tied workload trust to one hardware family. When support shifts, teams may discover that their real control was the chipset itself, not the policy behind it. That is a lifecycle governance problem: the trust boundary has to remain valid through refresh cycles, vendor changes, and platform replacement.
Q: What breaks when attestation is not portable across hardware platforms?
A: Workloads can still run, but the security model becomes inconsistent. A team may be able to attest one environment and not another, which means key release, compliance evidence, and operational rollout all become uneven. In practice, that leads to exceptions, manual approvals, and fragmented assurance across infrastructure tiers.
Q: What is the difference between enclave security and workload identity in confidential computing?
A: Enclave security is the hardware-backed ability to measure and protect code while it runs. Workload identity is the policy layer that decides whether a given workload is allowed to receive keys or access data after attestation. They are related but not interchangeable, and strong programmes need both to keep trust decisions enforceable.
Technical breakdown
How attestation gates key release in enclave workflows
A secure enclave workflow typically starts with platform measurement, then attestation, then policy-based key release. The software proves what code and hardware it is running on, and only then can encryption keys be released to unlock model weights or protected data. That sequence creates a trust boundary that is stronger than simple host-based access control, but it also introduces dependency on a specific attestation chain and hardware support model. When the hardware layer changes, the trust decision logic must still produce the same security outcome even if the underlying implementation shifts. See the Confidential Computing Guide.
Practical implication: Treat attestation policy as a portable control plane, not a chipset-specific dependency.
Why confidential computing is becoming a multi-vendor architecture problem
Confidential computing is no longer just about one enclave technology. The article points to CPUs and GPUs from different vendors, which means the security architecture has to handle heterogeneous trust anchors, different measurement formats, and potentially different attestation services. That creates integration risk if each platform is governed as a separate exception. The hard part is not enabling encryption in use, but normalising trust decisions across hardware families so workload protections remain consistent as infrastructure evolves.
Practical implication: Standardise trust policy across enclave implementations before hardware migration becomes urgent.
What changes when secure enclaves support AI workloads
In AI deployments, enclaves protect model weights and sensitive data while computation is in progress. That makes the enclave boundary part of the AI control plane, because key release determines whether the model can be used at all. The identity question becomes who or what is authorised to trigger attestation and obtain keys, especially when workloads span CPU and GPU components. If that authorisation model is weak, the enclave still exists but the protection boundary can be bypassed through mis-scoped trust decisions rather than direct cryptographic failure.
Practical implication: Bind model access to workload identity and policy enforcement, not to hardware assumptions alone.
NHI Mgmt Group analysis
SGX retirement is not a dead end for confidential computing, but it does end the illusion that enclave security can be tied to one hardware generation. Fortanix’s analysis makes the real issue clear: the control plane for attestation, policy, and key release has to be portable if the workload is expected to survive CPU refresh cycles. For practitioners, that means designing for attested workload mobility rather than enclave lock-in.
The governance problem is now hardware continuity, not hardware preference. Once a programme depends on secure enclaves for model weights, regulated data, or sensitive computations, the question becomes whether trust decisions can be preserved when the underlying silicon changes. That is a platform governance issue as much as a cryptography issue, and it belongs in architecture reviews before migration pressure arrives.
Confidential AI raises the stakes because the enclave is now part of AI access control, not just data protection. The article shows how combined CPU and GPU attestation can gate release of model weights and customer data, which means the trust boundary is being used to govern AI execution. That makes confidential computing a policy and identity problem as much as a hardware one, and practitioners should treat workload attestation as a first-class control.
Portable attestation is the named concept this market is moving toward. The industry does not need a permanent dependency on SGX to preserve enclave security; it needs attestable trust decisions that remain valid across vendors and device classes. The practical implication is that architecture teams should measure whether their confidential computing design can move with the platform instead of being rebuilt for each generation.
SGX retirement will accelerate evaluation of alternative TEE stacks, but it will also expose weak governance wherever enclaves were treated as a one-time deployment choice. Teams that only documented the enclave itself, rather than the lifecycle of attestation, policy, and key release, will feel the gap most sharply. Practitioners should use this moment to test whether their confidential computing control model is hardware-agnostic in practice, not just in presentation.
Read next: Confidential Computing Guide
What this signals
Portable attestation: this is the practical direction for confidential computing because workloads now need trust decisions that survive platform replacement, not just a single hardware generation. Architectures that cannot preserve attestation semantics across vendors will accumulate exception handling and policy drift, especially in AI deployments where keys gate access to model weights and sensitive data.
The next governance question is whether confidential computing policies are written against hardware names or against measurable trust conditions. Teams that can answer that cleanly are better positioned to move from SGX-centric designs to a multi-vendor enclave strategy without weakening control consistency.
For practitioners
- Inventory every SGX-dependent workload Identify which applications, services, and AI pipelines rely on SGX-specific code paths, attestation services, or key release logic so migration scope is visible before the hardware transition window closes.
- Separate policy from enclave implementation Move attestation rules, authorization checks, and key release conditions into a platform layer that can be reused across different TEE technologies instead of embedding them in SGX-only workflows.
- Test workload portability across CPU and GPU enclaves Validate that the same workload trust outcome can be achieved on alternative hardware, including combined CPU and GPU attestations, without changing the security model for protected data or model weights.
- Update architecture reviews for enclave lifecycle risk Treat enclave support lifespan, vendor transition risk, and key release continuity as explicit design criteria in confidential computing reviews and programme roadmaps.
Key takeaways
- Intel’s SGX retirement is a portability problem for confidential computing, not a reason to abandon enclave-based protection.
- The important control is attestation continuity, because it determines whether keys and data remain governed as hardware changes.
- Practitioners should test whether workload trust, policy enforcement, and key release still work across alternate TEE implementations.
Related NHI Mgmt Group resources: Confidential Computing Guide · Guide to the Secret Sprawl Challenge · Open Source Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Enclave attestation is the authentication step that gates key release in this hardware trust model. |
| NHI-05 — Overprivileged NHI | Key release and workload access must be scoped so enclave identities do not gain broader trust than needed. | |
| Recommendation — Require attestation-backed authentication before releasing keys to enclave workloads. Limit enclave workload privileges to the minimum policy and data scope they actually need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key release and attestation depend on disciplined authenticator lifecycle governance. |
| Recommendation — Manage attestation credentials and key-release conditions as lifecycle-controlled authenticators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Confidential computing access is ultimately governed by who or what receives protected keys. |
| Recommendation — Enforce entitlement checks before protected data keys are released to workloads. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The central control objective is preventing unauthorised access to encryption keys and model weights. |
| Recommendation — Map key-release abuse to credential-access detections and monitor abnormal attestation requests. | ||
Key terms
- Secure Enclave: Secure Enclave is Apple's hardware-backed security component for protecting sensitive cryptographic material on supported devices. In biometric flows, it keeps keys isolated from the app and main operating system, reducing the chance that application code can directly expose or misuse authentication secrets.
- Attestation: Attestation is verifiable evidence about a workload’s execution context, such as where it is running, who started it, and whether it matches policy. In agent governance, attestation can be used to bootstrap enrollment and to justify access decisions that need to change as the workload behaves differently.
- Confidential Computing: A method of processing sensitive data inside a protected hardware enclave so the cloud operator cannot inspect the data while it is in use. It combines isolation, attestation, and controlled execution to reduce exposure during cloud-side computation without forcing plaintext access.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to connect identity controls to platform trust. It gives security teams a common language for governing machine and workload identities across changing infrastructure.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org