Reporting Under Article 14: The 24, 72 and 14-Day Clocks

The Cyber Resilience Act's design obligations wait until 11 December 2027. Article 14 does not. Reporting applies from 11 September 2026.

Two features make it the sharpest of the CRA's duties. It reaches products already made available on the Union market, including those placed before 11 December 2027, so it applies to an estate that was never designed against Annex I and may never be. And its deadlines are counted in hours, which means it cannot be discharged by a project. It needs a rota.

That inversion catches organisations that sequenced their CRA programme by the regulation's structure, starting with scope and essential requirements. Those matter for what you ship next. Article 14 matters for what you shipped five years ago and still support.

It sits alongside Annex I Part II rather than replacing it. Part II is the duty to fix. Article 14 is the duty to tell the authorities, and it runs in parallel.

Article 14 has exactly two triggers, and reading them precisely prevents both under-reporting and a flood of notifications nobody needs.

An actively exploited vulnerability is defined in Article 3 as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. Three elements do work. Reliable evidence, not suspicion. A malicious actor, which excludes good-faith research, penetration testing and coordinated disclosure. And exploitation in a system, not merely a published proof of concept.

A severe incident having an impact on the security of the product is an incident that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions, or that has led or is capable of leading to the introduction or execution of malicious code in the product or in a user's network and information systems.

A vulnerability you find and fix before anyone exploits it is not reportable.

Reports go simultaneously to two recipients: the CSIRT designated as coordinator for the Member State where the manufacturer has its main establishment, and ENISA. The channel is the single reporting platform established under Article 16, which ENISA operates with national entry points.

The simultaneity is deliberate. ENISA gets a Union-wide view of exploitation, and the national CSIRT gets the operational lead. The reporting manufacturer files once rather than to twenty-seven authorities.

Two practical consequences follow. First, you need to know which Member State holds your main establishment, and therefore which CSIRT is your coordinator, before an incident rather than during one. For a company with development in one country, incorporation in another and support in a third, that is a legal determination worth settling in advance.

Second, the report is expected to name the Member States affected. That means you need to be able to answer, quickly, where the affected product is deployed.

Both triggers run the same three-stage shape, and diverge only at the final report.

Awareness starts the clock. Within 24 hours an early warning goes in. For a vulnerability it indicates the Member States where the product is made available; for an incident it also flags whether the cause is suspected to be unlawful or malicious. The early warning is a flare, not an analysis. You are not expected to know the root cause.

Within 72 hours the substantive notification follows: general information about the product, the nature of the exploit or incident, an initial assessment, and any corrective or mitigating measures taken or available.

Then the paths part. A vulnerability report closes 14 days after a corrective or mitigating measure becomes available, which means the clock is tied to your fix and not to the calendar. An incident report closes one month after the 72-hour notification, a fixed date regardless of where remediation stands.

The three stages ask for progressively more, and the early stages are deliberately cheap to file.

The early warning at 24 hours carries the minimum: that you are aware of an actively exploited vulnerability or a severe incident, and which Member States are affected. For incidents, whether the cause is suspected to be unlawful or malicious.

The notification at 72 hours carries general information about the product concerned, the general nature of the exploit and of the vulnerability, or the nature of the incident and an initial assessment, plus any corrective or mitigating measures taken or that users can apply.

The final report differs by track. For a vulnerability: a description of the vulnerability including severity and impact, information about any malicious actor where available, and details of the security update or other corrective measure. For an incident: a description, the type of threat or root cause that likely triggered it, and the applied and ongoing mitigation measures.

Reporting to a CSIRT does not discharge the obligation to customers. Article 14 requires the manufacturer to inform, without undue delay and after becoming aware, the impacted users of the product, and where appropriate all users, about the actively exploited vulnerability or severe incident and about any risk mitigation and corrective measures they can deploy.

Where necessary, the manufacturer must also provide, in an easily accessible form, advisory messages with instructions including where relevant actions users can take to mitigate the impact.

The enforcement mechanism here is unusual and worth noting. If the manufacturer does not inform users in time, the CSIRT may do it instead, and may inform the public where it considers this proportionate and necessary to prevent or mitigate the impact.

That changes the incentive structure. A manufacturer weighing whether to stay quiet is not choosing between disclosure and silence. It is choosing between its own disclosure and someone else's.

Every deadline runs from when the manufacturer becomes aware. That phrase carries almost all of the operational difficulty, because awareness is distributed.

A support engineer reads a customer ticket describing behaviour that is, in fact, exploitation. A threat intelligence feed names your product. A researcher emails the disclosure address on a Friday evening. A cloud team sees anomalous traffic from a fleet of devices. In each case the organisation now holds information; whether it has become aware depends on whether that information reaches someone who can recognise it.

The design implication is that the reportability judgement has to be pushed to where the signal lands, or the signal has to be routed fast to where the judgement lives. Twenty-four hours does not pause for weekends.

The practical failure mode is not a missed deadline in a crisis. It is a ticket that sat in a queue for three days before anyone read it as an exploitation report.

Three qualifications soften the regime at the edges, and none of them removes the duty to report.

Microenterprises and small enterprises may not be fined for missing the 24-hour early warning deadline. The obligation still stands, and the later stages remain enforceable. This is a proportionality valve for a company where the person who would file at 2am is also the person fixing the bug.

Open-source software stewards report actively exploited vulnerabilities to the extent they are involved in the development of the product, and severe incidents affecting their own development infrastructure. They are not subject to CRA penalties at all.

And dissemination onward can be delayed. The regulation contemplates conditions under which a CSIRT withholds circulation of a report on cybersecurity grounds, so that a widely deployed unpatched flaw is not broadcast before a fix exists. That governs what authorities do with your report, not whether you file it.

A company can sit under several reporting regimes at once, and they do not align.

The CRA cascade deliberately mirrors NIS2 in shape. The divergence is the subject: NIS2 asks what happened to your organisation, the CRA asks what is happening to your product in someone else's hands.

One event can trigger several. An exploited flaw in your product that also breached your own systems and exposed personal data can be reportable three times, on three timetables, to three authorities.

Article 14 is satisfied by a process, not a document. A minimal one has seven parts.

A named coordinator CSIRT, determined from your main establishment, with the platform account provisioned and tested. A monitored intake covering the disclosure address, support queues and threat feeds. A written trigger test that a duty engineer can apply at 3am without calling a lawyer, distilling the two Article 3 definitions into questions about evidence and malicious intent.

An escalation path with a named decision-maker and a deputy, and an out-of-hours rota. Pre-drafted templates for all three stages, so the 24-hour filing is a form completion rather than a composition. A deployment map answering which Member States are affected, per product. And a customer notification channel that can reach impacted users directly.

The test of readiness is not whether the policy exists. It is whether a Saturday report reaches a decision within hours.