Backdrop: What are TEEs and adjacent technologies?
What is a TEE?
A Trusted Execution Environment (TEE) is an isolated computing context that provides:
Confidentiality and integrity of code and data inside the TEE, even if the host OS, hypervisor, or firmware is compromised.
A measurable identity, meaning a cryptographic measurement of the code and configuration.
Attestation, i.e., a cryptographic proof (signed by silicon-rooted keys) that communicates:
what code is running,
on which hardware,
and in what security state.
Sealed storage, enabling encryption of data at rest using keys derived from TEE identity.
Controlled I/O and IPC bridges to communicate with the untrusted world.
TEE design families:
Process-/Enclave-style TEEs
Examples: Intel SGX, RISC-V Keystone
Isolation below the OS, using a process-like abstraction.
VM-style / Confidential VM TEEs
Examples: AMD SEV-SNP, Intel TDX, IBM PEF, IBM s390x Secure Execution
Isolation below the hypervisor, protecting whole virtual machines.
Additionally, secure-world TEEs (e.g., Arm TrustZone / Arm CCA) partition the CPU into secure and normal worlds.
Threat model
Adversary capabilities:
Malicious kernel, hypervisor, co-tenant, or cloud administrator
Physical attackers (to a limited, realistic extent)
TEE protects:
Memory and state inside an enclave/realm/TD/secure world
Confidentiality and integrity of code and secrets
Not fully protected without additional controls:
Side-channels (cache/branch/speculative execution)
Denial of service
Traffic analysis
Plaintext I/O outside the TEE boundary
Developer bugs and logic flaws
Core building blocks
Key architectural components:
Isolation primitives: memory encryption engines, integrity/Merkle trees, page-table tagging, secure execution levels.
Boot / roots of trust: immutable ROM, firmware/microcode, device-unique keys, certificate chains.
Attestation pipeline: measurement → report → endorsement (chip/vendor certs) → remote attestation.
Sealing keys: derive per-enclave/per-CPU encryption keys for data at rest.
Bridging mechanisms (untrusted ↔ trusted world):
SGX: ECALL / OCALL
TrustZone / CCA: SMC calls
SEV-SNP: GHCB
TDX: TDVMCALL
Lifecycle phases: load → measure → initialize → attest → run → update/rotate → teardown
Key terminology
Generic
Measurement: cryptographic hash of code and configuration used as identity.
Local vs remote attestation: local (same machine peers) vs remote (external verifier).
Sealing: encrypting data using a key derived from TEE identity.
Provisioning: injecting secrets after attestation verification.
Intel SGX
Enclave: isolated region for code + data.
MRENCLAVE / MRSIGNER: measurement of code / signer identity.
QE / PCE / LE: Quoting / Provisioning / Launch enclaves.
DCAP / EPID: attestation schemes.
MEE / MECT: memory encryption + integrity tree.
Intel TDX (VM TEE)
TD: Trusted Domain (guest VM).
TDX Module: isolation logic below hypervisor.
TDVMCALL: interface for TD ↔ VMM.
Quote: attestation artifact.
AMD SEV family (VM TEE)
SEV / SEV-ES / SEV-SNP: baseline / encrypted state / secure nested paging (adds integrity).
PSP: Platform Security Processor.
ASK/ARK / CEK/VCEK: AMD attestation key hierarchy.
GHCB: Guest-Hypervisor Communication Block.
Arm TrustZone (secure world)
Normal vs Secure world: CPU partition.
EL3 / Monitor / SMC: world switching.
Secure OS / TEE: OP-TEE, QSEE, Kinibi.
TA / CA: Trusted Application vs Client Application.
GlobalPlatform TEE: common API/spec ecosystem.
Arm CCA (Realm-based)
Realm: new isolated world (beyond Secure/Normal).
RMM: Realm Management Monitor.
REC: Realm Execution Context.
CCA Attestation: vendor-signed attestation for realms.
IBM platforms
PEF: Protected Execution Facility.
Ultravisor: firmware enforcing TEE policy.
s390x Secure Execution: protected virtualization on IBM Z.
RISC-V
Keystone: enclave framework.
SM: Security Monitor.
Apple / Mobile SoCs
Secure Enclave (SEP): co-processor TEE.
Keybags / UID key: device-bound keying material.
Android TEEs: TrustZone (with Vendor TEE OS) + Android StrongBox (sometimes with a separate secure element).
Attestation in practice
TEE creates a report (measurements + security version numbers).
A device-local trusted service signs the report using endorsement keys anchored in silicon and a vendor cert chain.
A relying party verifies:
signature and cert chain,
measurements/configuration (hashes, config, PCR/SVN levels),
policies (version, signer identity, etc.).
If valid, the verifying party securely provisions secrets.
Developer surface
GlobalPlatform TEE APIs (client/core) on TrustZone TEEs (OP-TEE, commercial TEEs).
Intel SGX SDK, Open Enclave SDK, Gramine/Graphene, SCONE, Occlum, Enarx: higher-level runtimes for enclaves/TEE portability.
TDX/SEV-SNP Confidential VM tooling: use normal OS images; add attestation agent (e.g., AK/SNP/TDX agents) and paravisor interfaces.
Keystone SDK on RISC-V.
Non-comprehensive platform map (by abstraction)
Process-/enclave-style TEEs
Intel SGX (client & server generations; strong process isolation, memory integrity trees, DCAP attestation).
RISC-V Keystone (open-source, research-to-productization).
Academic lineage: Sanctum, MI6 (conceptual predecessors).
VM-style TEEs (Confidential VMs)
AMD SEV → SEV-ES → SEV-SNP (widely used in clouds; memory encryption + integrity; attestation via PSP).
Intel TDX (similar goal; TDs protected from VMM with TDX Module; remote attestation).
IBM POWER PEF (Ultravisor-secured VMs).
IBM Z (s390x) Secure Execution / Protected Virtualization.
Arm CCA Realms (armv9-era: Realm world + RMM, designed for cloud-scale CVMs).
Secure-world / split-world TEEs (services & TAs)
Arm TrustZone implementations:
OP-TEE (open-source TEE OS; common in embedded/edge).
Qualcomm QSEE, Trustonic Kinibi, Huawei iTrustee, Samsung TEEgris (commercial TEEs on phones/SoCs).
Apple Secure Enclave (SEP) (coprocessor TEE for key/biometric policy).
Device/accelerator TEEs
NVIDIA Hopper (H100) Confidential Computing (GPU-side isolated execution + attestation for kernels).
AMD GPU enclaves (emerging, often coordinated with CPU-side CVMs).
SmartNIC/DPUs (e.g., BlueField) with RoT and attestation to run network/security functions in a TEE-like domain.
How TEEs isolate memory/state
Encrypt-only (SME/SEV) vs encrypt+integrity (SGX MEE, SEV-SNP RMP, TDX).
Page table ownership: second-stage/NPT/EPT with protected metadata (e.g., RMP for SEV-SNP, EPT attributes for SGX/TDX).
World partitioning (TrustZone S/NS memory tagging; CCA introduces a new Realm world).
Microcode/firmware arbitration (PSP, TDX module, ultravisor, monitor).
Security caveats
Side channels: timing/cache/branch/spectre, page-fault, controlled-channel. Use constant-time crypto, oblivious access, page-level padding, partitioned caches where possible.
I/O exposure: data must be encrypted/authenticated end-to-end before leaving the TEE.
Updatability: track SVNs/TCBs, require minimum versions in attestation policy.
Supply chain: pin vendor certs, check revocation (CRLs/OCSP/equivalents).
Denial of Service: the host can starve/suspend your TEE.
Standards & ecosystems
GlobalPlatform defines TEE Internal Core and Client APIs as well as management and compliance standards for TrustZone-class TEEs.
Confidential Computing Consortium (CNCF/LF) defines standards for attestation formats and confidential computing runtimes which rely on underlying TEE / SE for security guarantees. For example projects like Enarx, Open Enclave etc.
IETF RATS: Defines the syntax and semantics for attestation, specifically EAT (Entity Attestation Token) & Attestation Results patterns (with CBOR/COSE/JWT encodings increasingly used). It standardizes how to convey claims about a TEE's state (e.g., "this TEE is running certified firmware X, version Y, with measurements Z").
Common Criteria EAL (Evaluation Assurance Level): Provides independent evaluation/proof that a specific implementation of a TEE or SE (also known as Target of Evaluation or TOE), adhering to any of the standards mentioned above, has been built and evaluated to a rigorous level of assurance as per target specifications, with no exploitable vulnerabilities at that level. EAL levels are defined from EAL1 to EAL7 with each increasing level having stricter requirements to prove security assurances (in addition to meting the requirement of previous levels). Below is a table for quick reference.
EAL1
Functionally Tested
Provides analysis of the security functions, using a functional and interface specification of the TOE, to understand the security behaviour
Low-risk, need a basic check. (e.g., consumer OS)
EAL2
Structurally Tested
Independent testing of the security functions, evidence of developer "black box" testing, and evidence of a development search for obvious vulnerabilities.
Legacy systems; requires developer cooperation
EAL3
Methodically tested and checked
The analysis is supported by "grey box" testing, selective independent confirmation of the developer test results, and evidence of a developer search for obvious vulnerabilities. Development environment controls and TOE configuration management are also required.
Good balance of rigor vs. cost. (e.g., network gear)
EAL4
Methodically designed, tested and reviewed
Analysis is supported by the low-level design the TOE, and a subset of the implementation. Testing is supported by an independent search for obvious vulnerabilities. Development controls are supported by a life-cycle model, identification of tools, and automated configuration management.
The most common level for commercial security products. (e.g., TEEs, Smart Cards)
EAL5
Semi-formally designed and tested
Analysis includes all of the implementation. Assurance is supplemented by a formal model and a semiformal presentation of the functional specification and high level design, and a semiformal demonstration of correspondence. The search for vulnerabilities must ensure relative resistance to penetration attack. Covert channel analysis and modular design are also required.
High-assurance for high-risk environments. (e.g., Banking, Military)
EAL6
Semi-formally verified designed and tested
Analysis is supported by a modular and layered approach to design, and a structured presentation of the implementation. The independent search for vulnerabilities must ensure high resistance to penetration attack. The search for covert channels must be systematic.
Extremely high-assurance for significant risks
EAL7
Formally verified design and tested
The formal model is supplemented by a formal presentation of the functional specification and high level design showing correspondence. Evidence of developer "white box" testing and complete independent confirmation of developer test results are required.
For the most critical, small-scale applications
Similar / adjacent tech
TPM (dTPM/fTPM): not a TEE for general code, but a measurement/keys co-processor; often supplies PCR-based boot trust and can help bind secrets to a platform state.
Secure Elements / Smartcards (UICC/eSIM, embedded SE, Google StrongBox): isolated chips for keys/identity; narrower execution models than general-purpose TEEs.
HSMs: external appliances/cards that provide isolated crypto + key custody (enterprise/server side).
AWS Nitro Enclaves: software & hypervisor isolation splitting a VM into an enclave VM with no persistent storage/network; not silicon-enclave, but a practical alternative in cloud.
Apple SEP (again): co-processor TEE archetype; not general-purpose for arbitrary apps but sets the reference for UX-grade key protection.
OpenTitan: open silicon root of trust; pairs with TEEs to anchor attestation.
Picking the right model
Whole OS isolation; reuse existing stacks
Confidential VMs (SEV-SNP, TDX, PEF, s390x, Arm CCA)
Minimal TCB, process-level isolation
SGX / Keystone
Mobile / embedded
TrustZone + GlobalPlatform
Device-grade key custody
SEP / Secure Element / TPM / HSM
ML secrecy
GPU TEEs paired with CVM + attestation
Minimal developer toolbox (by target)
SGX: Intel SGX SDK, Open Enclave, Gramine/Graphene, SCONE, Occlum.
SEV-SNP/TDX/PEF/s390x: Standard guest OS + attestation agent (e.g., SNP/TDX agents), KMS plugins for secret injection, distroless base images for smaller TCB.
TrustZone/CCA: OP-TEE + GlobalPlatform Client/Core APIs; vendor TEEs similar shape.
Keystone: Keystone SDK; host SM + runtime in enclave.
Attestation Artifacts (by vendor)
SGX
Quote (EPID/DCAP), Certificate Chain to Intel Root CA, MRENCLAVE/MRSIGNER/ISVSVN
TDX
TD Quote with TCB components (TDX-SEAM microcode)
SEV-SNP
Attestation report (signed by PSP), VCEK Certificate per CPU, RMP based integrity claims
Arm CCA
Realm attestation token (EAT/CBOR), Realm Measurement + RMM and firmware versions
IBM
Vendor-signed reports via ultravisor
TrustZone
Platform-specific implementations, usually through GlobalPlatform APIs or vendor attestation flows.
NVIDIA Confidential Compute
HSI (H100-Style) Attestation Report, signed by GPU Root of Trust, includes GPU TCB (FW, BL, Config) and user-defined measurement (Nonces, VM ID)
Architectural Spectrum of TEE Implementations
Software-defined TEE
AWS Nitro Enclaves, gVisor-like isolation, Enarx (on CVMs), library OS TEEs
Software isolation (hypervisor/VM or namespace boundaries)
Cloud firmware + VM configuration
Flexible, low hardware trust; relies on hypervisor/firmware correctness
CPU-assisted (on-die)
Intel SGX, AMD SEV-SNP, Intel TDX, Arm CCA
Hardware memory encryption + access control
CPU microarchitecture / microcode
Strong isolation from host OS/VMM; hardware-backed attestation
SoC secure-world partition
Arm TrustZone, OP-TEE, Qualcomm QSEE
Secure/Normal world split, hardware arbitration
Secure boot ROM, fuses
Medium–high: secure boot verified; isolation enforced by EL3 monitor
Dedicated co-processor TEE
Apple Secure Enclave (SEP), Google Titan M, TPM 2.0, Android StrongBox
Physically separate core + dedicated memory
Separate firmware & RoT
Very high for key management; narrow compute model
Standalone secure device / SE / HSM
Smartcard, SIM, YubiKey, Hardware Security Modules
Separate chip w/ tamper resistance
Embedded secure element & crypto coprocessor
Highest physical & logical assurance (Common Criteria EAL5–EAL7)
TEE vs SE: Conceptual and Security Comparison
Execution model
General-purpose code execution within isolated context
Limited-purpose (crypto ops, key mgmt)
Integration
On-SoC / CPU-based (shared die or logical partition)
Separate chip or coprocessor
Trust base
Depends on CPU vendor RoT, firmware, and boot chain
Dedicated silicon with minimal firmware, physically separate
Tamper resistance
Typically not tamper-resistant (focus on logical isolation)
Physical anti-tamper and side-channel protections
Physical attack surface
Higher (shared die, shared power/caches)
Lower (hardened packaging, fault detection)
Attestation
Software + vendor key infrastructure (DCAP, PSP, Realm tokens)
Static identity via hardware certificates (endorsement keys)
Performance
Near-native execution; scalable
Limited compute, I/O bottleneck
Certification level (typical)
EAL2–EAL4+ (logical separation)
EAL5+ to EAL7 (physical + logical separation)
Use cases
Confidential computing, trusted apps, enclaves, ML inference
Key storage, payment, identity, DRM, FIDO
Example systems
Intel SGX, AMD SEV, Arm TrustZone/CCA, IBM PEF
TPM 2.0, Titan M, Apple SEP, YubiKey, Smartcard
Security Assurance / Certification Landscape
Common Criteria (ISO/IEC 15408)
Evaluates security functionality and assurance (EAL1–EAL7)
SEs, HSMs, TPMs, some TEEs
EAL1–4: software assurance; EAL5–7: high physical tamper resistance
FIPS 140-2/3
Cryptographic module validation
SEs, HSMs, TPMs
Levels 1–4; Level 3–4 require tamper response
GlobalPlatform TEE Protection Profile (GP TEE PP v1.3)
Logical security of TEEs
Arm TrustZone/OP-TEE, Kinibi, QSEE
Common Criteria EAL2+ baseline for TEEs
EMVCo
Smartcards, payment SEs
SEs / SIMs
Security & functional compliance (no EAL number)
PSA Certified (Arm ecosystem)
Embedded/IoT TEEs & RoTs
TrustZone-based designs
Level 1–3 map to EAL2–EAL4 equivalence
Summary Axes for Classification
Dimension | Category | Example
Integration:
Software-only isolation → Nitro Enclaves, gVisor
CPU hardware isolation → SGX, SEV, TDX, CCA
SoC partition → TrustZone
Dedicated co-processor → SEP, TPM
External secure device → HSM, SE, Smartcard
Trust Boundary:
Logical (CPU microcode boundary)
Physical (dedicated chip or tamper mesh)
Certification Potential:
Logical-only (EAL2–EAL4) → typical TEEs
Logical + physical (EAL5–EAL7) → SEs/HSMs
Security Guarantees Tradeoff:
TEE: stronger flexibility, weaker physical protection
SE: stronger hardware assurance, limited programmability
TEE & Secure Element Landscape
↑ Higher Assurance / Tamper Resistance / EAL Level
|
| ┌──────────────────────────────┐
| │ STANDALONE SECURE DEVICES │
| │ (EAL6–EAL7 / FIPS 140-3 L3) │
| │ │
| │ • Hardware Security Modules │
| │ • Smartcards / SIM / eSIM │
| │ • YubiKey, NitroKey │
| │ • Payment SEs, JavaCard │
| └──────────────┬───────────────┘
| │
| │
| ┌──────────────┴───────────────┐
| │ CO-PROCESSOR TEEs / SEs │
| │ (EAL5–EAL6 / PSA L3) │
| │ │
| │ • Apple Secure Enclave (SEP)│
| │ • Google Titan M / Titan │
| │ • TPM 2.0 / StrongBox SE │
| │ • Embedded Secure Elements │
| └──────────────┬───────────────┘
| │
| │
| ┌──────────────┴───────────────┐
| │ SOC / CPU PARTITION TEEs │
| │ (EAL2–EAL4+ / GP TEE PP) │
| │ │
| │ • Arm TrustZone / OP-TEE │
| │ • Qualcomm QSEE / Kinibi │
| │ • Huawei iTrustee / TEEgris │
| │ • Arm CCA (Realms, RMM) │
| └──────────────┬───────────────┘
| │
| │
| ┌──────────────┴───────────────┐
| │ CPU-ASSISTED TEEs │
| │ (EAL2–EAL4, SW+HW mixed) │
| │ │
| │ • Intel SGX / TDX │
| │ • AMD SEV-SNP │
| │ • IBM PEF / s390x SE │
| │ • RISC-V Keystone │
| └──────────────┬───────────────┘
| │
| │
| ┌──────────────┴───────────────┐
| │ SOFTWARE-DEFINED TEEs │
| │ (EAL1–EAL2, Logical only) │
| │ │
| │ • AWS Nitro Enclaves │
| │ • gVisor / Kata Containers │
| │ • Enarx (CVM-hosted) │
| │ • Graphene / SCONE (SGX soft frameworks)
| └──────────────────────────────┘
|
Interpretation Matrix
Integration
Software-defined (Nitro, gVisor)
SoC-integrated (SGX, TrustZone)
Separate chip (TPM, SE, HSM)
Isolation Type
Software process/VM boundary
Hardware-enforced memory partition
Physical silicon barrier
Attestation Root
Firmware / platform key
CPU vendor RoT / Boot ROM
Device-specific key, cert chain
Certification (EAL/FIPS)
EAL1–EAL2
EAL2–EAL4+
EAL5–EAL7 / FIPS 140-3 L3+
Target Use Case
Cloud & container TEEs
General compute / mobile security
Key custody, payments, identity
Last updated