Reading time: about 8 minutes
From 11 September 2026 a manufacturer of a product with digital elements 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 a severe incident. You report once, through a single platform, to the competent CSIRT, and the information reaches ENISA at the same time. This is the first CRA deadline that genuinely takes effect. The act's full product obligations only start on 11 December 2027. If you place on the market a machine with a controller, a device with firmware or software with digital elements, this clock applies to you regardless of whether you fall under NIS2.
This is not legal advice, just a practical way to organise the topic from a manufacturer's point of view. CRA practice is still forming and procedural details will be refined by guidance. When in doubt, consult a cybersecurity lawyer. Below we bring together in one place what starts on 11 September, how the deadlines run, who is covered and what to do before the date.
What exactly starts on 11 September
The CRA, the Cyber Resilience Act, applies in stages. Most product obligations, such as security requirements across the lifecycle, technical documentation and CE marking for digital elements, start on 11 December 2027. But one block starts earlier, and it is the subject of this piece: the reporting obligation, which per the European Commission applies from 11 September 2026.
From that day a manufacturer reports two things. The first is an actively exploited vulnerability in a product with digital elements, meaning one for which there is evidence of real exploitation, not just a theoretical possibility. The second is a severe incident having an impact on the security of the product. Both events trigger the same multi-stage reporting mode with hard deadlines counted in hours.
The distinction matters, because the September deadline does not mean the whole CRA has to be in place from that day. It means you have to be able to detect a qualifying event and report it within the required time. Reporting capability is therefore an obligation that runs more than a year ahead of the rest of the act.
Three clocks: 24h, 72h, 14 days or a month
A report is not one document but a sequence. The counter starts the moment the manufacturer becomes aware of the event. It is easiest to put in a table.
| Stage | Deadline | What it contains |
|---|---|---|
| Early warning | 24 hours | A signal: what is happening, which product, whether it is being exploited |
| Full notification | 72 hours | Nature of the event, assessment so far, corrective measures |
| Final report (vulnerability) | 14 days after fix | Full description and the corrective measure made available |
| Final report (incident) | one month after | Full description, impact and actions taken |
This difference in the final report is often lost, because industry notes tend to quote only the 14-day rule. For a severe incident the closing clock is longer, counted in a month. In practice the three clocks mean one thing: the response procedure has to recognise that an event qualifies under the CRA and start a report in hours, not weeks. A day is little time if the decision to report needs escalation through several people who are not in the procedure.
Who is covered: decision table
The addressee is a manufacturer of a product with digital elements, that is, an entity placing such a product on the market under its own name or mark. It is a broad category: software, but also hardware containing software or a connectivity component. The simplest way to settle your situation is a table.
| Your situation | Does the CRA apply | What to do |
|---|---|---|
| You place a machine with a controller or firmware under your own brand | Yes, you are a manufacturer | Build a reporting capability for 11 September |
| You sell software with digital elements separately | Yes | Bring the product under the same reporting procedure |
| A third-party component sits inside your product | Yes, if the vulnerability is exploitable in your product | Monitor suppliers and their vulnerabilities |
| You only use someone else's AI or IT solution | No, the duty sits with the manufacturer | Cover it in the contract and incident procedure |
| The product is no longer supported but still on the market | The reporting duty continues | Keep the reporting channel despite end of support |
As the Pearl Cohen analysis notes, the reporting duty continues even after a product is no longer supported, and a vulnerability in a third-party component is reported when the vulnerable code is actually exploitable within your product. The word "machine" alone does not settle it, the presence of a digital element and the fact that you place the product on the market does.
The three CRA clocks start the moment the manufacturer becomes aware of the event.
CRA and NIS2: two roles, two sets of duties
The commonest misunderstanding is: if 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. 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 fall under both, in two different roles, with two separate sets of duties and two separate clocks. One incident can start several counters at once: NIS2 to the CSIRT, the CRA to the CSIRT and ENISA, and where personal data is breached, the GDPR to the supervisory authority. So the incident procedure has to branch them rather than assume one report covers everything.
If you are still arranging the NIS2 side, our pieces on NIS2 registration by 3 October 2026 and on what NIS2 means for an AI deployment are useful. The CRA adds a separate, product-level branch to that.
How a report is filed and where it goes
The CRA tidies 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 manufacturer's country of main establishment, and the information is made available to ENISA at the same time. If the product was made available in other countries, the receiving CSIRT shares the report with the other competent teams without undue delay.
The practical conclusion is that 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. This is the same foundation a NIS2 audit requires, and it is why AI tools working on your data should leave a trail you can show. We unpack that in the piece on why public-cloud AI won't pass your audit.
What to do before 11 September
There is little time left before the obligation takes effect, but preparation is not a quarter-long project if you already have the bones of incident response.
- Establish whether you are a manufacturer, and for which products. Without that map you do not know which events the clock covers. It is the first column of every later decision.
- Add the CRA to the incident procedure as a separate branch. With its own deadlines and addressee, not as a variant of a NIS2 report. State plainly who decides to report and who has access to the platform.
- Check detection and logs. Whether they let you establish that a vulnerability is actively exploited at all. This is the commonest gap: the duty exists, but the signal that triggers it does not reach the right person in time.
- Rehearse one report dry. A simulation shows where the 24 hours break before a real incident does it for you.
- Separate the two dates. 11 September 2026 is the start of reporting, not of the whole act. For September you need a working reporting capability, not complete product compliance, which is due 11 December 2027.
If you want to check where your AI architecture lacks the trail needed to detect and report, our readiness mini-audit takes 10 minutes and leaves no data behind.
Frequently asked questions
From exactly when do the CRA reporting duties apply?
From 11 September 2026 for actively exploited vulnerabilities and severe incidents. The CRA's full product obligations 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 for a vulnerability, or within a month for a severe incident.
Where is a report filed?
Once, through the CRA Single Reporting Platform. It goes to the competent CSIRT in the manufacturer's country of main establishment, and the information is made available to ENISA at the same time, which shares it with other countries' CSIRTs.
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 fall under both, in two roles, with separate deadlines and addressees.
What must I have ready by 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 platform access, and detection and logs that let you notice a qualifying event.
Fryderyk, CortexMine. We write about private AI for NIS2-covered manufacturers, based on our own deployments and tests.
This is not legal advice. The scope of obligations depends on your product and organisation, if in doubt consult a cybersecurity lawyer.
Prefer to talk it through? Book a 30-minute call with the founder, no pitch, just your case.