Secure Boot and Hardware Root of Trust: Architecture Choices for Product Teams

What is a hardware root of trust? NIST defines a root of trust as an element that provides security functions such as verification, measurement, storage, update or recovery, and that must always behave as expected, because its misbehavior can’t be detected ^[1]. In an embedded product, it’s usually immutable code and keys in hardware that every later boot stage depends on.

This guide is for firmware leads choosing a root of trust and an embedded secure boot design for connected products. It’s part of our embedded and firmware security hub. It covers the options, the chain of trust, key provisioning in manufacturing, rollback protection, and what to do about products already in the field.

Why it matters now

The root of trust is what lets a device refuse code you didn’t sign. Without it, signed updates and integrity checks can be bypassed by replacing the code that does the checking.

For products sold in the EU, the Cyber Resilience Act's essential requirements (Annex I, Part I) include protecting the integrity of stored data, commands, programs and configuration against unauthorized modification, protection from unauthorized access, and limiting attack surfaces ^[2]. They apply from 11 December 2027 ^[2][3]. The CRA doesn’t name a technology. How you meet those requirements is a design decision, documented in your risk assessment.

Industrial machinery has a parallel requirement. The Machinery Regulation (EU) 2023/1230, which applies from 20 January 2027, requires safety-critical software and data to be protected against accidental or intentional corruption, and the machine to identify its safety-relevant software ^[4][5].

Chain of trust: how secure boot works on embedded devices

A chain of trust starts at the root of trust and extends it one stage at a time. Each stage verifies the next before handing over control. Once control passes to code that isn’t verified, the chain has ended ^[1].

A typical embedded chain:

1. Boot ROM (immutable, in the SoC) verifies the first-stage bootloader against a key hash held in one-time-programmable fuses.
2. First-stage bootloader sets up memory and verifies the next stage.
3. Second-stage bootloader (on embedded Linux, often U-Boot) verifies the kernel, device tree and initramfs. U-Boot’s verified boot, for example, can check signed images and then hand off to the kernel’s dm-verity to mount a signed root filesystem ^[6][7].
4. Operating system or RTOS image verifies applications or root filesystem integrity.

On microcontrollers, the chain is usually shorter: ROM or an immutable bootloader verifies one or two application images. MCUboot, for example, verifies signed images and supports swapping between slots ^[8].

Secure boot and measured boot. The two terms describe different features. MCUboot’s documentation, for example, covers both: the bootloader validates each image before booting it, and a separate, optional measured boot feature records attributes and measurements of the image and shares this boot status information with the runtime software ^[8].

Root-of-trust options compared

Our original comparison of the main hardware root-of-trust options:

These options can be combined, for example SoC ROM secure boot for enforcement plus a secure element or TPM for device identity keys. Check each row against your SoC vendor’s documentation.

Hardware root of trust vs TPM. A TPM is one kind of root of trust: the Trusted Computing Group describes it as a hardware-based root of trust that generates and stores keys and attests to platform integrity ^[12]. NIST lists measurement, storage, reporting, recovery, verification and update among root-of-trust functions ^[1]. Enforcing that only signed code runs is a separate function; in many designs it comes from the SoC boot ROM or an immutable bootloader.

Key provisioning in manufacturing

Even a well-designed boot chain fails if the wrong key ends up in the fuses, or the right key leaks.

• Decide what goes into the device, and where. Typically a hash of the boot-verification public key (fuses), a device-unique identity key (secure element, TPM or protected storage) and, where needed, debug-lock settings.
• Generate signing keys in an HSM and keep private keys out of the factory. The factory programs public material and locks the device.
• Lock debug access (JTAG/SWD) and close the "development mode" fuses as part of the production flow, with a record per serial number.
• Plan for key rotation and revocation before the first unit ships. Some SoC ROMs support several key slots or revocation fuses. Check what yours supports.
• Record what happened. A per-unit log of what was provisioned, when and by which station is evidence you’ll want later.

The signing side, including key hierarchy and HSM use, is covered in our firmware signing and key management guide.

Rollback protection

Signed but old firmware is still dangerous if it has a known vulnerability. Anti-rollback stops a device from booting an image older than a stored minimum.

• Store the minimum in hardware: fuses, a monotonic counter, or a counter in a secure element or TPM.
• Use a security counter separate from the version number. MCUboot, for example, compares an image’s security counter with a value held in non-volatile trusted storage, and notes that the counter needn’t increase with every release ^[8].
• Consider raising the counter only for security-relevant releases, and only after the new image is confirmed healthy, so functional rollback still works. See our secure firmware update architecture guide for how this fits the update flow, and the OTA architecture decision tree for choosing a pattern.

Legacy SKUs already in the field

Products shipped without secure boot can’t simply have it switched on. Options, roughly from least to most invasive:

1. Harden what you have. Sign updates and verify them in the existing bootloader, even without a hardware anchor. This raises the bar but isn’t a root of trust.
2. Enable a dormant SoC feature. Some SoCs support secure boot that was never turned on. Enabling it in the field means programming fuses remotely, which is irreversible and risky if it fails.
3. Redesign at the next hardware revision. Add a hardware root of trust, and keep the old SKU on a separate, clearly documented support track.

Whichever you choose, record the decision and its reasoning. Under the CRA, the cybersecurity risk assessment must be documented and updated as appropriate during the support period, and relevant cybersecurity aspects must be documented systematically (Art. 13(3) and 13(7)) ^[2]. Check with your SoC vendor whether field fuse programming is supported for your part.

If this turns into a multi-product retrofit, our guide to evaluating firmware development companies covers what to ask an outside team.

Where to start

1. List each product’s processor and whether it has a ROM secure boot, TrustZone, a secure element or a TPM.
2. Draw today’s chain of trust and mark where it ends.
3. Choose the root of trust per platform using the table above.
4. Design the factory provisioning flow and key custody before tooling.
5. Define anti-rollback storage and counter policy.
6. Work through our bootloader security checklist.

For a gap list across secure boot, signing and updates, try the free Secure Update Readiness Assessment.

Spotted an error? Report it to our corrections log. Read our editorial methodology.