Key takeaways
- A device cannot verify its own first instruction with software, because any software-based check can itself be replaced by an attacker who controls where that software lives.
- These are not mutually exclusive.
- The Trusted Computing Group released the Device Identifier Composition Engine (DICE) Architecture in 2017 specifically because a full TPM is often impractical on low-cost IoT and embedded silicon.
- Identify your actual hardware anchor before trusting a vendor's "secure boot enabled" claim.
A hardware root of trust is a piece of silicon, fuse-protected key material, or immutable ROM code on a device that cannot be modified after manufacture and that anchors every later trust decision; secure boot is the sequence of signature checks, each stage verifying the next before it is allowed to run, that extends trust outward from that anchor through the bootloader to the OS or application firmware. Together they are the mechanism that answers a single practical question at every power-on: is the code about to run actually the code the manufacturer signed, or has it been tampered with since?
A sourcing note: NIST's and Arm's primary PDFs for SP 800-193 and the PSA Trusted Boot and Firmware Update specification are large, compressed documents that this guide's fetch tooling could not fully render as clean extractable text. Facts and figures attributed to them below are cross-checked against TCG's and Arm's own HTML documentation pages (fetched directly) and independent secondary technical write-ups. Confirm exact clause wording against the primary PDFs linked in sources before citing this guide as authoritative on any single requirement.
Why a chain, not a single check
A device cannot verify its own first instruction with software, because any software-based check can itself be replaced by an attacker who controls where that software lives. The only way out of this bootstrapping problem is to put the first check somewhere software cannot reach: burned into mask ROM, locked by a one-time fuse, or isolated in a separate secure co-processor. From that one immutable starting point, each stage of boot verifies a cryptographic signature on the next stage before handing over execution — Arm's Trusted Boot and Firmware Update specification describes the pattern as an immutable bootloader acting as the hardware root of trust that executes from reset and manages the public key used to verify every subsequent firmware stage. On a typical UEFI PC, this plays out as firmware verifying the bootloader against a trusted-key database before execution, the bootloader then verifying the OS loader, and the OS loader verifying the kernel — a widely cited description of the pattern frames it simply as a chain running "from firmware to boot manager to OS loader to kernel," where a failure anywhere in that chain halts the boot rather than letting an unverified stage run.
Where the anchor actually lives: four common approaches
| Approach | What it is | Where it fits |
|---|---|---|
| Discrete TPM | A separate, standardized chip (Trusted Computing Group's TPM 2.0 line) for measured boot, sealed storage and remote attestation | Higher-end platforms (servers, laptops, some industrial PCs) that can afford a second component and its provisioning overhead |
| Secure element | Its own small, tamper-resistant chip, often used for payment credentials and SIMs | Devices needing strong physical tamper resistance for a narrow set of secrets, less often the primary boot anchor |
| Arm TrustZone | A CPU feature, not a separate chip, splitting one processor into a secure world and a non-secure world | Arm-based SoCs where the processor itself, per Arm, provides "the perfect starting point for establishing a device root of trust based on PSA guidelines" without added bill-of-materials cost |
| TCG DICE | A minimal hardware secret plus a measurement of the first mutable code, combined into a Compound Device Identifier | The most resource-constrained microcontrollers and components, where neither a TPM nor TrustZone is practical |
These are not mutually exclusive. TCG's own description of DICE notes it can work "standalone on constrained devices, or as complement to TPM in more complex security architectures," and a design can legitimately use TrustZone to isolate secure-world code on the main application processor while a smaller sensor or power-management IC on the same board uses DICE for its own identity.
TCG DICE: a root of trust for devices too small for a TPM
The Trusted Computing Group released the Device Identifier Composition Engine (DICE) Architecture in 2017 specifically because a full TPM is often impractical on low-cost IoT and embedded silicon. DICE needs only a protected hardware secret — the Unique Device Secret, accessible solely to the earliest, most trusted layer of code — and a measurement of the first mutable code that runs. Those two inputs feed a one-way function to produce a Compound Device Identifier that is unique to that exact combination of hardware and firmware; change the firmware, and the identifier changes with it, which is what makes tampering detectable without needing a certified security chip at all. TCG frames the result as giving IoT and embedded systems "critical security and privacy benefits... where traditional Trusted Platform Modules (TPM) may be impractical."
What secure boot does not do by itself
Secure boot answers "is this code signed by someone I trust," not "is this code free of vulnerabilities" or "will this device recover if the signed firmware is still compromised." A properly verified chain of trust can still boot firmware with an exploitable bug in it, because the signature only proves provenance, not correctness. This is exactly the gap NIST SP 800-193's roots of trust for detection and recovery are built to cover once verification itself is working, and it is why NSA's December 2025 guidance on managing UEFI Secure Boot, coordinated with CISA, exists at all: the guidance catalogs real incidents — including PKFail, where devices shipped with untrusted test certificates still accepted as trusted roots, and BlackLotus, a bootkit that bypassed Secure Boot enforcement — as evidence that a correctly designed chain of trust can still fail in practice if keys, certificate databases, or revocation lists are misconfigured or left at insecure defaults.
A workable starting point
Identify your actual hardware anchor before trusting a vendor's "secure boot enabled" claimConfirm whether the first verification step runs from immutable ROM, a fused key, or a general-purpose flash region that could itself be rewritten. Map every stage in your boot chain and confirm each one verifies the next, rather than assuming a single signature check at the start covers everything that runs afterward. Treat key management as the hard part, not the cryptographyMost real-world secure boot failures — PKFail among them — trace back to test keys, shared keys across product lines, or missing revocation paths, not broken algorithms. Match the root-of-trust approach to the constraint, not the trendA $2 sensor SoC does not need a discrete TPM; TCG DICE or a TrustZone-based design is often the realistic option, and forcing a heavier approach can delay a product without adding real security. Pair verification with recoveryA chain of trust that only refuses to boot on failure, with no signed recovery path, turns a detected attack into a bricked fleet — the problem NIST SP 800-193's recovery root of trust is designed to solve.
For the resilience model that governs what happens after a verification failure, see NIST SP 800-193: Platform Firmware Resiliency; for the PC/server-specific BIOS update rules that predate and narrow that broader model, see NIST SP 800-147: BIOS Protection Guidelines. Threat models for where a weak or missing root of trust shows up in practice are catalogued in MITRE EMB3D, testing approaches for verifying boot-chain claims independently are covered in OWASP's firmware security testing methodology, and the regulatory expectation that a product protect code and data integrity is explained in CRA Annex I.
SoftWSP's Device & Firmware Security service reviews boot chains, key handling and root-of-trust implementation choices against the device's actual constraints rather than a generic checklist: see Device & Firmware Security.
This guide draws on NIST's, the Trusted Computing Group's, Arm's and NSA's published technical materials, cross-checked against independent secondary write-ups where a primary PDF could not be rendered as extractable text. This guide is not a substitute for those organizations' own specifications, or for an engineer's assessment of a specific device's boot architecture.
Sources
- NIST Special Publication 800-193, Platform Firmware Resiliency Guidelines (May 2018)
- Trusted Computing Group: Device Identifier Composition Engine (DICE) Architecture announcement and overview
- Arm: Trusted Boot and Firmware Update, PSA Certified specification (DEN0072)
- Arm: TrustZone for Cortex-M (device root of trust based on PSA guidelines)
- NSA Cybersecurity Information Sheet: Guidance for Managing UEFI Secure Boot (11 December 2025, coordinated with CISA)
- NIST Special Publication 800-147, BIOS Protection Guidelines (April 2011)
Frequently asked questions
What is the difference between secure boot and a hardware root of trust?
Secure boot is the process — a sequence of signature checks that run every time a device powers on, each stage verifying the next before handing over execution. A hardware root of trust is the anchor that process depends on: a piece of silicon, fuse-protected key, or immutable ROM code that cannot itself be updated or spoofed, and that performs or protects the very first verification step. Arm's Platform Security Architecture materials describe this as an immutable boot ROM forming the trust anchor from which the rest of the chain of trust is built. Without a hardware root of trust, secure boot is only as strong as whatever software performed the first check — and software-only checks can usually be bypassed by an attacker who controls the storage the bootloader lives on.
How does the secure boot chain of trust actually work, step by step?
Each stage verifies a cryptographic signature on the next stage before running it, starting from a stage that nothing software-based can tamper with. On a typical UEFI PC, a hardware vendor embeds a Platform Key representing the root of trust, and the firmware checks the bootloader's signature against a database of trusted keys (the db) and a revocation list (the dbx) before executing it; a widely used secondary description summarizes the resulting flow as "firmware to boot manager to OS loader to kernel," where a failure at any link halts the boot. The well-known Linux shim/GRUB pattern illustrates this concretely: UEFI verifies the signed shim binary using a Microsoft-issued certificate, shim then verifies and launches GRUB using distro-specific keys, and GRUB verifies and starts the kernel — three separate signature checks, each one gating the next stage's execution rather than trusting it by default.
Do I need a TPM, a secure element, or is Arm TrustZone enough?
They solve overlapping but distinct problems, and many designs use more than one together. A discrete TPM (per the Trusted Computing Group's TPM 2.0 work) is a separate, certified chip good for measured boot, sealed storage and remote attestation, but it adds bill-of-materials cost and a second component to provision. Arm TrustZone is not a separate chip — it is a CPU feature that partitions a single processor into a secure world and a non-secure world, and Arm positions it as "the perfect starting point for establishing a device root of trust based on PSA guidelines," useful when the device already has an Arm core and cost or board space rules out a discrete TPM. A secure element (its own small, tamper-resistant chip, common in payment and SIM applications) trades flexibility for strong physical tamper resistance. For the lowest-cost, most resource-constrained devices that cannot justify any of the above, TCG's DICE architecture derives a strong device identity from a hardware secret and firmware measurements using only a small immutable code region — no dedicated security chip required.
How does secure boot relate to NIST SP 800-193, SP 800-147 and the EU Cyber Resilience Act?
They describe adjacent but different layers of the same problem, and this guide deliberately does not re-cover their detail — see the linked guides for that. NIST SP 800-193's roots of trust for update, detection and recovery (RTU, RTD, RTRec) describe what a platform must be able to do if firmware integrity fails, which assumes a working verification chain (secure boot) is already in place to detect the failure; see [NIST SP 800-193: Platform Firmware Resiliency](/guides/nist-sp-800-193-platform-firmware-resiliency/) for that resilience model in depth. NIST SP 800-147 is narrower still, defining an authenticated update mechanism and root of trust for update specifically for PC/server BIOS; see [NIST SP 800-147: BIOS Protection Guidelines](/guides/nist-sp-800-147-bios-protection-guidelines/). The EU Cyber Resilience Act does not mandate a specific boot architecture, but its essential requirements expect products to protect against unauthorized access and ensure data/code integrity, which secure boot and a hardware root of trust are a direct technical answer to; see [CRA Annex I, explained](/guides/cra-annex-i-explained/) for the regulatory text itself.
In this cluster
