Skip to content

Secure Boot and CRA

Draft — needs compliance review before external use

Explains how secure boot supports specific CRA requirements. Secure boot is one mechanism among several; it supports integrity and update-trust requirements, not the whole of Annex I. Verify against the official text.

Several of the CRA's Annex I requirements come down to one property: the device only runs firmware you authorized. That's what secure boot provides. At power-on, the device checks a cryptographic signature on each stage of firmware before executing it — if the signature doesn't verify against a key rooted in the hardware, the firmware doesn't run.

Why it maps to the CRA

Secure boot is the enforcement point for the CRA requirements about integrity and trustworthy updates:

  • Integrity of code (Part I). Firmware that's been tampered with — or replaced entirely — fails signature verification and won't boot. Unauthorized modification isn't just detected; it's prevented from executing.
  • Trustworthy security updates (Part I & Part II). A security update is only a remediation if the device can tell it apart from an attacker's payload. Secure boot means an update installs and runs only if it carries a valid signature made with your key. This is the technical backbone of the "distribute security updates securely" obligation and the remediation that Article 14 reporting assumes exists.
  • Reduced incident impact (Part I). A compromise that can't survive a reboot — because malicious firmware won't pass verification — is a contained compromise.

The keys that anchor all of this should live in an HSM, not on a build machine. That's LAAVAT's role: the signatures your devices verify at boot are produced by keys generated inside AWS CloudHSM that never exist in plaintext outside it, so the root of trust your product enforces is one an attacker can't extract from your infrastructure.

LAAVAT's chipset and format coverage

Secure boot is chipset-specific — the mechanism, key formats, and signing steps differ across silicon vendors. LAAVAT's signing operations cover a broad range of silicon, bootloaders and package formats; the guides below are examples of the most commonly used flows, not the full list of what the platform can sign.

Silicon and secure boot

  • NXP i.MX secure boot — HAB and AHAB signing for the i.MX family, including detached-digest flows. See the HAB and AHAB examples and CST signing.
  • STMicroelectronics secure boot — ST platforms, including SBSFU authentication and encryption keys.
  • Xilinx / AMD signing — Bootgen images, including Zynq UltraScale+ MPSoC variants.
  • Microcontrollers — MCUboot signing for the MCUboot secure bootloader.

Bootloaders, update and package formats

  • RAUC bundle signing — A/B-updated Linux systems, with ephemeral one-time-key signing available.
  • FIT image signing — U-Boot FIT images; U-Boot and kernel images can also be signed directly.
  • Detached digest signing — signs a digest rather than the artifact, so any format can be covered without uploading the image.

Beyond these, the platform also signs OP-TEE trusted applications, and vendor-specific flows such as NXP key exchange. The signing operations are enumerated in the audit event reference; which of them a given product exposes is set up in Product management.

Because detached digest signing signs a hash rather than a specific container format, platforms without a dedicated guide can usually be supported through it. If you don't see your silicon or format here, see Getting started — the coverage above is a starting point, not a boundary.

What secure boot does and doesn't cover

Secure boot supports the integrity and update-trust requirements. It is not, by itself, CRA compliance:

  • It doesn't manage your SBOM, your CVE monitoring, or your disclosure process (Annex I Part II process requirements).
  • It doesn't minimise your attack surface or handle data confidentiality beyond firmware — those are product-design requirements.
  • It's most effective as part of a chain: hardware root of trust → verified bootloader → verified firmware → verified updates. LAAVAT signs the artifacts in that chain; enabling and configuring the chain on-device is your integration work, covered in the chipset guides above.