Three clocks. One start line.
Article 14 gives you an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days of a corrective measure becoming available (one month for a severe incident), and all three run from the moment you become aware, not the moment anything is confirmed.
No tool makes you compliant, and this isn’t legal advice. What follows is what each clock actually requires you to submit.
Not sure a given product is even in scope? Run the scope check first, it’s free and takes a minute.
The clock starts at awareness, not confirmation.
The first two clocks (the 24-hour early warning and the 72-hour notification) both count from the same moment: when you become aware that a component in a product you’ve placed on the EU market is being actively exploited, or that a severe incident has affected its security. Not when the vulnerability was disclosed, not when your team finished investigating, and not when you’ve decided how serious it is. Awareness is the trigger.
That’s why the useful question isn’t “how bad is this”: it’s “do we have a timestamped record of the moment this reached us?” Without one, the 24-hour window is already running before you know it started.
What triggers each clock, and what you submit.
All three go through the same route: ENISA’s Single Reporting Platform. There’s no API for it, so a human files each one.
Early warning. Due within 24 hours.
You become aware that a component in a product with digital elements you’ve placed on the EU market is being actively exploited, or that a severe incident has affected the product’s security. Awareness starts the clock: not confirmation, not a fix, not a decision that it’s serious.
A short first notice: that you’re aware of a reportable finding, whether it’s active exploitation or a severe incident, and enough to identify the product affected. It isn’t an analysis: it’s a flag raised in time.
OSPulse names the package, the advisory and the affected releases the moment a dependency enters CISA KEV or a matching exploit signal lands, and timestamps that moment as the awareness record the early warning is built from.
Notification. Due within 72 hours.
The same clock as the early warning, run further: 72 hours from the same moment of awareness, not 72 hours after the early warning was filed.
A fuller account: the general information available about the finding, an assessment of its severity and impact, and, where applicable, the corrective or mitigating measures taken. More detail than the early warning, still not the final word.
OSPulse pre-fills the notification payload in the Single Reporting Platform’s own field order from the finding, the affected product and release, and your manufacturer details, so the fuller account is a review, not a rewrite.
Final report. Due within 14 days.
A corrective measure becoming available: a patch, a mitigation, a fix you can point to. For an actively exploited vulnerability, the final report is due within 14 days of that measure. For a severe incident, it’s due within one month of the 72-hour notification.
The complete picture: a detailed description of the vulnerability or incident, its severity and impact, and the corrective or mitigating measure taken or planned. This is the report that closes the finding out.
OSPulse assembles the final-report payload the same way, pre-filled from the finding record, the release it landed in and the remediation you shipped, with the full evidential trail from the original awareness timestamp through to closure attached.
One platform, no API, a human at every stage.
All three reports go through ENISA’s Single Reporting Platform. ENISA provides no API for it, so submission is manual at every stage: the early warning, the notification and the final report are each reviewed and filed by a person, not posted automatically by any tool, ours included.
What changes with OSPulse is what lands in front of that person: a pack pre-filled in the platform’s own field order from the actual finding, the affected product and release, and your manufacturer details, so the 24-hour window is spent reviewing, not drafting. See how the pack gets built.
Frequently asked
What exactly starts the clock: the exploit, or when I find out about it?
Awareness. The 24-hour, 72-hour and 14-day clocks all run from the moment you become aware that a component in a shipped product is being actively exploited, or that a severe incident has occurred, not from when the vulnerability was first introduced, first published, or confirmed. That’s why a timestamped record of when a signal reached you matters as much as the finding itself.
Do all three deadlines apply to every finding?
The 24-hour early warning and 72-hour notification apply to the same reportable finding: an actively exploited vulnerability or a severe incident. The 14-day final report is triggered separately, by a corrective measure becoming available for that finding (or within one month of the 72-hour notification if the underlying event was a severe incident), so it can land well after the first two.
Do I have to report every vulnerability we find?
No. The Article 14 duty covers actively exploited vulnerabilities and severe incidents affecting product security, not every CVE that turns up in a scan. Separating the two is exactly what a classification step is for.
How do I actually submit these?
Through ENISA’s Single Reporting Platform. There’s no API for it, so submission is manual: a human reviews and files each stage. That’s the reason a pre-filled, submission-ready pack matters: the work left is reviewing and filing, not drafting from a blank form against a countdown.
Does OSPulse file these reports for us?
No, and nobody else can either, since ENISA provides no API. OSPulse produces a submission-ready pack for each of the three stages, built from the finding, the awareness record, and your product and manufacturer details. Your team files it. This isn’t legal advice, and no tool discharges the reporting obligation.
Know your clocks before one starts.
Evidence and speed at every stage, not a claim that a tool discharges the obligation.