Secure Boot

Secure Boot is a hardware-enforced security mechanism that verifies the digital signature of each component in the device's startup sequence — from the initial bootloader through the operating system kernel to application code. Before executing any component, the firmware checks its cryptographic signature against a set of trusted keys stored in protected hardware (typically a TPM or hardware security module, or fused into the SoC). If the signature is invalid or absent, the device refuses to boot. This ensures that even if an attacker gains physical access to a device or manages to write modified firmware, the device will not execute unauthorised code. Secure Boot is one of the most effective defences against firmware-level supply chain attacks, rootkits, and persistent malware.

The CRA's Annex I requires manufacturers to protect the integrity of software and firmware, including through mechanisms that ensure only authorised software can be executed. Secure Boot is a primary mechanism for satisfying this requirement in embedded and IoT products. Specifically, Annex I requires that products only run software that is verified for integrity and authenticity. For products where the software runs at elevated privilege levels or controls physical processes (industrial controllers, medical devices, automotive systems), Secure Boot is effectively mandatory to demonstrate compliance with the integrity protection requirements. Products without Secure Boot must provide alternative technical justification for how firmware integrity is maintained — a difficult argument to make for network-connected devices.

Implementing Secure Boot requires coordination between hardware selection, firmware development, and key management:

• Hardware root of trust: Select SoCs or microcontrollers with hardware support for Secure Boot (most modern IoT SoCs include this). The root of trust must be immutable — keys must be stored in one-time-programmable (OTP) fuses or hardware security modules.
• Key hierarchy: Design a signing key hierarchy — a root CA key (kept offline and air-gapped), an intermediate key for signing production firmware, and a key revocation mechanism for responding to key compromise.
• Boot chain verification: Each stage of the boot chain (ROM bootloader → secondary bootloader → OS kernel → application) must verify the next stage before execution.
• Rollback protection: Prevent downgrade attacks by implementing version counters in protected storage that prevent rolling back to older, potentially vulnerable firmware versions.

Secure Boot must be integrated with the OTA (Over-the-Air) update mechanism to maintain security through the product lifecycle. When an OTA update is applied:

1. The update package must be cryptographically signed with the manufacturer's firmware signing key.
2. The device must verify the signature before applying the update.
3. The update must be applied atomically — partial updates that could leave the device in an inconsistent state must be rejected.
4. After update, the new firmware image must pass Secure Boot verification before the device reboots into the updated state.

A Secure Boot implementation that is bypassed by an unsigned OTA update process defeats its own purpose. Manufacturers should verify that the OTA code path is subject to the same integrity verification as the initial boot chain.