Start with the threat model
List the assets that matter: device credentials, signing infrastructure, personal data, control commands and service availability. Identify who can reach each interface and whether an attacker can physically possess the device. Decide which failures could affect safety. Select controls against these risks and record how they will be tested; a component’s security certificate does not certify the complete product.
A practical design and verification sequence
- Define trust boundaries between application, privileged firmware, external peripherals and backend.
- Separate private signing keys from device verification material; plan provisioning, rotation and revocation.
- Select boot, debug and storage protections supported by the exact device revision.
- Authenticate updates and test the recovery path after interrupted writes.
- Restrict exposed services, authenticate users and devices, and enforce authorisation at the API.
- Test negative cases: wrong image, revoked credential, old version, malformed input and lost connectivity.
- Maintain dependency records, vulnerability triage, release evidence and a support plan.
Test results must describe the target, configuration and attack assumptions. A successful secure-boot test does not establish resistance to every physical attack or runtime exploit.
Hardware trust and key protection
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.
Secure boot: protection and limits
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 and technology 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.
Applicable CRA dates and scope
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.
Frequently asked questions
Does CRA universally require secure boot?
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.
Does a secure element guarantee conformity?
No. It can protect selected keys and operations; conformity concerns the complete product and applicable requirements, including processes and evidence.
Sources and further reading
Related guides inEmbedded Security & IoT
Explore all →IoT Security Best Practices for Product Engineers
Practical IoT security across firmware, identity, APIs, updates and operations, with realistic hardware limits and accurate CRA obligations.
15 IoT Attack Types: Examples and Defences
Fifteen IoT threat categories, clearly labelled illustrative scenarios, a documented Mirai example and practical risk-based defences.