The CRA's 24-Hour Clock Started on 11 September
Quick answer: Since 11 September 2026, manufacturers of products with digital elements sold into the EU must report actively exploited vulnerabilities and severe incidents through the CRA Single Reporting Platform: early warning within 24 hours of becoming aware, full notification within 72 hours, final report within 14 days of a fix being available. Open-source software stewards are not covered until 11 December 2027. The obligation is a notification process, and having a good patching process is not the same thing.
Most engineering teams shipping software into Europe can tell you how fast they patch. Very few can tell you who files the 24-hour notice, to which national body, from which account, at 2am on a Sunday.
That second question became a legal one nine days ago. The Cyber Resilience Act's reporting obligations started applying on 11 September 2026, and the platform they run through went live the same day.
What started, and what did not
The European Commission's page on CRA reporting obligations puts it plainly: as of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements.
Two things did not start. The CRA's broader product requirements — secure-by-design obligations, conformity assessment, technical documentation, CE marking — are on a later date. And open-source software stewards are not in scope for reporting until 11 December 2027, a fifteen-month grace the Commission granted deliberately.
So the thing that is live is narrow and procedural. It is also the thing most likely to be missed, because it does not show up in a security review. It shows up when something is already on fire and nobody knows who has the login.
Three clocks, not one
The obligation is staged, and the stages have different content requirements.
| Stage | Deadline | Clock starts at |
|---|---|---|
| Early warning | 24 hours | Becoming aware |
| Notification | 72 hours | Becoming aware |
| Final report (exploited vulnerability) | 14 days | Corrective measure available |
| Final report (severe incident) | 1 month | The 72-hour notification |
Read the third row carefully, because it is the one that behaves differently from every other disclosure regime engineers have internalised. The 14-day final report is not counted from discovery. It is counted from the moment a corrective measure becomes available. Ship the fix, and you have started a second clock.
Reports go through the CRA Single Reporting Platform, which the Commission states became operational on 11 September 2026. The notification reaches the Computer Security Incident Response Team where you have your main establishment and is simultaneously made available to ENISA, barring exceptional circumstances; that first CSIRT then shares it onward with other relevant CSIRTs. You file once, into one place, and the distribution is handled for you.
"Actively exploited" is narrower than it sounds
The trigger is not "a CVE was filed against a dependency". It is a vulnerability in your product that is actively exploited, or a severe incident impacting the security of your product. A high-severity advisory in a transitive dependency with no evidence of exploitation against your users is a patching task, not a 24-hour filing.
That distinction sounds comfortable until you try to make it under time pressure with partial telemetry. "Are we seeing exploitation?" is an evidence question, and the honest answer at hour three is often "we don't know yet". You need to decide in advance who is allowed to answer it and what the default is when they cannot — because the clock runs from awareness, and awareness is not a thing you get to define later.
Most of the practical work here is detection and provenance: knowing what you shipped, to whom, built from which inputs. That is the same investment that makes a dependency compromise survivable, and it is why hardening the release path — signed provenance, short-lived credentials, publishing without long-lived tokens — pays twice.
Where open source actually sits
This is the part that generates the most noise and the most incorrect summaries, so here is what the Commission's open source guidance says.
An open-source software steward is a legal person that provides sustained support for the development of free and open-source products with digital elements intended for commercial activities, and plays a main role in ensuring their viability. In practice: foundations and similar bodies, not individuals.
Stewards get a lighter regime than manufacturers. They must have a cybersecurity policy that supports secure development and vulnerability handling, cooperate with market surveillance authorities, and report actively exploited vulnerabilities and severe incidents — from December 2027. They cannot be hit with administrative fines.
Two exclusions matter. Free and open-source software that is not monetised by its manufacturers is not treated as a commercial activity. And individual developers contributing source code to projects that are not under their responsibility are outside the scope entirely. Maintaining a popular library in your spare time does not make you a regulated entity.
The trap is the other direction. If you take an open-source project, wrap it, and sell it as a product in the EU, you are the manufacturer of that product. The upstream licence does not transfer the obligation upstream, and the 11 September date applies to you now, not in 2027.
What to have in place before the first one lands
This is a small amount of work done calmly, or a large amount done badly at 2am.
Name your CSIRT. Determine which member state hosts your main establishment and write the specific national CSIRT into the runbook. Not "the relevant authority" — the name, the portal, the contact route.
Get accounts on the Single Reporting Platform before you need one. Credential provisioning is the most predictable way to burn six of your twenty-four hours. Two people minimum, in different time zones if you have them.
Define "aware" in writing. Pick the trigger: a confirmed exploitation signal, a credible third-party report, a customer incident meeting stated criteria. Then log the timestamp when it fires. If you ever have to defend the timeline, the log is the defence.
Separate the notification path from the fix path. The engineer holding the pager should not also be drafting a regulatory filing. One person patches, one person files, and they are not the same person.
Rehearse it once. Tabletop the 24-hour path on a fictional exploited vulnerability. The exercise is cheap and reliably finds the missing login. The tooling that supports the detection half of this lives in the security and privacy and cloud and DevOps categories; if you are choosing between options there, our note on comparing developer tools without reading forty landing pages will save you a week.
FAQ
Who has to report under the CRA right now?
Manufacturers of products with digital elements, since 11 September 2026. Open-source software stewards are not required to report until 11 December 2027.
What are the exact deadlines?
An early warning within 24 hours of becoming aware, a full notification within 72 hours, a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability, and within one month of the 72-hour notification for a severe incident.
Where do the reports go?
Through the CRA Single Reporting Platform, operational since 11 September 2026. The report reaches the CSIRT of your main establishment and is made available to ENISA at the same time, except in exceptional circumstances; that CSIRT then shares it with other relevant CSIRTs.
Does every CVE in my dependency tree trigger a report?
No. The trigger is an actively exploited vulnerability in your product, or a severe incident affecting its security. A published advisory with no exploitation against your product is a patching obligation, not a notification one.
I maintain an open-source library. Am I regulated?
Almost certainly not. The Commission states that free and open-source software not monetised by its manufacturers is not a commercial activity, and that individual contributors to projects not under their responsibility are out of scope. Stewardship obligations attach to legal persons sustaining projects intended for commercial activities.
What happens if we miss the 24 hours?
Enforcement sits with national market surveillance authorities and the penalty framework is set out in the regulation itself. Stewards are explicitly exempt from administrative fines; manufacturers are not. Take the specifics to counsel rather than to a blog post — including this one.
This is a summary of published guidance, not legal advice. Verify your own scope against the regulation before relying on any of it — and browse the developer tools directory for the monitoring and inventory tooling the process depends on.