Trusted Execution Environments in Embedded Systems
Trusted execution environments (TEEs) represent a fundamental approach to embedded systems security, providing hardware-enforced isolation that protects sensitive code and data from the rest of the system. By creating secure enclaves within processors, TEEs enable applications to execute in protected regions where even privileged software such as operating systems and hypervisors cannot access or tamper with the protected content.
This hardware-based security model addresses a critical limitation of software-only protections: if an attacker gains control of the operating system or firmware, traditional software security measures become ineffective. TEEs solve this problem by establishing a hardware root of trust that remains secure even when the normal execution environment is compromised. This capability has become essential for mobile devices, cloud computing, Internet of Things deployments, and any embedded system handling sensitive operations.
This article approaches trusted execution environments from the device side: how the isolation is built into embedded and mobile processors, and what integrating a secure world into an embedded product requires. A companion article, Trusted Execution Environments under privacy-preserving technologies, treats the same hardware primitive from the confidential computing side, with fuller coverage of remote attestation, cloud deployment models, and enclave key management.
This article covers choosing and using a trusted execution environment on a device: the design models, what each vendor architecture offers, dedicated security processors, and the integration work. The privacy-technology treatment, covering confidential computing, remote attestation, key management, and the trust model, is at Trusted Execution Environments under privacy-preserving technologies.
Fundamental Concepts
Understanding trusted execution environments requires familiarity with several core concepts that define how these systems establish and maintain security:
Hardware root of trust: TEEs derive their security guarantees from hardware mechanisms that cannot be altered by software. This root of trust typically begins in read-only memory containing immutable boot code, cryptographic keys fused into silicon during manufacturing, or dedicated security processors. Because these foundations exist in hardware, they resist the software-based attacks that can compromise operating systems and applications.
Isolation and memory protection: TEE architectures partition processor resources into secure and non-secure domains. Hardware-enforced access controls prevent code running in the non-secure domain from reading or writing memory belonging to the secure domain. This isolation extends to peripherals, interrupts, and other system resources, creating comprehensive separation between protected and unprotected execution contexts.
Attestation: TEEs can prove their identity and integrity to remote parties through attestation mechanisms. The hardware generates cryptographically signed evidence about the TEE's state, including what code is executing within the secure enclave. Remote systems can verify this attestation to establish trust before sharing sensitive data or granting access to protected services.
Sealed storage: Data can be encrypted such that only the specific TEE that sealed it can unseal and access the contents. This binding to the TEE's identity and state ensures that sensitive data remains protected even if storage media is extracted or the device is compromised in other ways.
Design Models
Commercial TEEs fall into three broad design models. The model determines what the protected unit is, how large the trusted computing base becomes, and how much effort porting an existing application requires.
System partitioning: The processor and the surrounding system-on-chip are split into two or more security states, each with its own memory, peripherals, and interrupts. Arm TrustZone is the canonical example. The protected unit is an entire software stack, so the secure side runs a small trusted operating system alongside the rich operating system. This model suits devices that need a persistent, always-available secure world for services such as key storage and biometric matching.
Process enclaves: The protected unit is a region within a single application's address space. Intel SGX is the canonical example. The trusted computing base is small, because the operating system is excluded from it, but applications must be partitioned into trusted and untrusted halves, and every transition across the boundary carries a cost. This model suits workloads with a compact, well-defined secret, such as a key-handling routine or a private-set-intersection kernel.
Confidential virtual machines: The protected unit is a whole guest virtual machine, isolated from an untrusted hypervisor. AMD SEV-SNP, Intel TDX, and Arm CCA follow this model. The trusted computing base is larger, because it includes the guest operating system, but unmodified applications can be lifted into the protected environment with little or no change. This model dominates cloud confidential computing, where ease of adoption outweighs the benefit of a minimal trusted computing base.
These models are not mutually exclusive. A modern system-on-chip may combine a TrustZone secure world for platform services, a discrete or firmware TPM for measured boot, and confidential virtual machine support for tenant workloads. Choosing among them is largely a question of what the adversary is assumed to control and how much software rework the deployment can absorb.
Arm TrustZone Technology
Arm TrustZone represents one of the most widely deployed TEE architectures, integrated into billions of mobile devices, embedded systems, and IoT products. Unlike enclave-based approaches that protect individual applications, TrustZone divides the entire system into a secure world and a normal world, each with dedicated resources. The technology appears in two forms: TrustZone for Cortex-A application processors, and the lighter-weight TrustZone for Cortex-M (introduced with the Armv8-M architecture) for microcontrollers, which performs world switching automatically as part of function calls rather than through a software monitor.
Architecture Overview
TrustZone extends the Arm processor architecture with a security state that propagates throughout the system. On Cortex-A processors, every memory access, peripheral transaction, and interrupt carries this security designation (signaled on the bus by the non-secure, or NS, bit), enabling hardware to enforce isolation at every level. The processor switches between secure and normal worlds through a special instruction, the Secure Monitor Call (SMC), which transitions control to secure monitor code running at the highest secure privilege level to manage world switching.
The secure world runs its own trusted operating system (Trusted OS) and trusted applications (TAs). Common trusted operating systems include OP-TEE (the Open Portable Trusted Execution Environment), Trusty, and proprietary implementations from silicon vendors. The normal world runs the rich operating system (such as Linux or Android) and normal applications that can request services from the secure world through well-defined interfaces.
Memory and Peripheral Protection
The TrustZone Address Space Controller (TZASC) and TrustZone Memory Adapter (TZMA) configure memory regions as secure or non-secure. The secure world can access all memory, while the normal world can access only non-secure memory. This asymmetric access model allows secure software to share data with the normal world when appropriate while preventing unauthorized access to secure regions.
Peripherals can also be designated as secure, making them accessible only from the secure world. This capability protects cryptographic accelerators, secure storage interfaces, and other sensitive hardware from normal world access. The TrustZone Protection Controller (TZPC) manages peripheral security attributes, enabling flexible configuration based on system requirements.
Interrupt Handling
TrustZone uses interrupt grouping in the Generic Interrupt Controller to ensure secure interrupts cannot be intercepted by normal world software. Secure interrupts can preempt normal world execution and trigger immediate world switching, ensuring time-critical security operations receive prompt handling. This architecture maintains responsiveness for security-critical events while allowing normal applications to execute efficiently.
GlobalPlatform TEE Standards
The GlobalPlatform organization defines standards for TEE interfaces that promote interoperability across implementations. The TEE Client API specifies how normal world applications communicate with trusted applications, while the TEE Internal Core API defines the programming interface available to trusted applications themselves. These standards enable portable trusted application development and consistent security properties across devices from different manufacturers.
Intel Software Guard Extensions
Intel Software Guard Extensions (SGX) takes a different approach from TrustZone, focusing on protecting individual application enclaves rather than partitioning the entire system. SGX enclaves execute in encrypted memory regions that remain protected even from system software, including the operating system, hypervisor, and BIOS. Intel deprecated SGX on its client Core processors with the 11th- and 12th-generation families, and it now remains available primarily on Intel Xeon Scalable server processors, where it underpins confidential computing offerings. A visible side effect of that deprecation was the loss of Ultra HD Blu-ray playback on affected desktop platforms, because the disc's digital rights management scheme depended on an SGX enclave.
Enclave Architecture
SGX creates protected memory regions called enclaves within the virtual address space of normal applications, backed by a reserved region of physical memory known as the Enclave Page Cache (EPC). When the processor executes enclave code, it transparently encrypts data written to EPC memory and decrypts data read from it, using keys managed entirely within the processor. This encryption occurs in hardware close to the memory controller, making enclave contents opaque to any software or hardware that attempts to read enclave memory directly.
Enclaves are defined at build time and loaded into protected memory through a measured launch process. Each enclave receives a unique identity (a measurement) based on its code and initial data, enabling attestation that specific code is executing within the enclave. Applications enter enclaves through defined entry points and exit through controlled mechanisms, maintaining security boundaries while allowing necessary interaction with the rest of the system.
Memory Encryption and Integrity
First-generation SGX processors used a Memory Encryption Engine (MEE) that provided both confidentiality and integrity protection for enclave memory. The encryption ensured that reading enclave memory from outside the enclave revealed only ciphertext, while integrity checking detected any tampering, preventing attackers from manipulating enclave data through physical access or compromised system software. The MEE used a Merkle tree (an integrity tree) whose root was stored within the processor, making any modification to enclave memory tamper-evident and causing subsequent access attempts to fail with a hardware exception.
The integrity tree consumed scarce on-die storage and limited how large the EPC could grow, which is why early SGX systems capped the EPC at 128 MB or 256 MB. To enable the much larger EPC sizes available on server platforms, later SGX implementations on Xeon Scalable processors replaced the MEE with AES-XTS total memory encryption (the basis of Intel Total Memory Encryption and Multi-Key Total Memory Encryption). This change traded the MEE's built-in cryptographic integrity tree for far greater capacity, so integrity against a physical adversary on these platforms relies on different mechanisms rather than the original Merkle tree.
Attestation and Sealing
SGX provides both local and remote attestation capabilities. Local attestation allows enclaves on the same platform to verify each other's identity, enabling secure communication between enclaves. Remote attestation generates quotes that remote parties can verify, proving that specific code is running within a genuine SGX enclave on authentic Intel hardware. Early deployments relied on Intel's Enhanced Privacy ID (EPID) attestation service, while newer Data Center Attestation Primitives (DCAP) allow third parties to operate their own attestation infrastructure.
Sealing in SGX allows enclaves to encrypt data for persistent storage. The sealing key derives from the enclave's identity and the platform's root key, ensuring that only the same enclave on the same platform can unseal the data. Enclaves can choose sealing policies based on either the enclave measurement or the signing authority, allowing version upgrades while maintaining access to previously sealed data.
SGX Generations
Intel evolved SGX across multiple generations. Initial implementations had limited EPC sizes (128 MB or 256 MB) because of the overhead of the integrity-protected encryption engine. Second-generation SGX (SGX2) added support for dynamic memory management, letting enclaves add and remove pages at run time rather than committing all memory at creation. The dynamic-memory capability was later formalized as Enclave Dynamic Memory Management (EDMM), which requires operating system support to use. On Xeon Scalable processors the EPC grew by orders of magnitude, reaching as much as 512 GB per socket on some models, reflecting the shift to total-memory-encryption hardware described above and SGX's repositioning as a server-side confidential computing technology.
AMD Secure Encrypted Virtualization
AMD Secure Encrypted Virtualization (SEV) extends the TEE concept to protect entire virtual machines rather than individual enclaves. This approach is particularly suited to cloud computing environments where tenants need protection from the cloud provider's infrastructure and from co-resident workloads.
SEV Architecture
SEV encrypts virtual machine memory using keys managed by the AMD Secure Processor (AMD-SP), a dedicated security co-processor integrated into AMD processors. Each virtual machine receives a unique encryption key, and the hypervisor cannot access the unencrypted contents of guest memory. This architecture allows untrusted hypervisors to manage encrypted VMs without gaining access to their data.
The AMD-SP runs its own firmware and maintains isolation from the main processor cores. It manages encryption keys, handles attestation requests, and provides secure services to the system. Because it operates independently of the main processor and system software, compromising the operating system or hypervisor does not by itself compromise the AMD-SP.
SEV-ES and SEV-SNP
SEV-ES (Encrypted State) extends protection to VM register state, encrypting and integrity-protecting CPU registers when a guest exits to the hypervisor. This prevents the hypervisor from observing or manipulating guest register values, closing an attack vector present in basic SEV.
SEV-SNP (Secure Nested Paging) adds integrity protection to encrypted memory, preventing the hypervisor from replaying old memory contents, remapping guest pages, or aliasing memory. SNP also provides stronger attestation guarantees, enabling guests to verify the integrity of their execution environment before processing sensitive workloads.
Intel TDX and Arm CCA
AMD SEV established the confidential virtual machine model, and Intel and Arm subsequently introduced comparable architectures. All three protect a guest from the hypervisor, but they differ in how the protected environment is managed and measured.
Intel Trust Domain Extensions
Intel Trust Domain Extensions (TDX) protect a guest virtual machine, called a trust domain, from the host operating system, the hypervisor, firmware, system management mode, and platform administrators. TDX arrived with the 4th-generation Xeon Scalable processors (Sapphire Rapids) in 2023 and represents Intel's server-side successor to the process-enclave approach of SGX.
Rather than placing all security logic in microcode, TDX introduces a new processor mode called Secure Arbitration Mode (SEAM) that hosts a signed, Intel-authored TDX Module. The module mediates every transition between the hypervisor and a trust domain, manages the per-domain memory encryption keys supplied by Multi-Key Total Memory Encryption, and enforces the page-ownership metadata that prevents the hypervisor from remapping or aliasing guest memory. Attestation evidence originates in the module, which produces a signed report that a quoting enclave converts into a quote verifiable by a remote party. Because the TDX Module is itself a substantial piece of privileged software, Intel has published the source and commissioned external security reviews of it.
Arm Confidential Compute Architecture
The Arm Confidential Compute Architecture (CCA) extends the TrustZone security model rather than replacing it. Its principal hardware component is the Realm Management Extension (RME), an Armv9-A feature that adds two security states to the existing pair: a Realm world that hosts confidential guests, and a Root world that holds the most privileged monitor firmware. The result is four mutually isolated states, so a realm is protected not only from the normal world hypervisor but also from the TrustZone secure world and from other realms.
A realm is created dynamically at the request of an untrusted normal world host, which retains responsibility for scheduling and resource allocation but never gains access to realm memory. Policy is enforced by the Realm Management Monitor, a small firmware component running in the realm world, with the Granule Protection Table tracking which physical memory granule belongs to which world. CCA includes an attestation mechanism that reports both the platform state and the initial measurement of the realm, allowing a relying party to verify the environment before releasing data to it. Open-source enablement spans Trusted Firmware-A, the Linux kernel, and KVM.
RISC-V Security Approaches
The RISC-V architecture, as an open standard, supports TEE functionality through a combination of standard isolation primitives and vendor or open-source frameworks built on top of them:
Physical Memory Protection (PMP): RISC-V includes PMP as a standard feature, allowing more-privileged software to restrict memory access for less-privileged modes. While PMP alone is not a full TEE, it provides the building blocks for isolation between security domains and is the foundation on which most RISC-V TEE frameworks are constructed.
WorldGuard: Originally developed by SiFive and contributed to RISC-V International in 2023, WorldGuard provides system-level, TrustZone-like isolation for RISC-V platforms. It tags transactions with a "world" identifier and enforces access to memory and peripherals across the whole system-on-chip, including transactions issued by bus initiators such as DMA engines, enabling multiple isolated execution domains without adding new ISA instructions.
Supervisor Domains and CoVE: RISC-V International is developing standards-track equivalents of the proprietary architectures described above. The Supervisor Domains extension (Smmtt) defines a memory tracking table that partitions physical memory among isolated supervisor domains, and the Confidential VM Extension (CoVE) defines the threat model, reference architecture, and interfaces for confidential virtual machines built on that isolation. Both remain works in progress rather than ratified specifications, so RISC-V TEE products shipping today generally rely on PMP together with a vendor or open-source framework.
Keystone: Keystone is an open-source TEE framework for RISC-V that uses PMP to create isolated enclaves under the control of a small security monitor running in machine mode. Its open-source nature allows security researchers to audit the implementation and customize it for specific requirements.
MultiZone: Hex Five's MultiZone provides hardware-enforced separation using RISC-V privilege modes and PMP. It enables multiple isolated security zones with controlled communication channels on standard RISC-V cores, supporting multi-domain security architectures without custom hardware.
Dedicated Security Processors
Beyond processor extensions, many systems employ dedicated security co-processors that provide physically separate execution environments:
Apple Secure Enclave: Apple devices include a dedicated Secure Enclave Processor (SEP) that handles biometric data, encryption keys, and secure boot verification. The SEP has its own protected memory, boots independently using its own secure boot process, and communicates with the main processor only through a hardware mailbox interface.
Google Titan: Google's Titan chips provide a hardware root of trust for cloud servers and consumer devices. These dedicated security processors verify firmware integrity, protect encryption keys, and provide attestation services. Their physical separation from main processors limits attack surfaces.
Microsoft Pluton: Microsoft's Pluton security processor integrates directly into CPU dies from multiple vendors. It protects credentials, encryption keys, and personal data while providing firmware protection and attestation capabilities. Integration into the CPU die reduces physical attack opportunities compared with external security chips.
Trusted Platform Module (TPM): TPMs are standardized security components defined by the Trusted Computing Group. They provide secure key storage, platform configuration registers (PCRs) for measured boot, and cryptographic operations. While distinct from TEEs, TPMs complement TEE functionality by providing persistent secure storage and platform attestation, and they may be implemented as discrete chips, integrated controllers, or firmware running inside a TEE.
Applications
Trusted execution environments enable security capabilities across diverse application domains:
Digital rights management: TEEs protect content decryption keys and playback operations for premium video and audio content. Content providers can verify that playback occurs within approved TEE environments before delivering high-value content.
Mobile payments: Payment credentials, transaction processing, and biometric verification execute within TEEs, protecting sensitive financial data from malware that might compromise the mobile operating system.
Biometric authentication: Fingerprint matching, facial recognition, and other biometric operations occur within TEEs to protect biometric templates from extraction. The TEE verifies identity without exposing raw biometric data to the normal world.
Secure key storage: Cryptographic keys for device encryption, VPN connections, and code signing reside within TEEs where they cannot be extracted even by privileged software. Operations using these keys execute entirely within the protected environment.
Confidential computing: Cloud providers offer TEE-based services that allow customers to process sensitive data without trusting the cloud infrastructure. Attestation verifies that data remains encrypted except within verified enclaves.
Automotive security: Vehicles use TEEs to protect software update verification, secure communication with backend services, digital key management, and other security-critical functions from compromised infotainment systems or other attack vectors.
Industrial control: TEEs protect control system integrity, secure firmware updates, and safeguard communication credentials in industrial environments where systems may be exposed to physical access or network attacks.
Security Considerations and Limitations
While TEEs provide strong security guarantees, understanding their limitations is essential for proper implementation:
Side-channel attacks: TEEs protect memory contents and execution from software access, but physical and microarchitectural side channels may leak information. Cache timing attacks, power analysis, and electromagnetic emanation analysis can potentially extract secrets from TEE operations. Implementations must employ countermeasures such as constant-time algorithms, cache partitioning, and power noise injection.
Microarchitectural vulnerabilities: Speculative and transient execution vulnerabilities (such as Spectre, Meltdown, Foreshadow, and Downfall) have affected TEE implementations, in some cases allowing data to be read across the enclave boundary. While mitigations and microcode updates exist, new variants continue to be discovered, so TEE deployments must apply firmware updates as vulnerabilities are identified.
Rollback attacks: Attackers may attempt to restore older, vulnerable versions of TEE software or sealed data. TEE implementations require anti-rollback mechanisms such as monotonic counters stored in secure hardware to prevent these attacks.
Interface vulnerabilities: The boundary between secure and normal worlds represents an attack surface. Input validation bugs, confused-deputy attacks, and other interface vulnerabilities can compromise TEE security. Careful API design and thorough testing of world-crossing interfaces are essential.
Implementation complexity: TEE software development requires specialized expertise. Bugs in trusted applications can have severe consequences because they execute in the protected environment. Formal verification techniques and rigorous testing practices help reduce implementation vulnerabilities.
Supply chain trust: TEE security ultimately depends on trusting the hardware manufacturer. Backdoors or vulnerabilities introduced during manufacturing could undermine TEE guarantees. Open-source TEE implementations on open hardware provide transparency, but most commercial deployments rely on proprietary implementations.
Development and Integration
Implementing TEE-based security requires understanding development tools, APIs, and integration patterns:
SDKs and toolchains: Each TEE platform provides software development kits with compilers, libraries, and debugging tools. Arm provides TrustZone development tools, Intel offers an SGX SDK for multiple platforms, and open-source options such as OP-TEE include comprehensive development environments.
Trusted application development: Trusted applications typically use restricted APIs to minimize attack surface and complexity. Developers must understand the limitations of TEE environments, including restricted system calls, limited memory, and the absence of standard library functions in some implementations.
Secure communication: Establishing secure channels between normal world applications and TEEs requires careful protocol design. Session establishment, authentication, and encrypted communication protect against man-in-the-middle attacks and ensure message integrity.
Key management: TEEs often serve as key management systems, but provisioning initial keys (key injection) requires secure manufacturing processes. Development and production key hierarchies must be carefully managed to prevent key compromise.
Performance budgeting: Protection is not free, and the cost depends on the design model. Process enclaves charge for every boundary crossing, so designs that call into an enclave in a tight loop perform far worse than designs that batch work and cross the boundary rarely; paging beyond the protected memory pool is more expensive still. Confidential virtual machines avoid frequent transitions but add memory encryption overhead and more expensive guest exits. Measuring the workload's actual transition rate early is more informative than any general benchmark.
Testing and validation: TEE security testing requires specialized approaches, including fuzzing of TEE interfaces, side-channel analysis, and formal verification of critical code paths. Certification programs such as the GlobalPlatform TEE Protection Profile define security evaluation criteria.
Future Directions
TEE technology continues to evolve in response to new requirements and threats:
Confidential computing standardization: Industry consortiums such as the Confidential Computing Consortium work to standardize attestation formats, portability APIs, and security guarantees across TEE implementations. This standardization will simplify development of applications that can run on multiple TEE platforms.
Confidential accelerators: Having established confidential virtual machines on the CPU, the industry is extending the same protections to GPUs and other accelerators so that a workload's data stays encrypted across the interconnect and inside accelerator memory. This capability is central to confidential machine learning, where the model weights, the input data, and the operator's infrastructure often belong to three different parties.
Hardware and software co-design: Tighter integration between TEE hardware and software enables new capabilities such as dynamic enclave creation, heterogeneous TEE configurations, and improved performance. Custom hardware designs for specific security applications are becoming more feasible.
Post-quantum cryptography: As quantum computing advances, TEEs must transition to quantum-resistant cryptographic algorithms. This transition affects attestation, sealing, and all cryptographic operations within TEEs.
IoT scalability: Extending TEE capabilities to resource-constrained IoT devices requires approaches that provide meaningful security guarantees within tight power and area budgets. Lightweight TEE implementations and remote attestation at scale are active areas of development.
Conclusion
Trusted execution environments provide hardware-enforced security that protects sensitive operations from software attacks, including compromised operating systems and hypervisors. The field has settled into three design models: system partitioning as in Arm TrustZone, process enclaves as in Intel SGX, and confidential virtual machines as in AMD SEV-SNP, Intel TDX, and Arm CCA. Embedded and mobile devices still favor the partitioned model for its small footprint and always-available secure services, while server platforms have converged on confidential virtual machines because unmodified workloads can adopt them.
Understanding TEE capabilities and limitations enables engineers to design systems that leverage hardware security effectively. A TEE narrows the trusted computing base; it does not eliminate trust. Deployments must still account for side-channel and transient-execution leakage, the security of the world-crossing interface, anti-rollback protection, and the integrity of the key provisioning process. Treated as one layer within a defense-in-depth architecture rather than as a guarantee in itself, the TEE has become an essential component of embedded systems that handle sensitive data or connect to hostile networks.