Trusted execution environments (TEEs): boundaries, properties, and fit
A trusted execution environment is useful only when its protected boundary, trusted computing base, and evidence are stated precisely.
Direct answer
A trusted execution environment is an isolated execution boundary intended to provide confidentiality and integrity for code and data against actors outside that boundary. In confidential computing, the TEE is hardware-based and attested so another party can evaluate claims about its identity and state.The properties that define the boundary
The Confidential Computing Consortium centers three properties: data confidentiality, data integrity, and code integrity. Attestability allows a remote party to evaluate evidence about the environment. Code confidentiality may exist in some implementations, but it is not safe to assume it from the term TEE alone.CCC
| Property | Question it answers | Buyer test |
|---|---|---|
| Data confidentiality | Can an unauthorized actor outside the TEE read data in use? | Attempt access through host, hypervisor, debug, management, and device paths |
| Data integrity | Can that actor silently alter protected runtime data? | Review page ownership/integrity controls and exercise tamper/failure behavior |
| Code integrity | Can admitted code be changed without detection? | Compare measured launch and runtime claims with approved reference values |
| Attestability | Can a relying party evaluate identity and state before trust? | Obtain fresh evidence and independently appraise it against explicit policy |
Enclave, confidential VM, and device TEE
TEE designs protect different units. An application enclave can keep the trusted computing base small but may require application changes. A whole-VM TEE can run a conventional guest and application stack with fewer changes, while placing more guest software inside trust. A device TEE, such as a supported confidential GPU, must be securely attached to a CPU TEE and included in the workload’s attestation and keying flow.
| Form | Adoption benefit | Trade-off |
|---|---|---|
| Application enclave | Narrow boundary and potentially smaller TCB | Porting, constrained runtime, and enclave-specific I/O patterns |
| Whole confidential VM | Runs familiar operating systems and containers | Guest kernel and more runtime software enter the TCB |
| Confidential accelerator/device | Protects high-throughput compute outside the CPU | Requires an end-to-end supported host, device path, firmware, driver, and evidence chain |
What it protects—and what it does not
- Potentially protects active code and data from the host OS, hypervisor, other tenants, administrators, and some physical paths—only as stated by the platform threat model.
- Does not automatically encrypt external storage or network traffic; those controls remain necessary.
- Does not make vulnerable or malicious code inside the TEE safe.
- Does not prevent the host from withholding CPU time, memory, network, devices, or power.
- Does not eliminate every timing, cache, access-pattern, power, fault, or physical side channel.
- Does not control what an authorized application releases in outputs, logs, or tool calls.
How to compare TEE platforms
- List adversaries and physical assumptions, including whether a cloud or data-center operator is excluded.
- Draw exactly which CPU state, memory, devices, firmware, I/O, and management paths are protected.
- Inventory the trusted computing base and how it is measured and updated.
- Inspect evidence format, endorsement and revocation services, reference values, freshness, and verifier ownership.
- Test secret release and denial on measurement, version, debug-state, and device-membership changes.
- Review lifecycle constraints: migration, backup, crash handling, observability, patching, and incident response.
Frequently asked questions
Is every secure enclave a confidential-computing TEE?
The Confidential Computing Consortium uses a specific scope: hardware-based, attested TEEs protecting data in use. Products called secure enclaves can have different boundaries or roots of trust, so evaluate their published properties rather than the label.
Is a smaller TEE always more secure?
A smaller trusted computing base can reduce attack surface, but architecture quality, implementation, side-channel assumptions, operational correctness, and application changes also matter.
Can a TEE replace application security?
No. Code running inside the TEE can still have vulnerabilities, authorize the wrong actor, leak through outputs, call unsafe tools, or mishandle secrets.
Sources
- CCCA Technical Analysis of Confidential ComputingConfidential Computing Consortium
Relevant GPU availability
Verified specifications, confidential-mode support, and public listings for the accelerators this post covers.
Ready to reserve capacity?
Confidential Nodes matches bare-metal confidential GPU nodes to workloads, with verified provider data behind every listing.