The Main Types of TEEs

TEE is a category, not one product

Different TEEs protect different amounts of code and data.

The main design question is: What should be placed inside the protected boundary?

The answer determines the size of the TCB, application compatibility, developer effort, and remaining attack surface.

Process-level enclaves

A process-level enclave protects selected application code and memory.

The application is divided into trusted enclave code and untrusted host code. The host requests operations from the enclave. The enclave may request storage, network, or operating-system services from the host.

Main benefit: The trusted application boundary can remain small.

Main cost: The application may need to be redesigned and divided into trusted and untrusted parts.

Example technologies: Intel SGX, Keystone-style application enclaves, enclave frameworks built over protected processor features.

Common use cases: Key management, credential processing, secure signing, private matching, sensitive business logic, cryptographic services.

Secure-world architectures

A secure-world architecture divides the system into hardware-enforced security states.

Arm TrustZone commonly separates Normal World and Secure World. The hardware can apply security attributes to memory, peripherals, interrupts, processor state, and debug access.

Arm describes TrustZone as a system-wide approach to hardware-enforced isolation.

Main benefit: The secure environment can protect device-wide security services.

Main cost: The secure operating system and trusted applications inside it become part of the TCB.

Common use cases: Mobile payments, device credentials, biometric processing, secure boot, digital rights management, embedded security.

Confidential virtual machines

A confidential virtual machine protects an entire guest VM from the host hypervisor and other host software.

The boundary may include guest firmware, guest kernel, applications, runtime dependencies, and in-memory data.

Main benefit: Existing operating systems and applications may run with fewer changes.

Main cost: The guest operating system and its services become part of the TCB.

Example technologies: AMD SEV-SNP, Intel TDX, Arm CCA Realms.

Common use cases: Private databases, enterprise applications, confidential AI, multi-party analytics, cloud services, existing application stacks.

Isolated enclave VMs

Some platforms create a restricted isolated environment beside a parent virtual machine.

AWS Nitro Enclaves is one example. A Nitro Enclave receives isolated CPU and memory from its parent EC2 instance. It does not provide normal external networking or persistent storage interfaces. Communication occurs through a local virtual socket mechanism.

Main benefit: The enclave has a restricted environment and a narrow communication path.

Main cost: Developers must design around limited interfaces.

Common use cases: Tokenization, private comparison, key processing, secure signing, processing encrypted records.

Secure subsystems and secure elements

A secure subsystem protects a narrow group of security functions. It may contain a separate processor, protected memory, cryptographic engines, dedicated firmware, secure boot, and protected key storage.

Apple's Secure Enclave is an example of a dedicated security subsystem integrated into a system on a chip.

Main benefit: The security boundary is focused on a small number of sensitive operations.

Main cost: It cannot normally run arbitrary server applications.

Common use cases: Device-bound keys, biometric templates, authentication, payments, passcode protection.

Confidential containers

Confidential containers place container workloads inside confidential VMs. This keeps familiar container and Kubernetes workflows while using a hardware-isolated guest environment.

The boundary commonly includes the container workload, guest kernel, guest runtime, guest firmware, and attestation agent.

Main benefit: It fits existing cloud-native workflows.

Main cost: The supporting guest stack enters the TCB.

Confidential accelerators

A confidential accelerator extends the protected path to a GPU or another device.

The system must protect accelerator memory, device firmware, CPU-to-device communication, session keys, device identity, and device attestation.

Main benefit: Sensitive high-performance workloads can use accelerators.

Main cost: The system now depends on a more complex chain involving the CPU, device, drivers, firmware, and interconnect.

Common use cases: Private AI inference, protected AI model weights, confidential training, scientific computation, large-scale private analytics.

Comparing the main architectures

| Architecture | Protected scope | Main strength | Main trade-off | |---|---|---|---| | Process enclave | Selected application code | Small TCB | More development work | | Secure world | Secure OS and trusted services | Device-wide security | Large privileged secure stack | | Confidential VM | Full guest VM | Application compatibility | Larger TCB | | Isolated enclave VM | Restricted service environment | Narrow interfaces | Limited operating model | | Secure subsystem | Specific security functions | Strong focused protection | Limited programmability | | Confidential container | Container inside protected VM | Cloud-native deployment | Guest environment is trusted | | Confidential accelerator | CPU and accelerator workload | Private high-performance compute | Complex trust chain |

Choosing the boundary

Use a small enclave when:

• Only a small amount of logic is sensitive.
• The code can be separated cleanly.
• A small TCB matters.
• The team can handle specialized development.

Use a confidential VM when:

• A full operating system is needed.
• The existing application is difficult to rewrite.
• Compatibility matters more than minimum TCB size.
• The whole workload needs memory protection.

Key takeaways

• TEE platforms differ mainly by protected scope.
• Process enclaves protect selected code.
• Secure worlds support device-wide secure services.
• Confidential VMs protect complete guest environments.
• Secure subsystems protect narrow assets and operations.
• Confidential accelerators extend trust across several devices.
• TEE selection should follow the threat model.