What Is a Trusted Execution Environment (TEE)?

Introduction

In 2023, Microsoft’s Azure Confidential Computing team disclosed that multiple large financial institutions were running AI fraud-detection models in the cloud but faced a fundamental problem: they could not share customer transaction data with the cloud provider’s analysts for debugging without violating banking privacy regulations. The solution was not a new privacy policy — it was a trusted execution environment. By running the inference workload inside a hardware-isolated enclave, the bank kept data encrypted from the platform operator at all times, even while the computation ran. TEEs have become the foundational technology for any scenario where you need to process sensitive data on infrastructure you do not fully control.

What Is a Trusted Execution Environment?

A trusted execution environment (TEE) is a secure, isolated processing region inside a main processor that provides hardware-enforced confidentiality and integrity for code and data. Software running inside a TEE — called trusted applications — cannot be read or modified by the regular operating system, the hypervisor, other applications, or even privileged administrators. The isolation is not enforced by software policy, which can be bypassed; it is enforced by the CPU hardware itself.

The concept was formalized by GlobalPlatform, the industry standards body that defines TEE architecture, APIs, and security requirements. Under GlobalPlatform’s model, every device or server has two distinct execution environments running in parallel. The Rich Execution Environment (REE) is the normal world — the everyday OS, applications, and drivers. The TEE is the secure world, accessible only through strictly controlled interfaces, with its own isolated memory and storage.

A TEE protects three security properties simultaneously: confidentiality (data inside cannot be read by outsiders), integrity (code and data inside cannot be modified), and attestation (a remote party can cryptographically verify what is running inside).

How a Trusted Execution Environment Works

A TEE’s security rests on a chain of hardware mechanisms that operate before and during every computation.

Step 1 — Hardware partitioning. When a TEE-capable processor boots, the hardware establishes isolated memory regions that are physically inaccessible to non-TEE software. On ARM processors, the TrustZone security extension divides every system resource — CPU registers, RAM, cache, and peripheral buses — into Secure World and Normal World partitions. On Intel and AMD platforms, memory encryption engines encrypt TEE memory with keys that never leave the CPU die.

Step 2 — Secure boot and measurement. Before any trusted application runs, the TEE records a cryptographic measurement — a hash of the code and configuration loaded into the enclave. This measurement is the baseline for proving authenticity later.

Step 3 — Isolated execution. The trusted application executes entirely within the TEE. Calls to hardware resources (network, storage, display) must pass through a narrow, auditable interface called a Secure Monitor Call (SMC) on ARM, or equivalent transitions on Intel and AMD platforms. The regular OS handles physical I/O but cannot observe or modify the data in transit.

Step 4 — Remote attestation. When a remote server or user needs to confirm that a computation genuinely ran inside a TEE, they request a quote — a hardware-signed report from the CPU that includes the measurement of the loaded code and the hardware’s identity. The receiving party verifies this quote against the chip manufacturer’s attestation certificates, confirming authenticity without requiring trust in the platform operator.

TEE Implementations: TrustZone vs Intel TDX vs AMD SEV

The three dominant TEE architectures target different threat models and deployment contexts.

ARM TrustZone is the most widely deployed TEE architecture, present in virtually every modern smartphone and embedded device. It divides the system at the hardware bus level — both the CPU and the memory controller enforce the boundary — so a fully compromised Android OS still cannot access keys or biometric data stored in the Secure World.

Intel SGX (Software Guard Extensions) protects individual application-level enclaves on x86 servers. Each enclave is a small, encrypted memory region; SGX allows fine-grained isolation of specific workloads — for example, a single cryptographic key management service — while the rest of the application runs normally.

Intel TDX and AMD SEV-SNP operate at the virtual machine level, protecting entire VMs from the hypervisor layer. In a public cloud, your VM’s memory is encrypted with a hardware key that the cloud operator’s hypervisor cannot access. AMD SEV-SNP adds integrity checking so the cloud operator cannot replay or corrupt VM memory pages even without being able to read them.

VIDEO · READY 16:9

PLAY

Confidential Computing and Trusted Execution Environments | Intel Technology

Real-World Use Cases

Mobile payments and authentication. Apple Pay, Google Pay, and Samsung Pay all store cryptographic keys inside TEEs on the device’s application processor or a dedicated security chip. When you authenticate a transaction, the payment token is signed inside the TEE — the OS app never touches the raw key. This is why compromising an iPhone’s iOS does not automatically expose your payment credentials.

Confidential cloud computing. Banks, hospitals, and research institutions increasingly need to run AI models on data they cannot expose to their cloud provider. Azure Confidential Computing, Google Confidential GKE, and AWS Nitro Enclaves all provide TEE-based execution environments. Multiple hospitals can pool encrypted patient records for a joint study inside a TEE without any party — including the cloud operator — seeing another party’s raw data. This is closely related to confidential computing, which TEEs enable at the cloud infrastructure level.

Blockchain and key custody. Cryptocurrency exchanges and digital asset custodians use TEEs to manage private signing keys. The key is generated inside the enclave, never exported in plaintext, and all transaction signing occurs inside the TEE. Even if the server OS is compromised, the attacker cannot extract the key.

Common Mistakes to Avoid

Trusting the TEE boundary unconditionally. TEEs have well-documented attack surfaces. Intel SGX has been vulnerable to several side-channel attacks — including speculative execution attacks like Foreshadow — that leak information by observing cache timing even without breaking the hardware isolation directly. A TEE limits the attack surface; it does not eliminate it. This connects to why side-channel attack mitigations are part of any complete TEE threat model.

Ignoring attestation. A TEE without remote attestation is only half a solution. If you cannot verify what code is running inside the enclave from the outside, an attacker can substitute malicious code and the remote party has no way to detect it. Attestation must be implemented and verified on every connection.

Assuming the TEE covers all data paths. Data that enters or exits a TEE passes through a transition layer that is observable by the REE. Input/output channels must be carefully designed; plaintext data in REE memory — even briefly — can be targeted by a compromised OS. Encryption at rest and in transit controls complement TEE protection by ensuring data is protected before and after the enclave boundary.

Getting Started with Trusted Execution Environments

Identify your threat model first. TEEs differ significantly in what they protect against. If your concern is a malicious application on a mobile device, ARM TrustZone is your architecture. If your concern is a cloud operator or co-tenant VM attacking your workload, Intel TDX or AMD SEV-SNP is the right layer. Choosing the wrong TEE level for your threat model provides false assurance.

Use attestation libraries. Intel SGX provides DCAP (Data Center Attestation Primitives) for enterprise attestation. AMD SEV-SNP uses the AMD Secure Processor for attestation. ARM provides a Realm Management Extension in ARMv9. Use the vendor-supplied attestation stack rather than building custom verification — the attack surface of a custom attestation implementation is significant.

Pair TEEs with your existing public key infrastructure. Remote attestation produces a signed quote — a document that means nothing unless you can verify the signing chain back to the hardware manufacturer’s root certificate. Integrate TEE attestation verification into your PKI and certificate management workflows from day one.

Start with managed TEE services. For most teams, Azure Confidential VMs, Google Confidential GKE, or AWS Nitro Enclaves provide TEE isolation with the attestation infrastructure already managed by the cloud provider. This is the lowest-friction path to production TEE deployments, and confidential computing platforms abstract many of the raw TEE integration complexities.