Choose the Right TEE Architecture

What you will learn

This lesson teaches you how to select between:

Process-level enclaves
Confidential virtual machines
Isolated enclave VMs
Secure-world systems
Confidential containers
Confidential accelerators

Begin with the required boundary

The first architectural question is:

> What is the smallest useful unit that needs protection?

Possible answers include:

One cryptographic operation
One application function
One process
One container workload
One virtual machine
One mobile security service
One CPU and GPU workload

The size of the protected boundary affects:

Trusted Computing Base
Developer effort
Compatibility
Attestation
Memory use
I/O design
Update process
Side-channel surface
Recovery process

Process-level enclave

A process enclave protects selected code and data.

This model is suitable when:

Only a small part of the application is sensitive.
The application can be split cleanly.
A smaller TCB is important.
Developers can manage a specialized interface.

The host remains responsible for ordinary services such as networking, storage, and scheduling. The protected code should treat all host responses as untrusted.

Example use cases

Transaction signing
Password verification
Key derivation
Private matching
Credential processing
Tokenization

Confidential virtual machine

A confidential VM protects a full guest environment.

It is suitable when:

Existing applications must run with limited changes.
A full Linux environment is required.
Several services need to run together.
Process-level partitioning would be too expensive.

The guest kernel and guest services are normally inside the trusted boundary.

AMD describes SEV as a VM-based confidential-computing system. SEV-ES protects guest register state during exits, while SEV-SNP adds memory-integrity and page-ownership protections intended to resist malicious hypervisor remapping and replay.

Example use cases

Private databases
Enterprise workloads
Confidential AI services
Data clean rooms
Existing microservices
Complete blockchain nodes

Isolated enclave VM

An isolated enclave VM sits beside a parent workload and exposes restricted interfaces.

AWS Nitro Enclaves allocates isolated CPU and memory from a parent EC2 instance. The enclave has no normal persistent storage or external networking and communicates with its parent through a local virtual socket. It can request signed attestation documents from the Nitro Hypervisor.

This architecture is suitable for:

Key operations
Signing services
Private comparison
Tokenization
Decryption services
Small confidential backends

Confidential container

A confidential container places a container workload inside a confidential VM.

It is useful when:

The team already uses Kubernetes.
Existing container images should be reused.
Workload deployment should remain cloud-native.
The team accepts the guest environment in the TCB.

Confidential Containers separates the workload guest from the untrusted host and uses attestation services, reference values, policy, and a Key Broker Service for resource release.

Confidential accelerator

A confidential accelerator extends the trusted execution path to a GPU or another PCIe device.

The architecture may need to protect:

CPU workload
Device firmware
Driver
Device memory
CPU-to-device communication
Device attestation
Model weights
Input and output buffers

Datacenter GPU architecture showing the GPU package, HBM, high-speed interconnects, I/O, cooling, and its role inside a confidential CPU-GPU computing system.

This option is relevant to:

Large AI models
Private model inference
Confidential training
Scientific workloads
High-volume analytics

The trust boundary becomes more complex because it spans multiple processors and firmware systems.

Comparison of process enclaves, confidential VMs, isolated enclave VMs, confidential containers, and confidential CPU-GPU architectures, showing their protected and untrusted boundaries.

Architecture-selection questions

Ask the following before choosing a platform.

How much code needs protection?

A 500-line key service may fit a process enclave. A large database and API stack may fit a confidential VM more naturally.

Can the application be rewritten?

Process enclaves often require application partitioning. Confidential VMs may support existing applications with fewer changes.

What is the acceptable TCB?

A full guest kernel introduces more trusted code. A process enclave introduces a smaller boundary but may depend on an enclave runtime and more host calls.

What I/O is required?

Ask whether the protected workload needs:

Direct network access
File access
Persistent storage
GPU access
Multiple processes
Dynamic libraries
System services
Kubernetes integration

How will attestation work?

Check:

Evidence format
Certificate chain
Verification libraries
Reference values
Debug-mode claims
Revocation
Offline verification
Vendor service dependencies

How will the application be updated?

Determine whether identity is bound to:

Exact measurement
Signer
Image certificate
Security version
Container image
Guest firmware

Is simulation available?

A simulator is useful for development. A simulator does not provide real hardware isolation or hardware-backed attestation. Do not use successful simulation as evidence that the system is secure on production hardware.

TEE Architecture Selection Decision Tree

Selection example: Private API-key service

The service must:

Store API keys
Release a key only to an approved operation
Handle fewer than ten operations
Expose one narrow API
Run on a cloud server

A process enclave or isolated enclave VM may be a reasonable starting point. A complete confidential VM could work, but it would place more software inside the trusted boundary.

Selection example: Existing AI platform

The system includes:

Python
Model runtime
CUDA libraries
Several services
Large model files
Monitoring agents

A confidential VM combined with a confidential accelerator may require fewer changes than rewriting the entire system into a small enclave. The larger TCB should be recorded and reviewed.

Developer exercise

Choose an architecture for each use case:

1. Validator signing key 2. Private SQL analytics 3. Mobile biometric check 4. Confidential LLM inference 5. Private auction matcher 6. Kubernetes-based document processor

For each choice, explain:

Protected boundary
Trusted components
Required application changes
Attestation method
Main remaining risk

Common mistakes

⚠

**Selecting based on marketing claims** — Start with the threat model and technical architecture. **Assuming a larger boundary is safer** — A larger boundary often contains more code and dependencies. **Assuming a smaller boundary is always better** — A badly designed small enclave can have unsafe host interfaces and missing checks. **Ignoring the development environment** — A simulator does not reproduce every hardware behaviour or security property. **Ignoring device trust** — A confidential GPU adds device firmware, drivers, interconnect security, and device attestation to the system.

Key takeaways

Select the smallest boundary that supports the workload.
Process enclaves reduce TCB size but increase partitioning work.
Confidential VMs increase compatibility but trust the guest environment.
Confidential containers adapt VM-level TEEs to container workflows.
Confidential accelerators create a multi-device trust chain.
Measure performance and compatibility on the actual platform.

Check your understanding

1. Why can a confidential VM have a larger TCB than a process enclave? 2. When is application compatibility more important than minimum TCB size? 3. Why is a simulator not a security environment? 4. Which new components enter the trust model with a confidential GPU? 5. Why should platform selection follow the threat model?