Three CRA deadlines, one workflow: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure becomes available — not 14 days from awareness. Getting that distinction right is what most CRA coverage misreports.
On September 11, the clock starts running for real. Learn on September 12 that a CVE in your product is being actively exploited, and Article 14 of the EU Cyber Resilience Act gives you 24 hours to send an early warning to your national CSIRT. Not 24 hours to investigate or patch. Twenty-four hours to say: this is happening, here's roughly where.
This is the runbook for that day, written before it arrives. Need the case for why September 11 matters first? Read the CRA reporting pillar. This piece assumes you already believe the deadline is real and just wants the playbook for when the pager goes off.
Scope note before the checklist: this runbook covers the actively-exploited-vulnerability track only. Severe incidents under Article 14(4) follow the same 24/72-hour rhythm, but their final report is due within one month of the notification, a different clock. Don't let "three deadlines" collapse into one shape covering both tracks. It doesn't.
This 24-hour clock is also not the CRA's only deadline. It's the narrow, near-term reporting duty — the regulation's much larger obligation, mandatory CE marking and the full essential cybersecurity requirements, lands December 11, 2027. See what changes then so September doesn't crowd out planning for the bigger date.
Accuracy note: every date, deadline, and penalty figure below is cross-checked against the regulation's Article 14 and Article 64 text as published on EUR-Lex — Regulation (EU) 2024/2847 — not secondary summaries alone. If you're making a filing decision from this article, verify against the current regulation text for your specific situation — this is not legal advice.
What We'll Cover
- The three clocks, and when each starts
- Before September 11: the pre-flight checklist
- The early-warning template
- Hour-by-hour: a worked scenario
- Three mistakes that will cost you
- FAQ
The Three Clocks, and When Each Starts
Article 14 gives you three deadlines, and they don't all start from the same moment.
| Stage | Deadline | Starts when | What lands there |
|---|---|---|---|
| Early warning | 24 hours | You become aware of active exploitation | Confirmation that this is an actively exploited vulnerability, plus, where applicable, the Member States you know the product reaches |
| Notification | 72 hours | Same awareness moment | The fuller account: general product information, the general nature of the exploit and vulnerability, and any corrective or mitigating steps already taken |
| Final report | 14 days | A corrective or mitigating measure becomes available | Severity and impact, whether exploitation looks malicious, and the fix you shipped |
Read that last row twice. The 14-day clock doesn't start when you notice the vulnerability, and it doesn't start when you file the 72-hour notification. It starts when you have something to ship. A fix that takes six weeks to build makes the final report six weeks plus 14 days out, not 14 days from the incident. That's not a loophole; it's the mechanism, and getting it backwards is the single most common error in CRA coverage. Once the fix ships, ordinary remediation takes over — see our vulnerability remediation workflow guide for how that connects to the 14-day clock.
Here's the same three-clock timeline laid out visually, so the "starts when" column above is easier to hold in your head during an actual incident:
CycloneDX or SPDX inventory produced at build/scan time
Initial notification to the CSIRT/ENISA of an actively exploited vulnerability
Detailed vulnerability report — impact, severity, available fixes
Complete report with root cause, remediation, and corrective actions
An up-to-date SBOM is what makes the 24-hour deadline achievable — you cannot report impact on components you have not already inventoried.
Filing itself is one submission: to the CSIRT coordinating your Member State of main establishment, simultaneously accessible to ENISA, through the Single Reporting Platform under Article 16. That CSIRT forwards it to the other Member States where your product is marketed, so you aren't filing per country.
Update since publication: ENISA switched on the Single Reporting Platform on September 11, 2026, the same day the reporting obligation itself took effect. If you haven't registered yet, do it now — see ENISA's official Single Reporting Platform page for account setup, rather than finding out during an actual incident whether your access works.
Before September 11: The Pre-Flight Checklist
Everything here is boring in August and expensive in September if you skip it.
- A current SBOM you can produce in under an hour. CI-wired, not a Q1 export. See our SBOM Requirements 2026 Checklist. Done: one command gets an accurate dependency list for your last shipped release.
- A monitored CISA KEV feed cross-referenced against that SBOM. Our KEV explainer covers why KEV status is the closest practical proxy for "actively exploited" that the reporting obligation is built around. Done: a KEV addition matching a shipped dependency reaches a human inside an hour, not next week's review.
- A named owner and a backup, with an out-of-hours contact. Done: you can answer "who files this at 11 p.m. on a Saturday" without a Slack thread.
- A pre-drafted early-warning template. See the next section. Build it now, not mid-incident.
- A decision record for what counts as "actively exploited" in your product. Done: your team has agreed, in writing, whether a KEV listing alone is enough, or you need direct confirmation against your own deployment, before you're debating it with 22 hours left.
The Early-Warning Template
Build this from the statute, not a template you found online: most public CRA templates over-specify the 24-hour stage, whose actual requirement is strikingly small. Article 14(2)(a) asks for confirmation that this is an early warning of an actively exploited vulnerability, and, where applicable, the Member States where you know the product has been made available. That's the whole ask. Manufacturer identity and a contact point are platform-collection fields, not Article 14 mandates at hour 24.
Everything most templates demand up front — a CVE ID, precise affected versions, root cause, severity, attribution — is legitimately allowed to read "under investigation" at 24 hours. It's first required at 72 hours, under Article 14(2)(b).
EARLY WARNING — [Product name] — [date/time of awareness]
Status: Early warning of an actively exploited vulnerability
Awareness timestamp: [ISO 8601 — when your team first confirmed exploitation]
Product with digital elements: [product + version(s), or "under investigation"]
Member States of availability: [where applicable — list, or "not yet determined"]
CVE / identifier: [if assigned, otherwise "unassigned — tracking internally as INC-####"]
Nature of exploitation: [one line; "under investigation" is an acceptable answer]
Filed by: [name, role, contact — a platform-level field, not an Article 14 mandate]
At 72 hours, this same document grows: general product information, the general nature of the exploit and vulnerability, and any corrective or mitigating measures you've taken since. No Commission implementing act or official field template had been published as of this writing. If one exists by the time you're reading this, use it; it supersedes this reconstruction.
Hour-by-Hour: A Worked Scenario
09:14: your monitored KEV feed flags a CVE matching a package in your SBOM.
Hour 1: confirm the match is real. Is the vulnerable package in a shipped artifact, or only in devDependencies and never leaving CI? Most false starts happen right here.
Hour 4: scope it. Which product versions ship the vulnerable code path, and is it even reachable, or dead code behind a flag nobody enabled?
Hour 12: draft. Fill in what you know, mark what you don't, and get the on-call owner and backup reading the same document.
Hour 22: file, with a two-hour buffer, since platform hiccups and sign-off both eat real time, and "we missed it by eleven minutes" isn't a defense Article 64 recognizes.
Three Mistakes That Will Cost You
- Filing late because nobody owned it. A 24-hour clock with no named owner quietly becomes a 30-hour clock once three people forward the Slack message instead of acting on it.
- Filing an early warning for a CVE that never shipped. A package sitting only in
devDependenciesisn't a product vulnerability under Article 14; confirm reachability before you start the clock in your head. - Treating the 24-hour warning like it needs 14-day-report completeness. "Under investigation" is a legitimate answer at hour 22. Waiting for a CVE number, root cause, and shipped fix before filing is exactly how a 24-hour deadline turns into a missed one.
FAQ
What if we're not sure it's actively exploited?
The 24-hour clock starts when you become aware, and "aware" does real work in that sentence. A rumor isn't awareness; a KEV catalog addition matching your shipped code, or a direct report of exploitation in the wild, generally is. If you're genuinely uncertain, file the early warning anyway and mark exploitation status as under confirmation. That's exactly what the early-warning stage is for.
Does this apply to open-source maintainers?
Three distinct positions, not one "open source is exempt" bucket. Someone maintaining free and open-source software outside any commercial activity sits outside the CRA entirely: the regulation reaches products made available "in the course of a commercial activity" (Article 3(22)), and Recital 18 treats FOSS "not monetised by their manufacturers" as falling outside that activity, so there's no manufacturer status and nothing to be exempt from. An "open-source software steward" under Article 24, typically a foundation sustaining a FOSS product intended for commercial use, is a different case: fully in scope, carrying the same reporting duty as any manufacturer, exempt only from administrative fines under Article 64. A company shipping that same code inside its own commercial product is a manufacturer under Article 3, full stop, with neither carve-out.
What if the vulnerability is in a transitive dependency we don't control?
The reporting duty attaches to your product, not whoever wrote the vulnerable line. Ship it three layers deep in a dependency tree and the clock starts the same way, which is exactly why the pre-flight SBOM matters. Transitive dependencies are where "we didn't know we shipped that" lives.
What happens if we miss the 24-hour window?
You still file, and you're now explaining a missed statutory deadline instead of meeting one. Article 14 violations sit in the CRA's top penalty tier under Article 64: up to EUR 15,000,000 or 2.5% of worldwide annual turnover, whichever is higher, the same exposure as an essential-requirements violation. The microenterprise/small-enterprise carve-out is narrower than it sounds: it covers only the 24-hour early-warning deadline, not the 72-hour notification or the final report.
Get Ready Before September 11
Most CRA content is written for the person deciding whether the regulation applies to them. Almost none is written for the engineer who gets paged at 09:14 with 24 hours on the clock. This is for that person.
The obligation itself isn't hard. It's fast. Everything that makes it survivable — the SBOM, the KEV monitoring, the named owner, the template — is work you do this week, not on September 12.
Read the full CRA reporting pillar for the background, and pair your SBOM with GeekWala's dependency scanning so the KEV match happens automatically instead of during next month's audit.
