The EU Cyber Resilience Act (CRA) sets new expectations for embedded products - from secure design to traceable evidence. In this session, we’ll show how to turn CRA requirements into practical architecture decisions, manage updates safely, and prepare the minimal proof needed for CE compliance and audits. You’ll leave with a clear view of what to design, document, and verify to make your embedded products CRA-ready.
Objective
- Understand what the CRA expects from embedded products and teams.
- Turn requirements into architectural decisions (boot, keys, updates, SBOM flow)
- Know the minimal evidence you need for CE/conformity and audits.
- Explore solutions to comply with the CRA.
Agenda:
Why these matters
- Overview of PDE and product classification
- What’s in scope for embedded; typical pitfalls we see.
- How this relates to CE/conformity and other EU regs (NIS2/Cybersecurity Act).
Secure-by-Design: decisions you lock in early
- Threat model “lite” that drives architecture.
- Root of trust & key management options (TPM/SE vs. MCU features).
- Partitioning & least privilege (boot chain, services, comms).
- What to write down now so it becomes evidence later.
Evidence by architecture
- Map requirements → artifacts: update policy, vuln-handling procedure, SBOM, release notes, EoL/patch policy
- ARM security features that help
- TF-M benefits
- RTOSs and Zephyr integration: TF-M (Secure) + Zephyr app (Non-Secure), MCUboot
Updates without bricking devices
- Trust chain for updates: signing, versioning, rollback, recovery paths.
- Field constraints: bandwidth, power, storage; how to choose a strategy.
- SBOM flow through the pipeline (Yocto/Zephyr examples), vulnerability handling.
Q&A
➡️ Monday, 8 December 2025
Can’t join live? Register to receive the slides and recording afterward