The Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents from 11 September 2026, with an early warning within 24 hours, a full notification within 72 hours and a final report within 14 days. The remaining obligations apply from 11 December 2027.
A question keeps coming back from industrial clients: if our machine has software on board, and that software has a hole, who has to say so and to whom. Until recently the answer was a shrug and a quiet patch. From 11 September 2026 there is a procedure, its deadlines are measured in hours, and missing them can be fined.
The Cyber Resilience Act, Regulation (EU) 2024/2847, brings CE marking into cybersecurity: products with digital elements that are not secure cannot stay on the European market. It entered into force in December 2024, but the obligations arrive in stages, and the first stage is a few weeks away.
The two dates that matter
11 September 2026. Reporting obligations start. The manufacturer has to notify actively exploited vulnerabilities and severe incidents that affect the security of a product with digital elements. Reports go through a single European platform, the Single Reporting Platform, which routes them to ENISA and the relevant CSIRT.
11 December 2027. Everything else applies: essential cybersecurity requirements, technical documentation, vulnerability handling across the support period, conformity assessment and CE marking.
One detail catches people out. The reporting obligations also cover products already placed on the market before the regulation fully applies. A device you sold in 2023 and still support is in scope from September.
It concerns you even if you do not make hardware
The perimeter is products with digital elements: connected hardware, but also software placed on the market as a product. Operating systems, routers, industrial sensors, applications, commercial libraries. Pure cloud services stay outside, unless a remote data processing component is an integral part of the product, and so do sectors with their own rules such as medical devices, automotive and civil aviation. Open source developed outside a commercial activity is excluded, with an intermediate figure, the open source steward, for foundations distributing components that industry depends on.
On custom software the honest answer is that it depends on how you make it available. A module you resell to several clients is a product. A management system built for one client and never commercialised is a case to look at with a lawyer, not something to settle in an article. In both scenarios, though, the technical work you need is the same.
Reporting in 24 hours: what you need ready
The windows are tight. An early warning within 24 hours of becoming aware of an actively exploited vulnerability, a full notification within 72 hours, and a final report within 14 days of a corrective measure being available. For severe incidents the final report is due within a month. The clock starts when you become aware, which in practice means when the email lands in whatever inbox you published.
Twenty-four hours is not much when the report arrives on a Friday evening and the person who knows where to look is on holiday. You need a channel where reports actually land, meaning a security address someone reads, a person on call, and a notification template with the fixed parts already filled in. Whoever did this work for NIS2 is halfway there, because the 24 and 72 hour windows are the same ones.
SBOM: knowing what is inside
The CRA asks manufacturers to identify and document the components of a product, including a software bill of materials in a commonly used machine readable format, covering at least the top-level dependencies. It does not have to ship to end users. It lives in the technical documentation, and market surveillance authorities can ask for it.
In practice that means generating the SBOM in the pipeline on every build, with CycloneDX or SPDX and tools that are free, storing it next to the artefact, and wiring it to a feed of known vulnerabilities. The real payoff is not compliance. It is that when the next Log4Shell lands you know in ten minutes which of your products contain the library, instead of finding out after three days of grep.
Penalties, so we are clear
Breaching the essential cybersecurity requirements or the reporting obligations goes up to 15 million euro or 2.5 per cent of annual worldwide turnover, whichever is higher. Other obligations top out at 10 million euro or 2 per cent. Incorrect or incomplete information supplied to authorities costs up to 5 million euro or 1 per cent.
What is worth doing now
A few weeks are not enough to rebuild product security, but they are enough for the reporting part, which is the only piece mandatory in September. You need to know which products are in scope, who the named contact is, how you would find out you are under attack, and who writes the notification. The rest, SBOM in the pipeline, secure updates, a declared support period, gets built over the fifteen months that lead to December 2027.
That build is easier with whoever writes the software in the room. It is part of how we handle custom software projects, and if you are unsure whether a product of yours is in scope, tell us what it does.
