What Is a Trusted Execution Environment?

A working definition

A Trusted Execution Environment is an isolated execution environment designed to protect sensitive code and data from components outside its security boundary.

A TEE normally relies on hardware and supporting firmware to enforce this separation.

GlobalPlatform describes a TEE as an environment separated from a Rich Execution Environment, with protected services and trusted applications operating inside the trusted side of the architecture.

The Rich Execution Environment (REE) is the normal environment in which the main operating system and ordinary applications run.

Examples of the REE include:

Android running outside a TrustZone trusted environment
Linux running outside an application enclave
A cloud hypervisor running outside a confidential virtual machine
A parent EC2 instance running beside an AWS Nitro Enclave

What happens in ordinary execution?

A normal application depends heavily on the operating system.

The operating system controls:

Memory allocation
Virtual memory
Process scheduling
File access
Network communication
Devices
Interrupts
System calls
Debugging

If the operating system is compromised, the application may lose control over its code, data, and execution.

A container does not normally change this relationship. Containers share the host kernel, so the host operating system remains highly privileged.

What changes with a TEE?

A TEE introduces an additional protection boundary.

Depending on the architecture, that boundary may protect:

A small function
Selected application code
One process enclave
A complete virtual machine
A secure operating system
A cryptographic subsystem
A GPU workload

Hardware attempts to prevent untrusted software from directly reading or modifying the protected code and data.

Intel SGX, for example, protects selected code and data inside application enclaves. Intel TDX moves the boundary to the virtual-machine level.

Common properties of a TEE

Different platforms provide different features, but TEEs commonly include some combination of the following.

Isolated execution

The protected code runs in an environment separated from untrusted software.

Memory confidentiality

Components outside the boundary should not be able to directly read protected memory.

Memory or state integrity

Unauthorized changes to protected code or data should be blocked or detected.

Measurement

The platform creates a cryptographic representation of the initial code, configuration, or software state.

Attestation

The platform produces evidence that another party can verify.

Protected key operations

Keys may be generated, stored, derived, or used inside the protected environment.

Protected storage

Application data may be encrypted and authenticated before it is stored outside the TEE.

Not every TEE provides every property in the same form.

What does the word trusted mean?

A TEE is trusted because the system depends on it. It is not trusted because it has been proven incapable of failure.

A TEE may depend on:

Processor design
Hardware implementation
Microcode
Firmware
Secure boot
Runtime software
Application code
Attestation keys
Vendor certificate infrastructure

A weakness in any critical trusted component may reduce or break the expected protection.

Where does plaintext exist?

It is common to hear that a TEE allows data to remain encrypted while being processed. That explanation can be misleading.

Normal CPU instructions need values they can operate on. Data is usually decrypted within a protected part of the processor or trusted environment before instructions use it.

The goal is not always to compute directly over ciphertext. The goal is to ensure that readable data is available only inside an intended protected boundary.

💡

Homomorphic encryption is different — it aims to support computation directly over encrypted values without decrypting them. A TEE and homomorphic encryption address the same problem with very different trust and performance trade-offs.

A TEE protects execution, not intent

Consider a genuine TEE running the following application:

`` receive_private_key() send_private_key_to_attacker() ``

The TEE may run this code exactly as measured. It may stop the host operating system from reading the private key. It will not automatically stop the approved application from exporting the key.

A TEE protects the execution of loaded code. It does not determine whether the code follows a good privacy policy.

This is why TEE systems also need code review, reproducible builds, approved measurements, attestation policies, safe interfaces, and output controls.

Example: Secure biometric processing

Apple describes its Secure Enclave as an isolated security subsystem designed to protect sensitive information even when the main application processor kernel is compromised. It supports protected cryptographic operations and biometric security functions.

This does not mean every application on the device runs inside the Secure Enclave. The protected boundary is built around selected security operations and assets.

💡

**Think about it** A TEE can run malicious code perfectly. If a developer ships an application that exports private keys, the TEE will protect that export from the host — but cannot protect users from the application itself. What else is needed beyond hardware isolation?

Key takeaways

A TEE is an isolated execution environment.
Hardware and firmware normally enforce its security boundary.
The protected scope differs between architectures.
TEE features may include isolation, memory protection, measurement, attestation, and key protection.
A TEE can run insecure or malicious code.
A TEE does not remove every trusted component.