Skip to content
Inovasense

Secure Boot

Secure boot authenticates boot software before allowing it to execute.

Author:
Inovasense Team
Updated:
Definition
Secure boot authenticates boot software before allowing it to execute.

How secure boot works and what it cannot prove

Secure boot authenticates boot software before allowing it to execute. In a common embedded design, protected initial verification code validates a signed bootloader, which validates the application image. The exact stages and algorithms depend on the processor and boot implementation. Secure boot protects against unauthorised image replacement; it does not prove that approved software is vulnerability-free or prevent all runtime exploitation. Measured boot records measurements for later evaluation; measurement by itself does not necessarily block execution. Anti-rollback and a protected recovery path are additional design choices to evaluate and test.

CRA: requirements and engineering choices

CRA requirements are outcome-oriented and technology-neutral, based on the product’s cybersecurity risk assessment and applicability. Secure boot, a hardware root of trust, TPM, TrustZone and wireless OTA can be appropriate engineering controls; they are not universal legal mandates for every product. Document why the chosen controls satisfy the applicable requirements rather than equating one architecture with compliance.

CRA scope and application dates

The CRA entered into force on 10 December 2024. Article 14 reporting has applied since 11 September 2026; the main product requirements apply from 11 December 2027. Article 69 contains transitional rules for previously placed products. Products subject to MDR or IVDR are excluded under Article 2(2); other exclusions and non-commercial free/open-source scope must also be checked.

Practical checklist

  1. Identify the product, intended use, market and applicable legal scope.
  2. Record the exact legal provisions, dates and applicable standard editions, including restrictions.
  3. Select the permitted assessment route and document the evidence needed.
  4. Link risk assessment, tests, product versions and declarations in the technical documentation.
  5. Assign responsibility for changes, support and responses to authorities.

This checklist supports planning; the applicable legal requirements determine the final assessment.

Primary sources

Related Terms