How Trusted Execution Environments Evolved

TEEs did not appear from one invention

Modern TEEs come from several older areas of computer security:

• Secure coprocessors
• Smart cards
• Trusted computing
• Hardware roots of trust
• Secure boot
• Mobile security
• Virtualization
• Memory encryption
• Remote attestation

The history matters because each architecture solves a slightly different problem.

Early secure hardware

Before modern application enclaves, sensitive cryptographic operations were often moved into dedicated hardware.

Examples included:

• Smart cards
• Hardware Security Modules
• Secure cryptographic coprocessors
• Payment security chips
• Trusted Platform Modules

These systems were designed mainly to protect narrow assets such as keys, credentials, measurements, or payment data. They were not usually built to run large general-purpose applications.

Trusted computing and TPMs

Trusted computing introduced ideas such as:

• Hardware-backed platform identity
• Measured boot
• Protected measurement registers
• Device attestation
• Keys bound to platform state

A Trusted Platform Module can store measurements and protect keys, but it does not normally provide a general-purpose private execution environment for an application.

TPMs helped establish many concepts later used in TEE attestation.

Arm TrustZone

Arm TrustZone introduced hardware support for dividing a system into separate security states commonly described as Secure World and Normal World.

TrustZone first appeared in the Arm A-profile architecture before becoming widely used across mobile and embedded devices. Hardware can assign memory, peripherals, interrupts, and execution resources to a security state.

This model became important for:

• Mobile payments
• Biometric processing
• Device authentication
• Digital rights management
• Secure boot services
• Protected key handling

TrustZone is a system-wide security architecture. Its security depends heavily on how the device manufacturer designs the secure software stack.

Process-level application enclaves

Intel Software Guard Extensions introduced protected application enclaves into mainstream server processors.

Instead of placing an entire secure operating system in a separate world, SGX allows selected application code and data to run inside enclave memory.

This reduces the size of the application boundary, but developers may need to split the application into trusted and untrusted parts.

Intel describes SGX as application isolation technology designed to protect selected code and data while they are in use.

Confidential virtual machines

Process enclaves can require major application changes.

Confidential virtual machines use a larger boundary. They attempt to protect a complete guest VM from the host hypervisor and infrastructure operator.

AMD Secure Encrypted Virtualization began with VM memory encryption. Later versions added encrypted register state and stronger integrity and page-ownership protections. AMD SEV-SNP is designed to resist several classes of hypervisor-controlled memory remapping and replay attacks.

Intel TDX also creates protected virtual machines called Trust Domains.

The confidential VM model became attractive because existing operating systems and applications can often run with fewer changes than in a small process enclave.

Cloud enclave services

Cloud providers began offering managed forms of isolated execution.

AWS Nitro Enclaves allows a parent EC2 instance to create a restricted enclave with isolated CPU and memory. Nitro Enclaves supports signed attestation documents and integration with AWS Key Management Service.

This model gives developers a restricted environment without requiring them to design the underlying hardware architecture.

Confidential containers

Cloud-native systems increasingly run applications as containers.

Confidential container architectures place container workloads inside confidential virtual machines. This keeps the container workflow while moving the security boundary below the guest kernel and workload environment.

The result is usually more compatible with existing cloud software, but the guest operating system and support components become part of the trusted boundary.

Confidential accelerators

AI and scientific workloads often require GPUs and other accelerators.

Modern confidential computing platforms are extending protection to:

• GPU memory
• Accelerator firmware
• CPU-to-GPU communication
• Device identity
• Accelerator attestation

This creates a larger system containing more than one trusted processor.

Arm Confidential Compute Architecture

Arm CCA adds a confidential-computing model based on isolated environments called Realms.

Arm describes CCA as a combination of hardware and software components intended to protect the confidentiality and integrity of Realm workloads from other software on the platform.

CCA is different from the traditional TrustZone Secure World model. It is designed to support confidential workloads with their own isolated Realm execution state.

The direction of evolution

TEE evolution shows three major trends:

Smaller trusted boundaries — Process enclaves try to protect only the most sensitive application code.

Easier application migration — Confidential VMs allow existing operating systems and applications to run inside a larger protected boundary.

Wider hardware coverage — Modern systems are extending protection from CPUs to GPUs, devices, network interfaces, and distributed workloads.

The trade-off remains the same:

• A smaller boundary may be easier to review but harder to build for.
• A larger boundary may be easier to use but includes more trusted software.

Key takeaways

• Modern TEEs developed from secure hardware, trusted computing, mobile security, and virtualization.
• TrustZone created system-wide secure and normal states.
• SGX introduced application-level enclaves.
• SEV-SNP and TDX protect complete virtual machines.
• Cloud services made TEE deployment more accessible.
• Newer systems extend confidential computing to containers and accelerators.