I've spent the last few weeks researching the EU Cyber Resilience Act for a side project. The Article 14 reporting duties have applied since 11 September 2026 — to products already on the market, not just new ones. Two kinds of events trigger them: actively exploited vulnerabilities, and severe incidents affecting product security. And each trigger starts not one deadline but three, staged:
Actively exploited vulnerability
- Early warning: within 24 hours of becoming aware
- Detailed notification: within 72 hours
- Final report: within 14 days of a corrective or mitigating measure becoming available
Severe incident
- Early warning: within 24 hours of becoming aware
- Detailed notification: within 72 hours
- Final report: within one month of the 72-hour notification
One submission per stage, filed through ENISA's Single Reporting Platform, reaching both your national CSIRT and ENISA. (At go-live, even the platform had rough edges — early-September reporting noted its public URL still wasn't published days before the deadline. Register and test access now, not during an incident.)
Here's what changes when you read them as three separate deliverables instead of one blurry "reporting duty."
Filing 1: the 24-hour early warning — prove when you knew
The early warning is deliberately thin: product identity, what happened, when you became aware, and what you know so far. Uncertainty is expected — the regulation allows progressive disclosure.
Its real function is timestamping your awareness. The clock starts at awareness, not at full understanding, and "when did you first know?" is the question every later filing will be measured against. A forwarded email in someone's inbox is not an awareness record. A timestamped intake entry — report received, triaged by whom, decision logged — is.
Filing 2: the 72-hour notification — the one that will expose you
This is the hard one. Within 72 hours you must describe the vulnerability or incident in technical substance: affected products and versions, how exploitation works or what the incident did, indicators, and what mitigations exist.
Read that again and notice what's missing: a fix. You will very likely file this before a patch exists — and the regulation knows that. "Corrective measure available" is what starts the final-report clock, not this one. So the 72-hour filing is a snapshot of incomplete forensics: what you can prove, what you're still checking, what customers should do meanwhile.
This is where small vendors get exposed, because the 72-hour filing quietly demands three things most teams don't have ready: (1) a definitive list of affected versions — which requires release-linked SBOMs, not a dependency list from the repo; (2) an exploitation assessment — is the vulnerable code actually reachable in the shipped product; (3) a decision trail — who decided this was reportable, on what evidence, and when.
A scanner finding from last month won't answer any of those. A per-release evidence packet will.
Filing 3: the final report — two different clocks, don't mix them
For vulnerabilities, the final report is due within 14 days of a corrective or mitigating measure becoming available — root cause, remediation, what was done. Note the trigger: the measure being available, not the notification. Ship the fix on day 40 and the 14-day clock starts then.
For severe incidents, it's one month from the 72-hour notification, regardless. Different event, different clock.
Mixing these up is an easy, expensive mistake — and it's exactly the kind of detail that a one-page "report within 24 hours" summary leaves out.
The prep that covers all three
Every filing draws from the same well: a timestamped awareness record, per-release SBOMs tied to shipped artifacts, a decision log, and SRP access registered before you need it. The 24-hour workflow from my earlier post is the engine; filings two and three are its outputs, filed on schedule.
Not legal advice — I'm a software engineer, not a lawyer. This is release hygiene that happens to overlap with what the CRA asks for.
I'm building Waybill to generate the evidence packet behind these filings: SBOM per release, a versioned evidence archive, and vulnerability intake with real deadlines. Founding beta is $29/mo.
The full write-ups behind this post:
- The CRA clock has started
- Your SBOM should be a release artifact, not a compliance screenshot
- The 24-hour CRA reporting clock: build the evidence packet before you need it
- I tried to build a CRA evidence packet for a WordPress plugin release. Here's what was missing.
Question for the vendors here: which of the three filings would break first at your shop — the awareness timestamp, the 72-hour technical snapshot, or the final report?
Top comments (0)