What is Secure Boot and Why Every IoT Device Needs It

A question that came up in a recent discussion about CRA compliance was whether secure boot is actually required or just recommended. The short answer is: it is required, and it is required because without it, none of your other security measures work reliably.

A device that boots unverified firmware is a device an attacker can fully own - regardless of how good the rest of your security architecture is.

What Happens When a Device Boots Without Secure Boot

When your microcontroller powers on, it starts executing code from a defined memory location. On most embedded platforms, this is the bootloader—a small piece of code that initializes hardware and loads the main application firmware.

Without secure boot, the bootloader loads whatever firmware it finds at the expected address. It does not check whether that firmware was written by you, whether it has been modified since you shipped it, or whether it is legitimate in any way. It just runs it.

This means an attacker who can write to your device's flash memory—through a firmware update channel, a debug interface, physical access, or a vulnerability in your update mechanism—can replace your firmware with their own. The device will boot it without complaint. It will appear to function normally. It is now running attacker code.

The attacker does not need to break your encryption. They do not need your private keys. They just need to get their firmware onto the device, and the device will run it.

This is not a theoretical scenario. It is the standard attack against IoT devices that lack firmware integrity verification. The Mirai botnet, which took down significant internet infrastructure in 2016, was built largely on devices where firmware modification was trivial.

How Secure Boot Works: The Chain of Trust

Secure boot solves this by making the device verify firmware authenticity before executing it. The mechanism is a cryptographic chain of trust that starts at the hardware level.

Here is how the chain works, step by step.

Step 1

Root of trust in hardware. The process starts with something that cannot be modified after manufacturing: a public key hash burned into One-Time Programmable (OTP) memory, or a key stored in hardware security elements on the chip. This is the hardware root of trust. It is the anchor of the entire chain - the one thing the attacker cannot replace.

Step 2

Bootloader verification. When the device powers on, the first-stage boot code (which lives in ROM and cannot be modified) reads the bootloader from flash and checks its cryptographic signature against the public key in OTP memory. If the signature is valid, the bootloader is authentic and execution continues. If the signature does not match, the boot halts.

Step 3

Application firmware verification. The bootloader, now verified, performs the same check on the main application firmware. It reads the firmware image, verifies its signature against a trusted public key, and only passes execution to the application if the signature is valid.

Step 4

Chain continues. Each verified component can extend the chain further—verifying configuration data, checking software versions, and validating update packages before applying them.

The result: the device only runs code that was signed with your private key. An attacker who replaces your firmware with their own cannot sign it with your key. The device will reject it and refuse to boot.

Why CRA Treats Secure Boot as a Baseline

Annex I of the CRA requires manufacturers to ensure the integrity of software running on connected products. The specific requirement is that products must include mechanisms to verify the authenticity and integrity of software— both at boot time and during updates.

Secure boot satisfies the boot-time requirement. Without it, there is no basis for claiming that the software running on a shipped device is the software you intended to ship.

This is why CRA treats secure boot not as an advanced security feature but as a baseline—the minimum foundation without which everything else is unreliable. Encrypted communications are only meaningful if you can trust that the device establishing the connection is running legitimate firmware. Unique device identity is only meaningful if the identity cannot be replaced along with a firmware swap.

Secure boot is the prerequisite that makes the rest of the security architecture trustworthy.

What This Looks Like on Nordic nRF and STM32

Nordic nRF (nRF5340, nRF9160, nRF52 Series)

Nordic's security architecture centers on the Trusted Execution Environment (TrustZone-M on Cortex-M33 cores) and the NSIB—Nordic Secure Immutable Bootloader. The NSIB lives in the device's ROM-equivalent region and is the hardware root of trust on these platforms.

The typical secure boot chain on nRF:

• NSIB verifies the first-stage bootloader (MCUboot) using a public key provisioned in the device's Key Management Unit (KMU) or UICR registers
• MCUboot verifies the application image signature before loading it
• Firmware images are signed with ECDSA (typically using a P-256 key pair) as part of the build process

Nordic's nRF Connect SDK includes MCUboot integration. The key management—generating signing keys, provisioning public keys into the device, signing images at build time—is where most teams need to put deliberate effort. The tooling exists; it requires intentional setup.

STM32 (STM32L5, STM32U5, STM32H5 series— TrustZone-capable)

ST implements secure boot through the STM32 Secure Boot and Secure Firmware Update (SBSFU) library, and more recently through the built-in Secure Boot (STiROT and OBKey) mechanisms on newer series.

The chain on STM32:

• The immutable ROM bootloader reads the secure boot configuration and public key hash from Option Bytes (OTP-equivalent)
• It verifies the application image before passing execution
• Anti-rollback protection is enforced through a monotonic counter in Option Bytes—the device will reject firmware older than the current installed version

One important detail on STM32: Option Bytes must be locked before shipping. Development boards ship with Option Bytes in an unlocked state, which allows debug access and key replacement. Shipping a device with unlocked Option Bytes means an attacker with physical access can re-provision the root of trust key. This is a configuration step that has to be part of your manufacturing process.

The Mistake That Ships with More Products Than It Should

Secure boot is disabled in the production build.

This happens more often than it should, and it happens for an understandable reason: secure boot complicates the development and testing workflow. Signing every firmware image, managing keys, and dealing with devices that refuse to boot unsigned debug builds add friction. So teams enable it in the security architecture, implement the mechanism correctly, and then leave a flag or build configuration that bypasses signature verification in production.

The device ships. It passes internal testing. The secure boot feature exists in the codebase. And it does nothing, because the production build has verification disabled or the signing key is a placeholder that was never properly provisioned.

The correct approach is to treat production configuration—Option Bytes locked, debug interfaces disabled, signing key provisioned, verification enforced—as a formal step in the manufacturing process with its own validation check. Not a development task that someone will get to.

FAQ

Does CRA Specifically Mention Secure Boot by Name? 

The regulation does not use the term "secure boot"; it requires manufacturers to "protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorized by the user" (Annex I, Part I, point (2)(f)). Secure boot is the standard implementation of this requirement for embedded devices. A device that cannot verify firmware integrity at boot time does not meet the Annex I requirement.

Can I Implement Secure Boot on Hardware That Does Not Have a Hardware Root of Trust? 

Partially. Some lower-end microcontrollers lack OTP memory or hardware key storage. In those cases, software-only implementations provide weaker guarantees - an attacker with flash access can potentially replace both the verification code and the key. For CRA compliance, hardware-backed root of trust is the correct approach. It is a hardware selection decision that should be made at the architecture stage, not after the board is designed.

Does Secure Boot Prevent All Firmware Attacks? 

No. Secure boot verifies that firmware is authentic at load time. It does not protect against vulnerabilities within the legitimate firmware itself - a properly signed firmware image can still contain bugs that attackers exploit at runtime. Secure boot is one layer of a defense-in-depth architecture, not a complete solution on its own.

What Happens If My Signing Key Is Compromised? 

If your private signing key is compromised, an attacker can sign malicious firmware that passes verification. Key management - generating keys securely, storing private keys in hardware security modules, rotating keys if compromise is suspected - is as important as the implementation itself. A secure boot implementation is only as strong as the key management around it.

We Have Secure Boot Implemented. Does That Mean We Are CRA-Compliant on Firmware Integrity? 

Secure boot covers boot-time integrity. CRA also requires integrity verification for firmware updates—the OTA update mechanism must verify the authenticity and integrity of update packages before applying them. These are related but separate requirements. Both need to be in place.