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

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.

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.

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 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.

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).

• 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)).

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.

A CRA gap check starts with deterministic evidence: SoftWSP's firmware scan extracts the software bill of materials and matches each component's version against CVE, KEV and EPSS data, independent of any AI step. AI's role sits on top of that evidence — drafting the narrative section of a gap-check report that maps specific findings to the Annex I requirement they touch (known-exploitable components ahead of patching, missing update-signing evidence, an absent vulnerability-handling policy) and to Article 14's 24-hour reporting fields, in plain language an engineer can confirm or correct before the report goes to a notified body or an EU CSIRT. AI never asserts conformity itself, and the underlying scan runs unchanged if AI drafting is unavailable.

This guide is general information, not legal advice.