From 11 September 2026, a manufacturer facing a reportable CRA Article 14 event has two early deadlines measured from awareness: an early warning without undue delay and no later than 24 hours, then a fuller notification without undue delay and no later than 72 hours. The final deadline depends on the track. For an actively exploited vulnerability, it is tied to when a corrective or mitigating measure becomes available. For a severe incident, it is tied to submission of the 72-hour incident notification.
This is practical information, not legal advice. The obligation comes from Regulation (EU) 2024/2847. Commission and ENISA materials help explain implementation, but Commission guidance is non-binding and operational instructions can change.
The reporting sequence at a glance
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Awareness | Clock starts when the manufacturer becomes aware of the reportable event | Same |
| Early warning | Without undue delay; no later than 24 hours after awareness | Without undue delay; no later than 24 hours after awareness |
| Notification | Without undue delay; no later than 72 hours after awareness | Without undue delay; no later than 72 hours after awareness |
| Final report | No later than 14 days after a corrective or mitigating measure becomes available | Within one month after submission of the 72-hour incident notification |
The 24-hour and 72-hour limits both run from awareness. The 72-hour stage is not simply due 48 hours after an early warning filed at any earlier point. The words “without undue delay” also matter: the outer limits are not permission to wait when the necessary information is already available.
Decide which Article 14 track applies
Article 14 does not make every vulnerability or security event mandatorily reportable. It creates two separate tests.
An actively exploited vulnerability requires reliable evidence that a malicious actor exploited the vulnerability in a system without the system owner’s permission. A newly disclosed vulnerability, a CVE assignment, a high severity score, or a precautionary patch does not establish that product-specific trigger on its own.
The Commission’s final guidance applies the test at product level. When vulnerable code comes from an integrated third-party component, the Commission says mandatory Article 14 reporting applies if that vulnerability is actively exploited in the manufacturer’s product. Vulnerable code that cannot be reached in that product, or that has not been exploited there, does not meet that interpretation of the mandatory trigger. Other supplier, vulnerability-handling, contractual, or voluntary-reporting steps may still apply.
The second track is a severe incident affecting product security. Article 14(5) covers an incident that negatively affects, or is capable of negatively affecting, the product’s ability to protect sensitive or important data or functions. It also covers an incident that has led, or is capable of leading, to malicious code being introduced or executed in the product or in a user’s network and information systems.
The potential-effect language is important. A process that asks only whether damage already occurred narrows the statutory test too far.
Article 14 reporting applies from 11 September 2026. It can also apply to in-scope products placed on the market before the CRA generally applies on 11 December 2027, so readiness work needs to account for the existing product portfolio.
Establish when awareness occurred
The Regulation starts each early clock when the manufacturer “becomes aware,” but it does not provide a detailed operational threshold for that moment.
The Commission’s final guidance says a suspicious event or outside report should be assessed promptly. In the Commission’s interpretation, awareness arises when an initial assessment gives the manufacturer a reasonable degree of certainty that the active-exploitation or severe-incident test is met.
That distinction prevents two opposite errors. An unverified researcher message, customer report, supplier notice, or media report is not automatically the same as legal awareness. It is still a reason to begin assessment promptly. Once reasonable certainty is reached, waiting for a complete forensic investigation can place the reporting sequence at risk.
Record at least three moments in the case history:
- when the signal arrived;
- when the initial assessment began; and
- when the reportability threshold was reached.
Also record the facts and decision-maker behind the awareness conclusion. That evidence helps later reviewers understand why the clock began when it did.
Prepare the 24-hour early warning
Both tracks require an early warning without undue delay and no later than 24 hours after awareness. The early warning is deliberately narrower than the later stages.
For an actively exploited vulnerability, identify, where applicable, the Member States where the manufacturer knows the affected product was made available.
For a severe incident, state at least whether unlawful or malicious acts are suspected. Identify relevant Member States where applicable.
The early warning is not a finished technical analysis. It gives authorities an initial signal while investigation, containment, and fact collection continue.
Build the 72-hour notification
The fuller notification is due without undue delay and no later than 72 hours after awareness.
For an actively exploited vulnerability, provide the information available at that point about:
- the affected product;
- the general nature of the exploit and vulnerability;
- corrective or mitigating measures already taken;
- measures users can take; and
- the sensitivity of the information, where applicable.
For a severe incident, provide available information about:
- the nature of the incident;
- the initial assessment;
- corrective or mitigating measures already taken;
- measures users can take; and
- the sensitivity of the information, where applicable.
Staged reporting accepts that the record develops. Keep the early warning and the 72-hour assessment internally consistent, and preserve why an assessment changed when later evidence displaced an earlier view.
Apply the correct final-report trigger
This is where the two tracks diverge.
For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. It is not due 14 days after awareness or 14 days after the 72-hour notification. The final report describes the vulnerability, its severity and impact, available information about the malicious actor, and the security update or other correction.
For a severe incident, the final report is due within one month after submission of the 72-hour incident notification. The Regulation says “one month,” not “30 days.” The report describes the incident, its severity and impact, the likely threat type or root cause, and applied or ongoing mitigation.
Current ENISA FAQ wording describes the incident final as one month after the “initial notification.” Article 14(4)(c), the Commission’s final guidance, the Commission reporting page, Ireland’s NCSC guidance, and independent legal analyses anchor that month to submission of the 72-hour incident notification. This guide follows the Regulation.
A case record therefore needs two different final-stage anchors:
- the time a vulnerability correction or mitigation became available; and
- the time a severe incident’s 72-hour notification was submitted.
Determine the coordinating-CSIRT route before an event
Article 14 reports use ENISA’s Single Reporting Platform through the electronic endpoint of the coordinating CSIRT. The notification is ordinarily made simultaneously accessible to ENISA, and the coordinating CSIRT manages dissemination to other relevant Member State CSIRTs.
For an EU-established manufacturer, the coordinating Member State is generally where decisions concerning the cybersecurity of its products are predominantly taken. If that cannot be determined, the Regulation points to the EU establishment with the highest number of employees.
A manufacturer without an EU main establishment follows Article 14(7)’s ordered fallback. The route considers the relevant authorised representative, then importer, distributor, and finally the Member State with the highest number of users.
Resolve that route before the reporting clock starts. Corporate-role and location questions are difficult to settle during a live 24-hour window. Check the current ENISA SRP material before filing because platform instructions can change.
Treat user communication as a separate duty
An SRP submission does not complete the manufacturer’s communication work.
Article 14(8) requires the manufacturer to inform impacted users and, where appropriate, all users about the vulnerability or incident. Where necessary, the communication must include mitigation or corrective measures that users can deploy.
Article 14 does not give this communication a separate 24-hour or 72-hour deadline. Commission guidance describes a risk-based and proportionate approach. Communication may initially be limited to affected users when indiscriminate technical disclosure could increase exploitation risk, but that does not remove the duty to help users act.
Also assess other duties independently. An Article 14 submission does not automatically replace separate legal, regulatory, contractual, or customer-notification duties that arise from the same facts.
Make the first hours administrative, not exploratory
A usable runbook prepares the decisions and evidence before an event:
- Inventory in-scope products, versions, components, manufacturer roles, and market Member States.
- Name who assesses both reportability tests, who can declare awareness, and who records the decision.
- Record the Article 14(7) routing analysis and keep it current.
- Name filing users and backups, including out-of-hours coverage.
- Prepare separate structures for the early warning, 72-hour notification, vulnerability final, and incident final.
- Preserve signal receipt, assessment, awareness, submission, corrective-measure availability, and user-communication evidence.
- Rehearse one vulnerability scenario and one severe-incident scenario.
These are operational recommendations, not additional legal elements. They make the statutory sequence easier to execute without changing it.
ActLume is being built as a human-controlled workspace for this process. The application is coming soon. You can review how the workflow is intended to work or read the broader CRA Article 14 overview while the launch site is open.
Four distinctions worth preserving
- A signal is not necessarily awareness, but it starts prompt assessment.
- The 24-hour and 72-hour deadlines both run from awareness.
- The vulnerability final clock starts when a corrective or mitigating measure becomes available.
- The severe-incident final clock starts when the 72-hour incident notification is submitted.
Those distinctions turn Article 14 from a loose deadline list into a workable reporting sequence.
Continue this workflow with the when does the Article 14 clock start guide and the two-track triage.