Cyber Resilience Act

The Cyber Resilience Act is Regulation (EU) 2024/2847 of 23 October 2024, on horizontal cybersecurity requirements for products with digital elements. Being a regulation it binds directly, with no national transposition, and it is a law about products rather than about management: it reaches hardware and software placed on the European market whose intended purpose or reasonably foreseeable use includes a data connection, direct or indirect, logical or physical, to a device or a network. Article 2 leaves out what another sectoral law already covers: medical devices, vehicles, civil aviation, marine equipment and anything developed exclusively for defence.

Entry into force and application are different dates. It entered into force on 10 December 2024, twenty days after publication, but Article 71 makes it applicable from 11 December 2027. Two blocks come earlier: Chapter IV, on the notification of conformity assessment bodies, from 11 June 2026, and Article 14, the one that obliges the manufacturer to report, from 11 September 2026.

Classification decides who verifies. Most products go through the default regime, where the manufacturer’s internal control is enough. The important products of Annex III split into class I, nineteen categories that include browsers, password managers, antimalware, operating systems, routers and connected toys, and class II, four: hypervisors and containers, firewalls and intrusion detection or prevention systems, and tamper-resistant microprocessors and microcontrollers. For class II, Article 32 rules out internal control: it takes EU-type examination plus conformity to type (modules B and C) or full quality assurance (module H), both with a notified body, unless a European cybersecurity certification scheme at assurance level at least substantial is used. Above those sit the critical products of Annex IV, where the Commission may require by delegated act a European certificate at assurance level substantial or higher.

The substantive requirements are in Annex I: the security properties of the product, and vulnerability handling throughout the support period. That period lasts at least five years, unless a shorter use is expected, in which case it is that expected time; every security update released stays available for a minimum of ten years; and its end date, with month and year, is stated clearly at the point of purchase. Annex I also asks for the components to be documented in a machine-readable format, which is the idea behind a software bill of materials, without requiring it to be published.

The gap the regulation targets is the connected product shipped and forgotten: firmware with hard-coded credentials, no update mechanism, and no process to handle a vulnerability report when a researcher files one. For the attacker that is the reliable target: a device that cannot be updated stays vulnerable for its whole life. And a product inherits the vulnerabilities of its components, so a supply chain attack on a dependency becomes a problem the manufacturer has to detect and disclose.

The part that breaks most processes is Article 14, because the manufacturer does not start the clock. The duty is triggered by an actively exploited vulnerability, defined as one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s authorisation, and that evidence usually appears elsewhere: a customer, a researcher, a CSIRT. From there it is an early warning within twenty-four hours and a notification within seventy-two, to the designated coordinator CSIRT and to ENISA at the same time, and a final report fourteen days after a corrective or mitigating measure exists.

For severe incidents the initial deadlines are the same and the final report is not: one month from the seventy-two hour notification. And reporting does not exhaust the duty: paragraph 8 also requires the affected users to be informed.

The last failure is one of identity. Articles 21 and 22 turn whoever places a product on the market under their own name or trademark, and whoever substantially modifies one already on the market, into a manufacturer, with Articles 13 and 14 on top. An integrator relabelling someone else’s hardware is not a distributor: it is the manufacturer of what it sells.

The three get cited together and they do not compete with each other. The CRA regulates the product, NIS2 the organisation providing the service, and CE marking is the declaration with which a product is placed on the market. A Spanish manufacturer of connected devices can be in all three at once.

The practical consequence is that the evidence overlaps and the channels do not. The product side goes through the single reporting platform that Article 16 gives ENISA, to the node of the coordinator CSIRT of the member state where the manufacturer has its main establishment in the Union, where the cybersecurity decisions about its products are predominantly taken. The same event, if it also affects the operation of the entity, may go through the national NIS2 channel.

Confusing entry into force with application. In force since December 2024, but generally applicable only from 11 December 2027.

Assuming the old catalogue is safe. What was placed on the market before 11 December 2027 is caught only if it is substantially modified afterwards, but the reporting duty of Article 14 applies to everything.

Setting the support period for commercial convenience. It has to reflect the expected time of use, with a floor of five years.

Relabelling somebody else’s product and believing you are a distributor. Selling under your own brand makes you the manufacturer, with Articles 13 and 14 in full.

Treating the bill of materials as a commercial document. Annex I asks for it machine-readable and covering the top-level dependencies at least; not having to publish it does not mean not having to hold it.

Classify the catalogue first, product by product: out of scope, default regime, Annex III class I, Annex III class II or Annex IV. That decision sets the cost and the timetable, because it settles whether internal control is enough. Since Implementing Regulation (EU) 2025/2392 those categories have a published technical description, so the classification can be argued against a text.

Then decide the support period of each product and write down the reasoning: what use is expected, what users reasonably expect, and what the rest of Union law requires. Alongside it goes the ten-year availability of the updates, which is an archiving commitment more than an engineering one.

Build the reporting process before 11 September 2026 and rehearse it: who decides there is reliable evidence of active exploitation, who drafts within twenty-four hours, who holds credentials on the platform, which CSIRT is the coordinator, and how affected users are told. The first attempt should not coincide with the first incident.

And produce the technical evidence continuously: placing a product on the market with no known exploitable vulnerabilities is demonstrated with dated testing and a remediation record, not with a declaration. A cycle of penetration testing on the product, with its retest, serves conformity and vulnerability handling at the same time.

An assessment against what the CRA expects tests the properties of Annex I: whether the product ships free of known exploitable flaws, whether it enforces integrity at boot through secure boot, whether updates are authenticated and reach the fleet already deployed, and whether the components are inventoried. For industrial products the control framework is usually IEC 62443. The finding is tied to both things, the technical vulnerability and the obligation it touches.

The second thing audited is not the product but the process: whether there is a point through which reports arrive, whether somebody decides the classification, whether the twenty-four and seventy-two hour deadlines have an owner, and whether the bill of materials is generated on every build or was written once.

We do not advise on legal scope or on reporting duties, and we say so. What we bring is the technical evidence, in a form a notified body or a customer’s compliance team can read. It is part of how we test a product against its security obligations.

When does the CRA start to apply? It entered into force on 10 December 2024 and will be generally applicable from 11 December 2027. Two parts come earlier: Chapter IV, on the conformity assessment bodies, on 11 June 2026, and the manufacturer’s reporting obligations on 11 September 2026.

Which products does it apply to? Products with digital elements whose intended purpose or reasonably foreseeable use includes a data connection, direct or indirect, to a device or a network. Medical devices, vehicles, civil aviation and marine equipment are among those left out, because another sectoral law already covers them.

How long does support have to last? At least five years, unless the product is expected to be in use for less time, in which case the support period is that expected time. Every security update released stays available for a minimum of ten years, and the end date of support is stated at the point of purchase.

What has to be reported, and how quickly? Actively exploited vulnerabilities and severe incidents, to the coordinator CSIRT and to ENISA at the same time: an early warning within twenty-four hours and a notification within seventy-two. The final report comes fourteen days after a corrective measure exists, or within one month for a severe incident.

What are the fines? Breaching the essential requirements of Annex I or the obligations of Articles 13 and 14 reaches up to EUR 15,000,000 or 2.5 % of total worldwide annual turnover, whichever is higher. That is the highest band in the regulation, and the remaining obligations carry lower caps.