Trust anchor, key roles and limitations
A hardware root of trust anchors selected security functions in hardware-backed mechanisms whose integrity the system relies on. Implementations may use protected boot code, key material, isolated execution or a dedicated security component. A public verification key or its hash is not the same as a secret private signing key: the manufacturer normally protects the signing key in its signing infrastructure. TrustZone, a TPM and a secure element perform different roles; none is automatically a complete security architecture or a product certification. Tamper resistance has a defined threat model and assurance level, not a guarantee that keys are physically impossible to extract. Evaluate debug access, fault injection, side channels and key recovery separately.
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
- Identify the product, intended use, market and applicable legal scope.
- Record the exact legal provisions, dates and applicable standard editions, including restrictions.
- Select the permitted assessment route and document the evidence needed.
- Link risk assessment, tests, product versions and declarations in the technical documentation.
- Assign responsibility for changes, support and responses to authorities.
This checklist supports planning; the applicable legal requirements determine the final assessment.