Security Architecture for Embedded Products: When TrustZone Is Enough and When It Is Not

The question of where to implement cryptography in an embedded product — in software on the application processor, in an isolated world via TrustZone, or in a physically separate security co-processor — is decided by threat model, not by which option is easiest to implement. Most product teams anchor their security architecture on TrustZone because it comes for free on ARM Cortex-M33 and Cortex-A processors: no additional BOM component, no I2C bus to manage, no external chip to integrate. The assumption that comes with this choice is often implicit: TrustZone is hardware-enforced isolation, and hardware-enforced isolation is adequate for the product's use case.

The assumption is frequently wrong in specific ways that the product team discovers only after deployment, during a security audit, or following a published attack. TrustZone is a hardware-enforced isolation mechanism between two software worlds on the same processor die. It is explicitly not designed to protect against side-channel attacks — ARM says so in its own security documentation. It runs on the same silicon substrate as the normal world, shares the same power supply rails, and produces power and electromagnetic emanations that are correlated with the cryptographic operations it performs. A determined attacker with physical access and measurement equipment can extract keys from a TrustZone secure world through differential power analysis without ever defeating the logical isolation that TrustZone provides. A dedicated security co-processor — a secure element, a TPM, an HSM — runs on separate silicon designed from the ground up with physical attack resistance as a first-class design objective.

Understanding exactly when this distinction matters, and when TrustZone is adequate, requires clarity about what each approach provides and does not provide.

What TrustZone Actually Is — and What It Is Not

ARM TrustZone is a processor architecture extension that partitions execution, memory, and bus transactions between a secure world and a normal world. On Cortex-A processors, this partition enables a Trusted Execution Environment (TEE) running a secure OS alongside a rich OS. On Cortex-M23 and M33, TrustZone-M provides a lighter-weight partition with faster context switching appropriate for microcontrollers.

What TrustZone provides:

• Hardware-enforced logical isolation: normal-world software cannot read secure-world memory or execute secure-world code without going through secure-callable entry points
• Secure peripheral access: peripherals can be assigned to the secure world so that normal-world software cannot access their registers
• Secure boot infrastructure: the secure world can run before the normal world boots, establishing a trusted chain from ROM code
• Key storage isolation: cryptographic keys held in secure-world memory cannot be read by normal-world software, even if the normal-world OS is compromised

What TrustZone does not provide:

• Physical isolation from the normal world: both worlds run on the same processor core, sharing the same silicon die, power rail, clock, and physical package
• Side-channel resistance: TrustZone's secure world produces power consumption and electromagnetic emanations that reflect its operations, extractable by physical measurement
• Tamper detection: there is no physical mechanism to detect or respond to attempts to probe the processor's signals, modify supply voltage, or inject faults
• Independent certifiability: the security guarantee is as strong as the implementation of the secure world software, which runs on the same programmable processor as potentially vulnerable code

ARM explicitly acknowledges this limitation: "The Security Extensions for the Armv8-M architecture do not claim to protect against side channel attacks due to control flow or memory access patterns." This is not a flaw in TrustZone's design — it is an accurate characterization of what logical isolation hardware achieves. Side-channel resistance requires dedicated physical countermeasures in the silicon: noise injection, power supply filtering, randomized execution, and metal shielding — design choices that add cost and area that a general-purpose application processor cannot justify for all use cases.

The Secure Element — What Dedicated Silicon Provides

A secure element is a physically separate, tamper-resistant semiconductor device whose primary design objective is protecting cryptographic keys and executing cryptographic operations in a physically hostile environment. The distinction from TrustZone is foundational: a secure element is not an isolation layer on top of a general-purpose processor — it is a separate processor with a separate threat model.

The physical security measures in a dedicated secure element go substantially beyond what an application processor provides:

• Active shielding: metal mesh layers over the die that detect attempts to probe or remove them
• Power supply filtering and noise injection: preventing power consumption from being correlated with cryptographic operations
• Temperature, voltage, and clock frequency monitoring: detecting and responding to fault injection attempts that try to skip security checks or force invalid states
• Randomized instruction execution: inserting dummy operations to mask timing side channels
• Memory scrambling: encrypting and integrity-protecting internal SRAM contents even against an attacker who has penetrated the package

These are not optional features — they are the certification requirements that determine whether a secure element achieves PSA Level 2 or Level 3 certification, Common Criteria EAL 5+ or EAL 6+, or FIPS 140-3 Level 3 validation. The PSA Certified framework, designed by ARM for IoT device security, defines levels based on threat protection: PSA Level 1 is software security, Level 2 adds basic hardware Root of Trust, and Level 3 explicitly requires protection against hardware attacks including side-channel and fault injection. By 2023, the first PSA Level 3 certified Root of Trust IP appeared — Intrinsic ID's QuiddiKey 300, a PUF-based key storage component.

The critical property that dedicated secure elements provide and TrustZone cannot is this: a private key generated inside a secure element never leaves the secure element in plaintext form. All cryptographic operations that require the private key — signing, decryption, key agreement — execute inside the secure element, and only the result is returned to the application processor. Even if the application processor running TrustZone is fully compromised — an attacker with full control of both secure and normal worlds — the private key in the secure element remains inaccessible. The attacker can command the secure element to perform operations using the key, but cannot extract the key itself.

The commonly used secure elements for embedded IoT and industrial products include:

• Microchip ATECC608B: a compact I2C/SPI device providing elliptic curve cryptography (ECDH, ECDSA), AES-128, SHA-256, and 10 KB of secure key storage in a 3mm × 2mm package at roughly $0.50–$1.50 at volume
• NXP SE050: a JavaCard-based secure element supporting a broader algorithm suite including RSA, AES, 3DES, ECC up to P-521, and post-quantum algorithm readiness; Common Criteria EAL 6+ certified
• STMicroelectronics STSAFE-A110: compact secure element with I2C interface, ECDSA/ECDH with P-256 and P-384, pre-provisioned device certificate; used in industrial IoT and automotive applications
• Infineon OPTIGA Trust M: Common Criteria EAL6+ certified secure element with comprehensive PKI support, used in industrial platforms and IIoT gateways

The Threat Model Decision Tree

The choice between TrustZone, dedicated secure element, TPM, or a combination depends entirely on the threat model the product must address. Most products do not require defense against physical side-channel attacks; some do. The engineering decision must be driven by an honest assessment of the threats, not by which option is cheapest or most familiar.

The decision framework follows the attack surface:

If the product operates in a physically controlled environment — deployed in a secure data center, behind a locked enclosure, in a setting where physical access by adversaries is not assumed — then TrustZone or software crypto in a TrustZone TEE is typically adequate. The threat model is remote software attacks, for which TrustZone's logical isolation provides meaningful protection. The normal-world OS can be compromised without exposing secure-world keys.

If the product is deployed in a physically accessible location — an IoT device in a building, a meter at a customer premises, an EV charger in a parking lot, a payment terminal in a retail environment — the threat model must include physical access by adversaries of varying sophistication. For these cases, the question is what the adversary gains by extracting a key from the device. If the key is a device-specific identity key, extraction enables cloning the device's identity. If the key is a firmware signing key or a class secret shared across all devices, extraction enables a fleet-wide attack. The higher the value of what the key protects and the broader the blast radius of its compromise, the stronger the argument for dedicated secure element rather than TrustZone-only.

If the product handles payment credentials, high-value authentication tokens, or keys whose extraction would compromise critical infrastructure, regulatory requirements may mandate hardware security evaluation: PCI DSS requires tamper-resistant hardware for cardholder data environments, and many national critical infrastructure regulations specify equivalent requirements. In these cases, the question is not whether to use dedicated secure silicon but which certification level is required.

The following table maps threat scenarios to recommended security architecture:

TrustZone Attacks in Practice — Understanding the Real Exposure

TrustZone has been subject to a substantial body of published attack research. Quarkslab and others have documented successful attacks against TrustZone implementations, and understanding the categories of attack clarifies which threat model elements TrustZone handles poorly.

Software attacks on TrustZone target the secure world software directly: vulnerabilities in the TEE OS, in trusted applications (TAs) running in the secure world, or in the secure-to-non-secure interface create paths for normal-world attackers to escalate into the secure world. These are the attacks that TrustZone was designed to prevent but that its design does not guarantee — it prevents unauthorized direct memory access by normal-world software, but a vulnerable TA that processes attacker-controlled input can still be exploited by a normal-world attacker who sends malformed messages through the TEE API. The secure world software must itself be correct, and TrustZone does not verify its correctness.

Physical attacks exploit the shared silicon substrate. Differential power analysis (DPA) measures the power consumed by the processor during cryptographic operations and correlates it with key-dependent intermediate values to reconstruct private keys. Simple power analysis (SPA) identifies operations visually from power traces. Electromagnetic analysis (EMA) performs the same correlation using electromagnetic field measurements rather than power supply measurements. Fault injection through voltage glitching or clock glitching causes the processor to execute instructions incorrectly, potentially skipping security checks or generating predictable output from operations that should be random. None of these attacks require defeating TrustZone's logical isolation — they operate at the physical layer below the logical security boundary.

A 2026 systematic review of embedded hardware security published in MDPI Electronics confirms that side-channel mitigation for cryptographic operations on general-purpose MCUs carries significant overhead: masked implementations of post-quantum cryptographic algorithms (lattice-based schemes from FIPS 203/204/205, finalized by NIST in August 2024) require additional power, area, and performance overhead that is difficult to justify in cost-sensitive IoT deployments without the dedicated silicon designed for this purpose. This further reinforces that the appropriate solution for environments requiring physical attack resistance is dedicated secure silicon, not software countermeasures on top of a general-purpose processor.

Post-Quantum Implications for Embedded Security Architecture

The NIST post-quantum cryptography standards finalized in August 2024 — FIPS 203 (ML-KEM, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA) — have direct implications for the embedded security co-processor choice. Post-quantum algorithms are computationally more expensive than the ECC algorithms they replace, which affects both the case for dedicated acceleration and the security properties of the solutions.

For software implementations of PQC algorithms on constrained Cortex-M targets, the performance cost is significant: ML-KEM key generation and encapsulation require substantially more cycles than ECDH equivalents, and ML-DSA signature operations are heavier than ECDSA. These performance costs make the case for dedicated hardware acceleration stronger than it was for ECC. Secure elements and embedded HSMs that include hardware acceleration for PQC algorithm primitives — particularly the polynomial multiplication at the core of lattice-based algorithms — provide the performance needed for PQC in real-time embedded applications without the CPU overhead that software PQC imposes.

The side-channel security of PQC implementations adds further pressure toward dedicated silicon. Research has demonstrated that lattice-based polynomial multiplication operations have different power leakage patterns than AES or ECC, creating new side-channel attack surfaces that require new countermeasures. Masked hardware implementations of lattice operations have been demonstrated by research groups, but deploying these in production requires either custom silicon design or secure elements from vendors that have already developed and certified masked PQC implementations. The NXP SE050 and its successors in the SE05x family have roadmap support for post-quantum algorithms; Microchip's ECC608 successor families are similarly positioning for PQC support. For products with 10+ year lifetimes that need to be PQC-capable, selecting a secure element with a credible PQC migration roadmap today is preferable to retrofitting PQC support into a TrustZone software implementation later.

Hybrid Architecture — When to Combine Both

Most production embedded security architectures for non-trivial products use both TrustZone and a dedicated secure element, assigning different responsibilities to each based on their respective strengths. This is not redundancy — it is defense in depth where each element is providing protection against a different attack category.

TrustZone handles software isolation: protecting secure boot logic, key wrapping operations, and trusted application isolation from a potentially compromised normal-world OS. The secure world can orchestrate operations against the external secure element without exposing the element's response data to normal-world software.

The secure element handles physical key protection: storing the device's identity private key, performing signing and key agreement operations that require that key, providing tamper-evident storage for critical credentials, and providing a hardware root of trust that is independent of the application processor's correctness.

This division of responsibility maps cleanly to the threats each component addresses:

• Remote software attacker who compromises the normal-world OS → TrustZone prevents them from accessing secure-world data
• Remote software attacker who compromises the TrustZone secure world → secure element prevents them from extracting the device identity key
• Physical attacker with side-channel equipment → secure element's physical countermeasures prevent key extraction from its silicon
• Physical attacker attempting fault injection on the application processor → secure element is unaffected by faults on the application processor's supply or clock

Silicon Labs Series 2 devices illustrate this hybrid architecture in a commercial product: devices with a dedicated Hardware Security Module (HSM Vault, labeled SVH) provide physically protected key storage and cryptographic acceleration via a separate secure core; devices without the dedicated HSM (SVM) implement secure key storage through TrustZone, providing software isolation at lower cost but without hardware attack resistance.

Quick Overview

TrustZone provides hardware-enforced logical isolation between secure and normal worlds on the same processor die — protecting against software attacks but explicitly not against physical side-channel attacks like differential power analysis or fault injection. Dedicated security co-processors (secure elements, TPMs, embedded HSMs) provide physical tamper resistance through active shielding, power supply filtering, and execution randomization, ensuring that private keys never leave the secure element in plaintext even under physical attack. The architectural decision between TrustZone, dedicated secure silicon, or a hybrid of both is determined by the threat model: physical accessibility of the device, the value and blast radius of protected keys, and applicable regulatory requirements. NIST PQC standards finalized in 2024 add new considerations around algorithm performance and side-channel resistance that further favor hardware acceleration in constrained embedded deployments.

Key Applications

IoT devices deployed at customer premises or in publicly accessible locations where physical access enables side-channel attacks on device identity keys, payment terminals and financial devices requiring PCI DSS tamper-resistant hardware certification, automotive ECUs where the embedded HSM (EVITA, SHE) standard separates security-critical key operations from the application processor, industrial IIoT gateways requiring device authentication for IEC 62443 compliance with hardware-backed attestation, and any product family where a single device's key compromise would enable a class-break attack against all devices with the same secret.

Benefits

Secure elements ensure private keys never leave the secure element — even a fully compromised application processor cannot extract them, only command operations with them. PSA Level 3 and Common Criteria EAL 6+ certifications provide independently verified evidence that physical attack countermeasures are adequate, reducing security audit burden. The BOM cost of a secure element like the ATECC608B at $0.50–$1.50 is low relative to the value of the identity credentials it protects across a device's 10+ year operational lifetime. Hybrid TrustZone + secure element architectures provide defense in depth covering both remote software attacks (TrustZone) and physical attacks (secure element).

Challenges

Secure elements add BOM cost, a physical component, I2C or SPI bus integration, a driver layer, and vendor-specific API dependencies to a product that TrustZone-only avoids. The secure element's private key being non-extractable is also a limitation: if the device is decommissioned and the key must be transferred to a replacement device, the architecture must provision a new key in the new device's secure element rather than migrating the old key. PQC-capable secure elements from mainstream vendors are in development but not universally available at the algorithm coverage and performance levels that PQC-only deployments require, creating transition planning uncertainty.

Outlook

PSA Certified adoption as a procurement requirement in IoT device security — already referenced in EU Cyber Resilience Act guidance and national cybersecurity frameworks — is creating market pressure for embedded products to achieve at minimum PSA Level 2 certification, which requires a hardware Root of Trust. This is accelerating adoption of dedicated secure elements and embedded HSM IP in products that previously relied on TrustZone alone. The PQC transition adds further urgency: devices shipping today with 10+ year lifetimes need PQC-capable cryptographic infrastructure, which the current generation of secure elements from NXP, Microchip, and STMicroelectronics is positioning to provide through algorithm update roadmaps.

Related Terms

TrustZone, TEE, trusted execution environment, secure element, SE, TPM, trusted platform module, HSM, hardware security module, secure world, normal world, Cortex-M33, TrustZone-M, ARMv8-M, side-channel attack, differential power analysis, DPA, simple power analysis, SPA, electromagnetic analysis, fault injection, voltage glitching, clock glitching, root of trust, hardware root of trust, PSA Certified, PSA Level 3, Common Criteria, EAL 6, ATECC608B, SE050, STSAFE, OPTIGA Trust, PUF, physically unclonable function, QuiddiKey, FIPS 203, FIPS 204, FIPS 205, ML-KEM, ML-DSA, post-quantum cryptography, crypto agility, EVITA, SHE, IEC 62443, PCI DSS, secure boot, OTP fuse, key wrapping, device identity, class-break attack, physical attack resistance, masked implementation