Guide · updated 17 October 2026

CRA vulnerability reporting requirements: the 24h, 72h and 14-day deadlines

Article 14 of the Cyber Resilience Act is the first part of the regulation to bite. It has applied since 11 September 2026, to new products and to products already on the market. Here is what it requires, in plain terms.

Who it applies to

Manufacturers of products with digital elements made available on the EU market: connected devices, embedded controllers, gateways, apps and software products, whether you're based in the EU or not. The reporting obligation covers products placed on the market before the CRA's full application date too, so your installed base counts.

Products already covered by their own sector rules, such as medical devices, motor vehicles, civil aviation and marine equipment, are outside the CRA.

What you must report

1. Actively exploited vulnerabilities

A vulnerability in your product for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. A theoretical weakness, or a researcher's report without exploitation, doesn't trigger Article 14 on its own (though you still have to fix it under your vulnerability-handling duties).

2. Severe incidents having an impact on the security of the product

An incident is severe if it negatively affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led or could lead to malicious code being introduced or executed in the product or in users' networks and systems. A compromised update server that pushes malicious firmware is the classic example.

The deadlines

All three go through ENISA's Single Reporting Platform to your coordinating CSIRT, with ENISA notified at the same time. The CSIRT can ask for intermediate status updates.

Telling your users

After becoming aware, you must also inform the impacted users of the product, and where appropriate all users, about the vulnerability or incident and any risk-mitigation and corrective measures they can take. Where appropriate, this should be in a structured, machine-readable format that can be processed automatically. If you don't inform users in time, the CSIRT may do it.

Other duties that sit next to Article 14

• A single point of contact for vulnerability reports, easy to find (Article 13(17)). Publishing it in /.well-known/security.txt is the common way. Check yours for free.
• A coordinated vulnerability disclosure policy that you put in place and enforce (Annex I, Part II). Fully applicable from 11 December 2027, but you'll want it before your first report.
• Reporting vulnerabilities in components you integrate, including open-source ones, to whoever maintains them (Article 13(6)).
• Voluntary reporting of other vulnerabilities, cyber threats and near misses is possible (Article 15).

Fines

Breaching the essential cybersecurity requirements or the obligations in Articles 13 and 14 can lead to fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. The regulation includes some relief for microenterprises and small enterprises around the 24-hour early-warning deadline, but the duty to report still applies to them; check how your Member State applies it with your counsel.

What makes the 24 hours hard

The early warning asks for little, but you need three things in place to send it on time:

1. The report reaches someone. A monitored security inbox, published where researchers look.
2. Someone can make the call. "Does this appear reportable?" needs an owner and access to counsel, including at weekends.
3. The facts are at hand. Which products, which versions, which countries. A product and version register turns a day of digging into minutes.

Our free 24h/72h/14-day runbook walks through each step with an SRP field checklist.

Sources: Regulation (EU) 2024/2847, Articles 3, 13, 14, 15, 64 and 69 and Annex I. Not legal advice.