CRA checklist for device makers and embedded firmware teams

Last updated: 2026-10-19

This checklist turns the Cyber Resilience Act into tasks an embedded team can assign. Two items are already due: vulnerability intake and the 24-hour reporting process, which apply since 11 September 2026. The rest must be in place for products placed on the EU market from 11 December 2027.

Each item cites the article or annex point it comes from. For the background, start with the Cyber Resilience Act hub.

Phase 0 – already due (reporting since 11 September 2026)

• Publish a coordinated vulnerability disclosure (CVD) policy and a contact address for reports (Annex I Part II (5) and (6)). Template: VDP and security.txt.
• Designate a single point of contact for users, easy to find and not limited to automated tools (Art. 13(17)).
• Name an on-call owner who can decide within hours whether a report is an actively exploited vulnerability and file the early warning within 24 hours (Art. 14(2)(a)).
• Identify your CSIRT coordinator: the Member State of your main EU establishment, or for non-EU manufacturers the order set out in Art. 14(7) (authorised representative, importer, distributor, users).
• Get access to the ENISA Single Reporting Platform before you need it. Process details: CRA 24h/72h reporting.
• List every product still on the EU market, old models included; Article 14 covers products placed before 11 December 2027 (Art. 69(3)).
• Prepare user notification: a way to tell impacted users about an exploited vulnerability and what they can do (Art. 14(8)).

Phase 1 – know what you ship

• Build an SBOM per firmware release in a machine-readable format (CycloneDX or SPDX), covering at least top-level dependencies (Annex I Part II (1)). Kernel, bootloader, libc, TLS library, web server, vendor SDK blobs and companion-app libraries all count.
• Map known vulnerabilities to each SBOM and record which are exploitable in your configuration. Use VEX to document “not affected” decisions. See firmware SBOM.
• Check for known exploitable vulnerabilities before release; products must ship without them (Annex I Part I (2)(a)).
• Do third-party due diligence on chip SDKs, ODM code and open-source components (Art. 13(5)).
• Classify each product against Annex III (important class I/II) and Annex IV (critical) by core functionality.

Phase 2 – design and hardening (Annex I Part I)

• Write a cybersecurity risk assessment per product and keep it updated (Art. 13(2)–(3), (7)).
• Remove shared default passwords; force unique credentials or user-set credentials (Part I (2)(b), (d)).
• Secure-by-default configuration with a factory reset that restores it (Part I (2)(b)).
• Close unused ports and debug interfaces (UART, JTAG, telnet, test endpoints) in production builds (Part I (2)(j)).
• Encrypt sensitive data at rest and in transit with current mechanisms; no hard-coded keys (Part I (2)(e)).
• Protect integrity of firmware, configuration and commands: secure boot, signed images, authenticated APIs (Part I (2)(f)).
• Enable exploit mitigations your toolchain supports: stack protection, ASLR/NX where the platform allows, hardened compiler flags (Part I (2)(k)).
• Rate limiting and denial-of-service resilience for exposed services (Part I (2)(h)–(i)).
• Security logging of access and configuration changes, with user opt-out (Part I (2)(l)).
• Data minimisation and secure deletion: collect only what the function needs and allow a full user wipe (Part I (2)(g), (m)).

Phase 3 – updates for the whole support period

• Set a support period of at least five years, or the expected use time if shorter, and document the reasoning (Art. 13(8)).
• Show the support end date (month and year) at the point of sale (Art. 13(19)).
• Signed, secure update channel with rollback protection and recovery from failed updates (Part I (2)(c), Part II (7)).
• Automatic security updates on by default where applicable, with opt-out and postponement (Part I (2)(c)).
• Separate security fixes from feature updates where technically feasible (Part II (2)).
• Keep each security update available for at least 10 years or the rest of the support period (Art. 13(9)).
• Make sure you can rebuild old firmware: archived toolchains, SDKs and build scripts. Without this, you cannot patch.

Phase 4 – process and evidence (Annex I Part II)

• Regular security testing: code review, fuzzing of parsers and network services, penetration tests (Part II (3)).
• Publish advisories for fixed vulnerabilities, with affected versions, impact, severity and remediation (Part II (4)).
• Free security updates with advisory messages (Part II (8)).
• Technical documentation per Annex VII, including the SBOM, CVD policy and update design.
• User information per Annex II: contact point, support end date, secure setup and decommissioning instructions.

Phase 5 – conformity and market access

• Choose the conformity route: module A self-assessment, EU-type examination (module B + C), or full quality assurance (module H), per product class (Art. 32, Annex VIII).
• Book a notified body early if a class requires it; capacity is limited (to be confirmed per sector).
• Draw up the EU declaration of conformity and affix the CE marking (Art. 28–30).
• Brief importers and distributors: they must check your CE marking, documentation and contact details.
• Keep documentation for 10 years or the support period, whichever is longer (Art. 13(13)).

Where teams get stuck

The most common blockers we see in firmware projects are practical, not legal: no source code from the ODM, a frozen chip-vendor SDK, a lost build environment, or no rollback in the bootloader. Plan those early, because they decide whether you can meet Part II at all.

Softwsp can produce the SBOM and vulnerability list from your binaries, fix or mitigate issues at firmware level, and run vulnerability intake for you: device firmware security and PSIRT as a service. For a plain-English reading of every requirement, see CRA Annex I explained.

This guide is general information, not legal advice.