Intel Trusted Domain Extensions (TDX) is a hardware isolation technology for running confidential virtual machines on supported processors. It uses a Trusted Domain to protect guest memory and execution state from the host hypervisor and other software layers, which helps keep sensitive workloads and secrets insulated during cloud or virtualised execution.
How Intel TDX works as a confidential computing boundary
Intel Trusted Domain Extensions, or TDX, creates a hardware-backed trust boundary for a confidential virtual machine. The Trusted Domain is designed so the guest can run with stronger isolation from the host hypervisor and adjacent software layers than a conventional VM can expect.
That matters because virtualisation normally assumes the host stack can observe or influence much of the guest runtime. TDX narrows that exposure so the guest can keep sensitive computation and in-memory material protected while still using cloud infrastructure.
What TDX changes for workload confidentiality
TDX is best understood as a data-in-use protection mechanism for virtualised workloads. It does not replace encryption at rest or in transit, but it reduces the trust placed in the surrounding platform while the workload is executing.
The practical change is that a cloud operator, hypervisor compromise, or other software-layer failure has less ability to inspect guest state directly. That is why TDX is often discussed alongside confidential computing, attestation, and controlled key release.
For teams handling regulated data, proprietary models, or sensitive processing, the value is not just privacy in the abstract. It is the ability to run in shared infrastructure while reducing the blast radius of infrastructure administrators, orchestration layers, and other privileged components.
Where TDX fits in the confidential computing stack
TDX is one implementation within the broader confidential computing family, which also includes related enclave and TEE approaches from other vendors. The common design goal is to protect memory and execution state from unintended visibility or tampering by software that is normally trusted in a standard VM model.
A useful way to think about it is that TDX strengthens the isolation of a virtual machine, while attestation and key release help prove the environment before secrets are handed over. That pairing is what turns hardware isolation into an operational control, rather than a purely architectural claim. Confidential Computing Guide
Because TDX is hardware and platform dependent, deployment choices still matter. The security outcome depends on the full chain of firmware, host configuration, attestation workflow, guest image handling, and how applications treat secrets once they are inside the protected domain.
Operational limits and security assumptions
TDX improves isolation, but it does not make the rest of the environment irrelevant. The guest still needs trustworthy provisioning, carefully scoped secrets, and application logic that does not leak data through logs, side channels, or external services.
That means organisations should treat TDX as one control in a larger confidential computing design, not as a blanket guarantee that every workload is safe by default. It is strongest when the main concern is reducing exposure to platform operators and other software layers during execution.
Used well, TDX lets security teams preserve cloud elasticity without fully surrendering trust in the hosting stack. Used poorly, it can create a false sense of invulnerability if surrounding identity, key management, and workload handling practices remain weak.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | TDX materially strengthens process and VM isolation for sensitive execution. |
| SC-13 — Cryptographic Protection | TDX is commonly paired with encrypted or protected data-in-use workflows. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Confidential VMs often depend on attestation-driven trust before secrets are released. | |
| Recommendation — Apply SC-39 to isolate confidential workloads from the host and adjacent software layers. Use SC-13 to protect workload data while it is being processed in memory. Use IA-9 to authenticate the confidential workload before releasing protected secrets. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Confidential computing deployments depend on tightly controlled access to hosts, guests, and release mechanisms. |
| Recommendation — Enforce IAM controls around attestation, key release, and privileged cloud access. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | TDX is part of a cryptographic protection strategy for data in use and workload isolation. |
| Recommendation — Apply A.8.24 to support confidential computing with governed cryptographic protections. | ||
Related resources from NHI Mgmt Group
- Why do trusted tools and extensions create such high credential risk?
- What do security teams get wrong about trusted browser extensions?
- Why does relying on trusted browser extensions create security risk for organisations?
- Why do baseline deviations in GitHub Actions matter even when the destination is under a trusted wildcard domain?