CRA from 11 September 2026: 24-hour vulnerability reporting, who reports and how

Reading time: about 8 minutes

Table of contents

1. What exactly starts to apply on 11 September
2. Three clocks: 24 h, 72 h, 14 days or a month
3. Who is covered by the obligation
4. CRA vs NIS2: two roles, two sets of obligations
5. How a report is filed and who receives it
6. What to do before 11 September
7. A common mistake: confusing the reporting clock with the full CRA
8. FAQ

Answer first

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 becoming available for a vulnerability, or within a month for an incident. You report once, through a single channel (the CRA Single Reporting Platform), to the relevant CSIRT, and the information reaches ENISA at the same time. This is the first CRA deadline that actually takes effect. The full product obligations of the act only apply from 11 December 2027. If you place hardware or software with digital elements on the market, this clock applies to you regardless of whether you fall under NIS2.

What exactly starts to apply on 11 September

The CRA, the Cyber Resilience Act, comes into force in stages. Most product obligations, such as security requirements across the lifecycle, technical documentation, or CE marking for digital elements, start to apply on 11 December 2027. But one block starts earlier, and it is the subject of this note: the reporting obligation.

From 11 September 2026 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 genuinely exploiting it, not merely a theoretical possibility. The second is a severe incident affecting the security of the product. Both events trigger the same multi-stage reporting flow with hard deadlines measured in hours.

The distinction matters, because the September deadline does not mean the entire CRA has to be in place from that day. It means that from that day you must be able to detect a qualifying event and report it in the required time. Reporting capability is therefore an obligation that precedes the rest of the act by more than a year.

Three clocks: 24 h, 72 h, 14 days or a month

A report is not a single document but a sequence. The counter starts the moment the manufacturer becomes aware of the event.

Early warning: 24 hours. Within one day of becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer files an initial notification. At this stage it is not about a full analysis, but about a signal: what is happening, which product it concerns, whether the event is being exploited.

Full notification: 72 hours. Within three days of becoming aware, the manufacturer supplements the report with substance: the nature of the vulnerability or incident, the assessment so far, and the corrective measures taken and planned.

Final report: 14 days or a month. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective measure, a patch or a workaround, becomes available. For a severe incident the deadline is different: a final report within a month of the 72-hour notification. This difference is often lost, because industry notes tend to quote only the 14-day rule. For an incident the final clock runs longer.

In practice the three clocks mean one thing: the response procedure has to recognise that an event qualifies under the CRA and trigger a report in hours, not weeks. A day is not much time if the decision to report requires escalation through several people who are not named in the procedure.

Who is covered by the obligation

The addressee is the manufacturer of a product with digital elements, that is, 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 component. A maker of a machine with a controller, a device with firmware, a component with a network module, or an application sold separately, all fall within this definition.

For companies deploying AI this matters from two sides. If you yourself build a product with a model or software inside it, you are a manufacturer within the meaning of the CRA. If you only use someone else's solution, the CRA reporting obligation sits with its manufacturer, but your contract and your supply chain should reflect that, because an incident at a supplier can start your own clocks under other regimes.

CRA vs NIS2: two roles, two sets of obligations

The most common misconception 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 the 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 fall under 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 towards the CSIRT, the CRA towards the CSIRT and ENISA, and, where personal data is breached, also the GDPR towards the supervisory authority. Deadlines and addressees differ, so the incident procedure has to branch rather than assume that one report settles everything. We lay this logic out more fully in the cross-mapping of NIS2, AI Act, GDPR and ISO 27001, where the CRA is the fifth column of the same matrix.

How a report is filed and who receives it

The CRA tidies up the reporting channel rather than multiplying windows. The manufacturer reports once, through a single channel, the CRA Single Reporting Platform. The report goes to the relevant CSIRT, designated as coordinator in the member state where the manufacturer has its main establishment, and the information is made available to ENISA at the same time. If the product was made available in other member states, the receiving CSIRT shares the notification without undue delay with the other relevant teams.

The practical takeaway is that reporting capability rests on what should be working anyway: on detection and on logs. Without telemetry showing that a vulnerability is being exploited, or that the product is behaving abnormally, the 24-hour clock starts too late or not at all. This is the same foundation that supports the logging obligations of NIS2 and ISO. What exactly to record in an AI system running locally we break down in the note on observability for on-prem LLMs.

What to do before 11 September

Little time remains before the obligation applies, and preparation is not a quarter-long project if you already have the bones of incident response. A sensible order is as follows.

First, establish whether you are a manufacturer within the meaning of the CRA and for which products. Without that map you do not know which events the clock covers.

Second, write the CRA into your existing incident procedure as a separate branch with its own deadlines and addressee, not as a variant of the NIS2 report. State explicitly who decides to report and who has access to the platform, so the day is not lost working out who owns it.

Third, check whether your detection and logs even let you establish that a vulnerability is being 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.

Fourth, run one report as a dry run. A simulation shows where the 24 hours break before a real incident does it for you. For more on the evidence and documents worth having ready for an auditor and a regulator, see audit readiness for NIS2 plus AI.

A common mistake: confusing the reporting clock with the full CRA

It is worth separating two dates, because mixing them leads either to panic or to complacency. 11 September 2026 is the start of the reporting obligation, not of the whole act. 11 December 2027 is the start of the full product obligations, including security requirements, technical documentation, and conformity assessment.

Complacency looks like this: since the full CRA is more than a year away, one can wait. One cannot, because the reporting clock runs from September and does not wait for the rest of the act. Panic looks the opposite: since the CRA starts in September, everything has to be buttoned up by that day. It does not, because the product obligations have their own, later deadline. For September you need a working reporting capability, not full product conformity.

FAQ

From when exactly does CRA reporting apply? From 11 September 2026 for actively exploited vulnerabilities and severe incidents. The full product obligations of the CRA start to apply 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 becoming available for a vulnerability, or within a month for a severe incident.

Who is the report filed with? Once, through the CRA Single Reporting Platform. The report goes to the relevant CSIRT in the manufacturer's main establishment, and the information is made available to ENISA at the same time.

How does this differ from reporting under NIS2? 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.

Does it apply to me if I only use someone else's AI rather than making a product? The CRA reporting obligation sits with the manufacturer of the product with digital elements. If you are purely a user of someone else's solution, this particular clock does not start for you, but an incident at your supplier can trigger your obligations under other regimes, so the contract and procedure should cover it.

What must I have ready by 11 September? A working reporting capability: knowing which products make you a manufacturer, an incident procedure with a dedicated CRA branch, a named decision-maker and access to the platform, plus detection and logs that let you notice a qualifying event at all.

What this note does not cover

I do not discuss the full CRA product obligations that apply from 11 December 2027, as that is material for a separate text. I do not go into the thresholds and definitions of a severe incident in detail, nor into the operational layer of the reporting platform itself. I leave aside sectoral regimes that impose their own clocks, such as DORA for the financial chain. Nor do I map the CRA controls onto the other acts, as we keep that in a separate compliance matrix.

// disclosure & biasesDisclosure and biases

I write from the perspective of someone working on AI deployments run outside the public cloud, so I naturally emphasise control over data flows, detection, and the ability to audit dependencies. I have tried to separate the content of the rules from that architectural preference. This text is not legal advice. Practice under the CRA is still taking shape, and procedural details, including how the reporting platform works, will be clarified by implementing acts and guidance. Before making compliance decisions, consult a lawyer specialising in cybersecurity.

Next step

If you want to see how the CRA meshes with NIS2, the AI Act, the GDPR and ISO 27001 without doing the same work five times, read Cross-mapping NIS2, AI Act, GDPR, ISO 27001 without duplication, where the CRA enters as the fifth regime of the same matrix.

Related

• Cross-mapping NIS2, AI Act, GDPR and ISO 27001 without duplication
• Article 50 of the AI Act from 2 August 2026: what applies when you run your own LLM
• Audit readiness NIS2 plus AI: 7 documents you produce before the auditor
• Monitoring and observability for on-prem LLMs: what to log and how
• NIS2 plus AI: mapping Article 21 to concrete controls, one cheat sheet

Sources

• European Commission, CRA reporting obligations, confirms the 24 h, 72 h, 14-day and one-month deadlines and the reporting channel to the CSIRT and ENISA.
• Jones Day, EU Cyber Resilience Act: 24-Hour Reporting Duties Start September 11, 2026.
• Crowell & Moring, September 11, 2026 Reporting Deadline.
• DLA Piper, The CRA's 24-Hour Rule.

Fryderyk Pryjma. Works on on-prem AI deployments for European manufacturing and writes at the intersection of architecture, compliance and regulation.