EU Cyber Resilience Act · Article 14
An exploited vulnerability was just reported to you. What happens in the next 24 hours.
Reporting obligations under Regulation (EU) 2024/2847 apply from . The rest of the regulation follows on . This page is the clock, not an explainer — what is owed, to whom, and by when.
- Reporting from
- Full application
- Dated record
Hour 0
What starts the clock
The trigger is not "we found a bug". Article 14 runs on two things, and they are different events with different duties: an actively exploited vulnerability in your product, and a severe incident affecting its security. Discovering a vulnerability that nobody is exploiting does not start this clock — it puts you in the vulnerability-handling duties instead, which have no 24-hour hand on them.
The regulation defines all three separately, and only one of them starts this clock: a vulnerability, an exploitable vulnerability — one with the potential to be used by an adversary — and an actively exploited vulnerability, which requires reliable evidence that a malicious actor has exploited it in a system without the owner's permission. The first two do not.
So the first question after a report lands is evidentiary, not legal: is it being exploited, and how do you know? The answer decides whether you are on a 24-hour clock, and you will have to state it in writing. The clock then runs from when you became aware, not from when the exploitation began.
Hour 0–24
The early warning
Early warning notification to the CSIRT designated as coordinator and to ENISA.
Two recipients, not one, and simultaneously. It goes to the CSIRT designated as coordinator for the member state of your main establishment and is simultaneously accessible to ENISA, through the single reporting platform that Article 16 requires ENISA to establish. That platform is not live yet — it is due to be operational for the date the duty starts, so it is not something you can onboard to in advance today.
This is an early warning, and the word is doing work: it is not expected to be complete. It says that something is happening and, where you can, whether the exploitation is believed to be malicious. What it cannot do is wait for your investigation to finish.
Hour 24–72
The full notification
Main notification, adding general information on the vulnerability or incident and any corrective or mitigating measures taken.
What has to be true by now that was not true at hour zero: you have to be able to describe the vulnerability or incident in general terms, and to say what corrective or mitigating measures you have taken. At hour zero you were allowed to know almost nothing. By hour 72 you are expected to have looked.
Day 14 / one month
The final report — 14 days, or one month
Final report on an actively exploited vulnerability (Art. 14(2)(c)) - due 14 days after a corrective or mitigating measure is available, not 14 days after awareness.
Final report on a severe incident (Art. 14(4)(c)) - due one month after the 72-hour incident notification was submitted, NOT after a measure becomes available.
Note what each deadline is anchored to, because they are anchored to different events and neither is the day you were told. The 14-day clock for an exploited vulnerability runs from when a corrective or mitigating measure is available — the clock is on the fix. The one-month clock for a severe incident runs from when you submitted the 72-hour notification, and it does not wait for a fix at all.
And "after a fix" is where a robot policy stops resembling firmware. A firmware CVE has a patch and a version number, and the final report can point at both. A learned policy has neither. When the exploited component is the policy itself, "we fixed it" means you retrained, re-tuned, or swapped a checkpoint — and the report has to describe what changed and how you know it is better.
Ongoing
Products already on the EU market are in scope
This is the clause most often missed, so it is stated plainly. The regulation splits in two. Its product requirements bite only on products placed on the market from , or on earlier products substantially modified after it. But Article 14 reporting is an express derogation from that: it applies to every in-scope product placed on the market before that date, regardless of when it shipped and regardless of whether it was ever modified.
So a product can be out of scope for the requirements and in scope for reporting at the same time. For that installed base the duty is to notify — the CRA does not oblige you to retrofit a fix to it — but the duty to inform affected users still applies.
The planning consequence is that the fleet you have to be able to report on is the fleet you have already shipped — including checkpoints you no longer train, on hardware you no longer sell.
What to have in place before
None of this is required of you today, and none of it is a purchase. It is the short list of things that are ordinary to arrange this month and very hard to arrange inside a 24-hour window — which is the whole reason to do it while it is still optional. A team that can answer these four questions on the day has met the hard part of the clock; a team that cannot will spend the first of its 24 hours finding out who to ask.
Who is on call, and what are they allowed to decide?
The 24-hour clock starts on awareness, not on triage, and it does not pause for a weekend. Name a person and a deputy, give them a route that does not depend on one inbox, and — the part that is usually missed — write down that they may file the early warning without sign-off. The early warning is allowed to say almost nothing; waiting for someone senior enough to approve a complete story is how the first deadline is missed while everyone behaves reasonably.
What evidence do they have to hand?
At hour 24 you need to name the product, say what is exploited and state what you are doing. Those answers live in artifacts, not in memory: which checkpoint is deployed where, what it was last tested against, and what the result was. If the exploited component is a learned policy, the last measured behaviour of that policy is the closest thing you have to a version number — and it is worth nothing if it has to be produced from scratch on the day.
Where does the SBOM live, and is it the deployed one?
One retrievable location, addressable by someone who is not you, covering what is running rather than what was released. For a robot that means the model artifacts too — the checkpoint, its provenance and its dependencies — not only the firmware and the OS packages. An SBOM that has to be regenerated before it can be sent is not available at hour 24.
How does a decision get recorded?
Two of them, specifically: when you became aware, and why you concluded this was or was not reportable. Both are contemporaneous or they are reconstruction. The second matters more than it looks: deciding not to report is a legitimate answer, and the only thing that distinguishes a considered judgement from an oversight afterwards is that somebody wrote down the reasoning at the time.
Three of these four cost nothing but an afternoon and a written page. The one that has a lead time is the second — evidence about a deployed policy exists on the day only if something produced it earlier — which is the argument for measuring on a cadence rather than on demand, and the honest reason this page sits on this site. Continuous assurance is that cadence; a single Checkpoint Report is the cheapest way to find out what one of these measurements even looks like.
“What evidence do you have that the policy was tested?”
This is the question the final report has to survive, and it is the reason this page exists on this site rather than on a law firm's.
A firmware CVE closes with a patch and a version number. A learned policy offers neither: there is no diff to read, and "we retrained it" is not evidence that anything improved. The only honest answer to how do you know it is better is a measurement — the same suite, the same seeds, and a benign control arm, run before and after the change, so the difference is attributable to the change rather than to the weather.
The control arm is the part that is easy to skip and expensive to skip. Without it you cannot distinguish a policy that got safer from a predicate that got quieter, and a regulator reading a before-and-after with no control is reading two numbers with nothing between them.
- How a result is verified — what a Provael run measures, and the confidence interval it carries.
- A sample evidence pack — the artifacts a before-and-after actually produces, in the formats an assessor ingests.
- Continuous assurance — re-running the measurement on every checkpoint, so the "after" exists before you need it.
Provael is a measurement tool. A red-team result is evidence you can file; it is not a vulnerability-handling process, and it does not start, satisfy or discharge the Article 14 clock. A policy-attack result is not a vulnerability-handling process, and Article 14 is about the process. Article 14 obliges the manufacturer to NOTIFY actively exploited vulnerabilities and severe incidents to ENISA and the coordinating CSIRT on a fixed clock (24h / 72h / 14 days); a Provael run produces neither that process nor those notifications, and cannot start, satisfy or evidence that clock. CRA compliance remains a product-level obligation on the responsible economic operator.
Not legal advice. Every date on this page is published as a dated, source-linked record at /regulatory-clock, verified against Regulation (EU) 2024/2847 on EUR-Lex and the Commission CRA summary. Verify against the primary source before relying on it.