Who should read this: anyone whose company sells software, a connected device, or a product with software in it, into the EU market. If you only consume technology rather than ship it, this one is not about you.
On 11 September 2026 the first hard obligation of the Cyber Resilience Act comes into effect. It is a reporting duty, it runs on a 24 hour clock, and it applies to manufacturers rather than to users.
What the obligation actually is
From 11 September 2026, manufacturers of products with digital elements must report two things:
- actively exploited vulnerabilities in their product
- severe incidents affecting the security of their product
The deadlines are short and they stack:
| Stage | Deadline |
|---|---|
| Early warning | 24 hours from becoming aware |
| Full notification | 72 hours |
| Final report, exploited vulnerability | no later than 14 days after a corrective measure is available |
| Final report, severe incident | one month |
Reports go through a single channel, the CRA Single Reporting Platform, to the CSIRT designated in the member state of your main establishment, and are shared with ENISA. That CSIRT then distributes to the other CSIRTs where the product is available. The platform is due to be operational on the same date the obligation starts.
The rest of the CRA, the essential cybersecurity requirements, the conformity assessment and the CE marking, applies from 11 December 2027. That gives you fifteen months on the substantive product requirements. It gives you no time at all on reporting.
Why this catches companies by surprise
Three reasons, and they are worth naming because each one produces a different kind of mistake.
It is a product regulation, not an organisation regulation. NIS2 asks whether your company is secure. The CRA asks about the thing you sell to other people. A company can be entirely outside NIS2 scope and squarely inside the CRA, and the two have different regulators, different obligations and different clocks.
“Product with digital elements” is broader than software. It covers software, hardware with software in it, and remote data processing solutions integral to the product. A connected sensor, an industrial controller, a router, a piece of embedded firmware, a SaaS component shipped as part of a product. Many companies that do not think of themselves as software vendors are manufacturers under this definition.
Awareness starts the clock, and awareness is not a decision you control. The 24 hours runs from when you become aware that a vulnerability in your product is being actively exploited. That knowledge often arrives from outside: a researcher, a customer, a CERT advisory, a public disclosure. If nobody at your company is watching the channels where that arrives, the clock has already been running when you find out.
The two things to have in place by Friday
You cannot build a vulnerability handling programme in a couple of days. You can put the two things in place that turn a missed deadline into a met one.
1. Name the person, and give them a route. Someone has to be allowed to decide that a report is required and to file it, without waiting for a meeting. In a company of forty people this is one named individual and one named backup. Write down who they are and how they are reached out of hours. This is the cheapest single control on this page and it is the one most often missing.
2. Know how you would find out. Where does the news arrive. A security contact address on your website that someone reads. Monitoring of the CVE feeds for your components. A relationship with the CERT of your main establishment. A path for a customer to tell you something is wrong that does not go through a general support queue and sit there for a week.
That second point is where most of the risk sits, and it is worth being blunt about why. A 24 hour clock is not difficult to meet if you know at hour zero. It is impossible to meet if you find out on day nine.
What to build in the following months
Once the immediate gap is closed, the work that makes this sustainable is ordinary and familiar.
A coordinated vulnerability disclosure policy. A published way for researchers and customers to report to you, with a stated response commitment. This is also an expectation under NIS2, covered in the NIS2 vulnerability disclosure framework.
A software bill of materials, and the habit of watching it. You cannot assess whether a vulnerability affects your product if you do not know what is inside it. Most CRA-relevant vulnerabilities will be in components you did not write.
An incident process that produces a report rather than a discussion. The 72 hour notification asks for specifics. Deciding what to say while the clock runs is how deadlines get missed.
Evidence that accumulates. The final report and any subsequent supervision will ask what you knew and when. Records created at the time answer that. Records assembled afterwards do not, an argument set out in evidence that assembles itself.
If you also sell into regulated customers, note that these obligations layer rather than replace each other. A telecom supplier can be in the CRA for its product and inside its customer’s NIS2 supply chain obligations at the same time, described in supply chain security under NIS2. An aviation supplier can be in the CRA and inside a customer’s Part-IS interface assessment, described in what Part-IS means for aviation suppliers. The efficient response to all of it is one control set with the frameworks mapped onto it, which is the argument in doing ISO 27001 and NIS2 once instead of twice.
What this is not
Worth saying clearly, because there is a lot of noise around this date.
It is not the full CRA. Conformity assessment, technical documentation and CE marking are December 2027 problems, and you have time to plan them properly.
It is not a certification. Nothing is being audited on Friday. There is no certificate to obtain, no assessor visiting, no scheme to join.
It is not about your internal IT security. It is about the security of what you ship.
And it does not apply to everybody. If you do not place a product with digital elements on the EU market, you are not a manufacturer under this regulation. Establish which side of that line you are on before you spend anything, because a meaningful number of companies will spend the next month preparing for an obligation they do not have.
The technical reality: the report is the easy half
The reporting duty is procedural. Name a person, watch the right channels, file within the window. That is achievable in a week.
The harder question sits behind it, and the regulation does not ask it. When you file the 72 hour notification saying a vulnerability in your product is being actively exploited, the next question from every customer will be how long it was there and how many of them are affected. Answering that needs an inventory of what is in your product, a record of which customer runs which version, and some way of knowing what has been happening in your own environment.
The regulation asks you to report what you know. It does not make you know anything. Companies that can answer the follow-up question will have built that capability for their own reasons, and companies that cannot will discover the gap in public with a clock running. A structured security audit is a reasonable way to find out which of those you are before Friday rather than after an incident.
