A report of a possible exploit rarely arrives in the shape of a finished incident. It might be a support ticket, a message from a researcher, a note from a customer, or a journalist asking a question that has not yet been answered. The operational question is what happens in the interval between that signal arriving and the point at which the company can say, with evidence, that the vulnerability is being actively exploited.
Since 11 September 2026, manufacturers of products with digital elements covered by the EU Cyber Resilience Act have had a reporting duty when they become aware of an actively exploited vulnerability in one of their products. Article 14 of the Regulation sets the duty. It is narrower than a rule for every organisation that sells software into the EU, and that distinction matters when an incident plan is being written.
The first notification must be made through the single reporting platform without undue delay and no later than 24 hours after awareness. It is an early warning, not a completed investigation. A subsequent notification is due without undue delay and no later than 72 hours after awareness, with the information available then. A final report is due no later than 14 days after a corrective or mitigating measure becomes available. The Commission’s reporting overview is useful here because it keeps the sequence visible: the early warning establishes that the event exists; the later material carries the investigation forward.
The hard part is the word awareness. The Commission’s non-binding guidance says that a suspicious report should be assessed immediately. It describes awareness as the point at which the manufacturer has a reasonable degree of certainty that active exploitation is taking place. Detection is therefore not a legal shortcut. A queue timestamp proves that a signal arrived; it does not by itself prove the conclusion that starts the reporting clock.
That makes the initial assessment worth treating as a first-class operational artifact. Keep the time at which the signal entered the organisation, and keep the time at which the assessment reached its conclusion, together with the evidence used and the person or team that performed it. Those two timestamps are not an additional legal condition. They are the record that lets a team reconstruct how it moved from an unverified report to awareness, and whether the assessment was actually handled without undue delay.
The first report also needs more than a bare assertion that an exploit exists. The ENISA glossary for the reporting platform identifies fields such as the report type, title and summary, as well as the affected product and version. Where applicable, Article 14 calls for information about the Member States in which the product has been made available. That is a conditional part of an early warning, not a substitute for the technical information that makes the warning actionable.
Article 14 reporting applies now and continues after a product’s support period. The CRA’s separate Annex I, Part II vulnerability-handling requirements are not yet generally applicable; the Regulation’s general application begins on 11 December 2027. For products subject to those requirements, the handling duties run only through the support period. That distinction matters for teams that put end-of-life products behind a different operational boundary: the reporting path still needs an owner, a reachable inbox, and a way to assess a credible signal.
The practical work is modest but specific. Trace the route a report takes from the first inbox to the first assessment. Make the evidence and the conclusion recoverable. Then make sure the person maintaining the report can distinguish what was known at the start from what became clear later. A 24-hour deadline is demanding enough; it should not have to carry the additional weight of a timeline nobody can explain.
This article is an operational reading of the CRA reporting process, not legal advice. Consult the Regulation and the applicable guidance for your product and circumstances.