GlossaryHardwareEmbedded

Secure Boot

Secure boot verifies the signature of every stage of firmware before it runs. How the chain of trust works, where it is specified, and where it fails in real devices.

Updated October 7, 2026This page as Markdown

In short

Secure boot is a mechanism in which each stage of a device's start-up verifies the cryptographic signature of the next stage before executing it, starting from an immutable root of trust in ROM or one-time-programmable memory. It prevents modified or foreign firmware from running. It is a requirement in practice under UN R155, ETSI EN 303 645 and the Cyber Resilience Act, and one of the first things we check in a hardware penetration test.

What is secure boot?

Secure boot is a start-up process in which every piece of code is checked before it is executed. The first stage, typically a boot ROM baked into the silicon, holds or references a public key (often as a hash in eFuses) and verifies the signature of the first-stage boot loader. The boot loader verifies the next stage, and so on down to the operating system kernel, the root file system and the application. The sequence is called the chain of trust; the immutable first element is the root of trust.

If a signature does not match, the device refuses to boot, falls back to a recovery image or enters a locked state. The attacker’s options shrink to attacks on the root of trust itself (fault injection, hardware bugs) or on the signing keys.

Where is it defined?

There is no single standard. UEFI Secure Boot for PCs and servers is specified in the UEFI Specification (platform key, key exchange key, signature databases db and dbx). For Arm application processors, the Trusted Board Boot requirements implemented in Trusted Firmware-A describe the chain from BL1 in ROM through BL2 and BL31 to the rich OS. NIST SP 800-193 defines protection, detection and recovery requirements for platform firmware, including that the root of trust is immutable and that updates are authenticated. Microcontroller vendors specify their own flows: hardware security modules on automotive microcontrollers verify the application flash at start-up, and IoT SoCs provide secure boot via eFuse-locked key digests.

Regulation references it indirectly: UN R155 Annex 5 lists software manipulation as a threat and integrity protection of software as a mitigation; ETSI EN 303 645 provision 5.7 asks that software integrity is verified using secure boot mechanisms; the Cyber Resilience Act Annex I requires protection of integrity of software and firmware.

What it means in practice

Secure boot is almost always “implemented” and often not effective. Things we regularly find in ECU and IoT tests:

Development configuration shipped. The signature check exists, but the fuse that enforces it was never burned, or the key hash slot still holds the vendor’s test key.
Partial chain. The boot loader is verified, the Linux root file system is not (no dm-verity, no signed squashfs). An attacker modifies a start-up script and owns the device with the chain intact.
Bypass via another mode. A UART recovery command, a USB boot mode or a diagnostic routine loads unsigned code.
No anti-rollback. A signed but old, vulnerable image is accepted again.
Time-of-check gaps. The image is verified in external flash, then re-read for execution. Swapping the content in between is a known attack on cheap SPI designs.

For a power-electronics ECU with an AURIX microcontroller the review covers the HSM boot configuration, the UCB settings and whether the application can be flashed via UDS without the HSM re-validating it. Getting these details right is most of the work.

Common misunderstandings

Secure boot does not protect against vulnerabilities in correctly signed code: a buffer overflow in a signed application runs as signed code. It also does not make keys safe; if the signing key is on a build server without access control, the chain is only as trustworthy as that server. And “secure boot enabled” in a datasheet says nothing about the configuration in the shipped device.

FAQ

Frequently asked questions

Is secure boot the same as encrypted firmware?

No. Secure boot checks authenticity and integrity with a signature; it does not hide the code. Firmware encryption protects confidentiality and needs a key on the device. Many products need both: signature checks against tampering, encryption against reverse engineering and cloning. One without the other leaves a gap.

Does secure boot stop firmware extraction?

Not by itself. Secure boot stops unsigned code from running; it does not stop an attacker from reading flash via a debug port or by desoldering the chip. Readout protection, locked debug interfaces and encryption are separate measures. A bypassed or missing signature check makes extraction easier, because the attacker can run their own dumper.

How do you test secure boot?

We read the fuse and option-byte configuration, check whether the public key hash is actually locked, modify one byte of a signed image and verify the device refuses it, test whether debug or recovery modes bypass the check, check anti-rollback, and look at the whole chain down to the file system. On automotive microcontrollers this includes the HSM configuration. A full test takes days, not hours.

Sources

← Glossary