Reading time: about 8 minutes
From 11 September 2026, if you place a machine, device or software with digital elements on the market under your own name, you must report actively exploited vulnerabilities and severe incidents on three clocks: an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days of a fix being available for a vulnerability, or within a month for an incident. You report once, through a single platform, to your competent CSIRT, and the information reaches ENISA at the same time. This is the first CRA deadline that actually bites; the full product obligations only start on 11 December 2027. This clock applies whether or not you are covered by NIS2. On 11 September you need a working reporting capability, not full product compliance.
What exactly starts on 11 September
The CRA, the Cyber Resilience Act, phases in over time. Most of the product obligations, such as lifecycle security requirements, technical documentation and CE marking for digital elements, only start on 11 December 2027. But one block starts earlier, and it is the subject of this note: the reporting obligation. Per the European Commission, it applies from 11 September 2026.
From that day a manufacturer has to report two things. The first is an actively exploited vulnerability in a product with digital elements, meaning one for which there is evidence that someone is really exploiting it, not just a theoretical possibility. The second is a severe incident affecting the security of the product. Both events trigger the same multi-stage reporting process with hard deadlines counted in hours.
This distinction matters, because the September deadline does not mean the whole CRA has to be in place on that day. It means that from that day you have to be able to detect a qualifying event and report it within the required time. The reporting capability runs more than a year ahead of the rest of the act.
Are you a manufacturer under the CRA
The obligation is addressed to the manufacturer of a product with digital elements, meaning the entity that places such a product on the market under its own name or trademark. A product with digital elements is a broad category: software, but also hardware containing software or a connectivity module. A manufacturer of a machine with a PLC, a device with firmware, a component with a network module, or an application sold separately falls within the definition. The table below helps you settle your own role.
| Your situation | CRA role | What the clock covers |
|---|---|---|
| You place a machine with a PLC or firmware on the market under your own name | Manufacturer of a product with digital elements | Actively exploited vulnerabilities and severe incidents in that product |
| You sell a device with a network or connectivity module | Manufacturer | Same |
| You sell software separately, including with an embedded AI model | Manufacturer | Same |
| You only use someone else's AI or software internally | Not the manufacturer of that product | Your vendor reports; your contract and supply chain should reflect it |
| You distribute or import a product under someone else's brand | Distributor or importer (lighter duties) | Verify your own duties, this is not the manufacturer's full clock |
The pattern is clear: your role turns on whether you place the product on the market under your own name, not merely on there being software inside it. If you do, the reporting clock applies to you from 11 September.
Three clocks: 24h, 72h, 14 days or a month
A report is not a single document, it is a sequence. The counter starts when the manufacturer becomes aware of the event. Article 14 of the CRA sets the deadlines, and the table shows the practical layout.
| Stage | Deadline | What you submit |
|---|---|---|
| Early warning | 24h from awareness | A signal: what is happening, which product, whether it is being exploited |
| Full notification | 72h | Nature of the vulnerability or incident, assessment so far, mitigations |
| Final report (vulnerability) | 14 days after a fix is available | Description, impact, the fix or workaround made available |
| Final report (incident) | one month after the 72h notification | A full summary of the event and the response |
The difference between the final report for a vulnerability and for an incident is often lost, because industry notes tend to quote only the 14-day rule. For an incident the final clock is longer. In practice the three clocks mean one thing: your response procedure has to recognise that an event qualifies under the CRA and start the report in hours, not weeks. A day is little time if the decision to report has to escalate through several people who are not in the procedure.
The three CRA clocks start from the moment you become aware of the event.
CRA vs NIS2: two roles, two sets of obligations
The most common misunderstanding goes: since I already report incidents under NIS2, the CRA changes nothing. It does, because the two acts look at the same company in a different role. NIS2 treats you as an entity that uses systems and provides services, and asks about reporting incidents affecting those services, to a CSIRT. The CRA treats you as a manufacturer placing a product on the market, and asks about reporting vulnerabilities and incidents in that product.
The same company can be subject to both, in two different roles, with two separate sets of obligations and two separate clocks. A single incident can start several counters at once: NIS2 toward the CSIRT, the CRA toward the CSIRT and ENISA, and, where personal data is breached, GDPR toward the supervisory authority. The deadlines and the recipients differ, so the incident procedure has to branch rather than assume one report covers everything. We cover the NIS2 obligations for an AI deployment in our guide NIS2 and AI: what applies and how to prepare.
How a report is filed and to whom
The CRA tidies up the reporting channel rather than multiplying windows. A manufacturer reports once, through a single platform, the CRA Single Reporting Platform. The report goes to the competent CSIRT designated as coordinator in the country of the manufacturer's main establishment, and the information is shared with ENISA at the same time. If the product was made available in other countries, the receiving CSIRT shares the report with the other relevant teams without undue delay.
A practical note: the reporting platform is a new element only coming into use for the September deadline. So it is worth settling and testing your own reporting channel in advance, rather than assuming that on the day you can go looking for the right form. Law-firm analyses, including Jones Day and DLA Piper, stress that the hard 24-hour clock requires a ready procedure, not improvisation at the first event.
Reporting capability rests on what should be working anyway: detection and logs. Without telemetry that shows a vulnerability is being exploited, or that a product is behaving abnormally, the 24-hour clock starts too late or not at all. It is the same foundation that serves the logging obligations under NIS2, and the same reason tools working on your data should leave an auditable trail.
What to do before 11 September
Little time is left before the obligation applies, but preparing is not a quarter-long project if you already have the bones of incident response. A sensible order is this.
- Establish whether you are a manufacturer under the CRA, and for which products. Without that map you do not know which events the clock covers.
- Add the CRA to your existing incident procedure as a separate branch with its own deadlines and recipient, not as a variant of the NIS2 report. Define explicitly who decides to report and who has access to the platform, so the day is not spent working out the owner.
- Check whether your detection and logs let you establish that a vulnerability is actively exploited. This is the most common gap: the obligation exists, but the signal that triggers it does not reach the right person in time.
- Run one report as a dry run. A simulation shows where the 24 hours break, before a real incident does.
September is a month of stacked deadlines anyway: a few weeks after CRA reporting starts comes NIS2 registration by 3 October 2026. It is worth laying both out on one schedule rather than handling them separately. If you want to check how your AI deployment stands on data control and an auditable trail, our readiness mini-audit takes 10 minutes and leaves no data behind.
Frequently asked questions
When exactly does CRA reporting start?
From 11 September 2026 for actively exploited vulnerabilities and severe incidents. The full CRA product obligations only start on 11 December 2027.
What are the reporting deadlines?
An early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report within 14 days of a corrective measure being available for a vulnerability, or within a month for a severe incident.
Does the CRA apply to a machine manufacturer?
Yes, if you place a machine on the market under your own name and it has a controller, firmware or a connectivity module, meaning digital elements. Then you are a manufacturer of a product with digital elements and the reporting clock applies to you.
How is this different from NIS2 reporting?
By role. NIS2 sees you as an entity using systems and providing services, the CRA as a manufacturer placing a product on the market. The same company can be subject to both, in two roles, with separate deadlines and recipients.
What do I need ready for 11 September?
A working reporting capability: knowing which products make you a manufacturer, an incident procedure with a separate CRA branch, a designated decision-maker and access to the reporting channel, plus detection and logs that let you notice a qualifying event at all.
This is not legal advice. CRA practice is still forming, and procedural details will be clarified through implementing acts and guidance. The scope of obligations depends on your organization's profile; if in doubt, consult a lawyer or compliance advisor.