Cyber Resilience Act requirements: a guide for device and firmware makers

Last updated: 2026-10-19

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets mandatory cybersecurity requirements for hardware and software “products with digital elements” sold in the EU. Manufacturers must design products to the essential requirements in Annex I, handle vulnerabilities for a support period of normally at least five years, and report actively exploited vulnerabilities within 24 hours. Reporting has applied since 11 September 2026; everything else applies from 11 December 2027.

This guide is written for teams that build connected devices and firmware: cameras, routers, smart locks, gateways, wearables, controllers and the like.

Key CRA deadlines

The ENISA Single Reporting Platform went live on 11 September 2026, the same day reporting became mandatory. See CRA vulnerability reporting: 24h, 72h and final report.

What is in scope

The CRA applies to products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network (Art. 2(1)). A “product with digital elements” is a software or hardware product and its remote data processing solutions, including components placed on the market separately (Art. 3).

For device makers, that covers almost anything with firmware and a network interface, Bluetooth, USB data port or a cloud companion app. The cloud backend that the product needs to function can count as a “remote data processing solution”.

Main exclusions (Art. 2): medical devices and in-vitro diagnostics (Regulations 2017/745 and 2017/746), vehicle type-approval under Regulation 2019/2144, aviation products certified under Regulation 2018/1139, marine equipment under Directive 2014/90/EU, identical spare parts, and products made exclusively for national security or defence. Products not supplied in the course of a commercial activity are also outside scope.

Radio equipment is not excluded. Until 11 December 2027 it is covered by the RED cybersecurity rules; after that, by the CRA. See our EN 18031 guide.

Who has obligations: manufacturer, importer, distributor

Two points matter for brands that sell ODM hardware:

• Your logo makes you the manufacturer. An importer or distributor that places a product on the market under its own name or trademark, or substantially modifies it, is treated as the manufacturer and takes on Articles 13 and 14 (Art. 21).
• No source code is not an excuse. Article 13(5) requires due diligence when integrating third-party components, including open-source ones. If you only receive binaries from your ODM, you still need to know what is inside. Our firmware SBOM guide explains how.

Annex I essential requirements at a glance

Annex I has two parts.

Part I – product properties. Products must be designed for an appropriate level of cybersecurity based on risk, and, where applicable: ship without known exploitable vulnerabilities; be secure by default with a reset option; be fixable through security updates (automatic by default, with opt-out); protect against unauthorised access; protect confidentiality and integrity of data, commands and configuration; minimise data; protect availability, including against denial of service; limit attack surface; use exploit mitigation; log security-relevant activity; and let users securely delete their data.

Part II – vulnerability handling. Manufacturers must identify components and draw up a software bill of materials covering at least top-level dependencies; fix vulnerabilities without delay; test regularly; publish information on fixed vulnerabilities; run a coordinated vulnerability disclosure policy and provide a contact address; distribute updates securely; and ship security updates free of charge (unless agreed otherwise for tailor-made business products) with advisories.

A plain-English walk through every point is in CRA Annex I explained.

Product classes: default, important, critical

Most products fall in the default category and can use self-assessment (internal control, module A). Annex III and Annex IV list products that need more.

The categories are defined by a product’s core functionality. A camera that merely contains a microcontroller is not a class I microcontroller product; the camera itself is listed as a “security camera”. The Commission adopted technical descriptions of these categories in Implementing Regulation (EU) 2025/2392 (as referenced on the Commission’s CRA summary page).

Support period and user information

• The support period must be at least five years, unless the product is expected to be in use for less time (Art. 13(8)).
• Each security update must remain available for at least 10 years after release or for the rest of the support period, whichever is longer (Art. 13(9)).
• The end date of support (at least month and year) must be clear at the time of purchase (Art. 13(19)).
• You must designate a single point of contact for vulnerability reports, easy for users to find (Art. 13(17)).
• Technical documentation and the EU declaration of conformity are kept for 10 years or the support period, whichever is longer (Art. 13(13)).

Penalties

Member States set the rules, but the CRA fixes the ceilings (Art. 64):

Micro and small enterprises cannot be fined for missing the 24-hour early-warning deadline (Art. 64(10)). Market surveillance authorities can also require corrective action, withdrawal or recall.

What device makers should do now

1. Set up vulnerability intake today. Reporting is already live. Publish a disclosure policy and a security contact, and name who decides within 24 hours. Use our VDP template.
2. Inventory every SKU on the EU market, including old models still sold; Article 14 covers them.
3. Build an SBOM per firmware version, even from binaries, and map known vulnerabilities.
4. Classify each product against Annex III and IV to know whether you need a notified body.
5. Decide support periods and how you will deliver signed updates for that long.
6. Plan the gap closure against Annex I before 11 December 2027, model by model. Our CRA checklist for device makers breaks this into tasks.

Harmonised standards for the CRA are being drafted by CEN, CENELEC and ETSI under a Commission standardisation request; their final publication dates in the Official Journal are (to be confirmed).

Need help? Softwsp scans firmware, builds SBOMs from binaries, and can run your vulnerability intake and CRA reporting as a service: see device firmware security and PSIRT as a service.

This guide is general information, not legal advice.