Cyber Resilience Act reporting obligations: what to report, and by when

Both triggers start the same reporting clocks. The 24- and 72-hour clocks run from the moment the manufacturer becomes aware — not from when the vulnerability was exploited or the incident began; the final reports run from the fix or the notification. The notification and the final report are not needed where the relevant information has already been provided in an earlier report.

The early warning names, where applicable, the Member States where you know the product is available; for an incident it also says whether unlawful or malicious acts are suspected. The notification gives general information on the product, the exploit or incident, and the corrective or mitigating measures taken and available to users. The final report describes the vulnerability or incident with its severity and impact and the fix or mitigation, plus any information on the malicious actor for a vulnerability, or the likely root cause for an incident. The CSIRT that receives the notification may also ask for an intermediate report on status updates.

An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission. The trigger is exploitation, not severity: a vulnerability with a critical score and no evidence of exploitation does not start the clock. It covers vulnerabilities in components the product contains, and a vulnerability found in an integrated component, open source included, must also be reported to whoever maintains it (Article 13(6)).

Recital 68 narrows this in two ways. It concerns a breach that “has resulted from a malicious actor making use of a flaw in one of the products with digital elements made available on the market by the manufacturer” — the exploitation of a flaw in your product. And vulnerabilities “discovered with no malicious intent for purposes of good faith testing, investigation, correction or disclosure” should not be subject to mandatory notification.

An incident affecting the security of the product is a severe incident when it affects, or could affect, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or when it has led, or could lead, to malicious code being introduced or executed in the product or in a user’s systems (Article 14(5)).

Public catalogs help with the evidence question. CISA’s Known Exploited Vulnerabilities catalog lists vulnerabilities it has evidence are exploited in the wild; FIRST’s EPSS score predicts how likely exploitation activity is in the next 30 days. The regulation names neither. A KEV listing is strong evidence to weigh, but CISA’s criteria also cover attempted exploitation, so confirm the vulnerability is present and exploitable in your product. An EPSS score on its own is a forecast, not evidence that exploitation has happened. FOSSA has a guide to using the CISA KEV catalog (on fossa.com, opens in a new tab) to track exploited vulnerabilities in dependencies.

Anything below these thresholds — a vulnerability, a cyber threat, an incident or a near miss — can still be reported voluntarily to a CSIRT or ENISA (Article 15).

Reports are submitted through ENISA’s single reporting platform, using the electronic notification end-point of the CSIRT designated as coordinator in the Member State of your main establishment, and are simultaneously accessible to ENISA (Article 14(7)). Your main establishment is where decisions on the cybersecurity of your products are predominantly taken, or failing that, where you have the most employees in the EU.

A manufacturer with no main establishment in the EU reports to the CSIRT in the Member State of its authorised representative for the most of its products, then its importer, then its distributor, and finally where most of its users are — checked in that order. In that last case it may send later reports to the same CSIRT it first reported to.

You must also inform impacted users — and where appropriate all users — about the vulnerability or incident and any mitigation they can apply, where appropriate in a structured, machine-readable format (Article 14(8)).

The reporting obligations also cover products already on the market. They apply to every in-scope product placed on the market before 11 December 2027 (Article 69(3)), while most other requirements reach those legacy products only if they are substantially modified. Article 14 itself has applied since 11 September 2026 (Article 71(2)). See the CRA timeline.

When does the 24-hour clock start?

When the manufacturer becomes aware of the actively exploited vulnerability or the severe incident. Not when it happened, and not when the investigation finishes.

Does a critical CVSS score have to be reported?

Not on its own. The obligation turns on reliable evidence of exploitation, whatever the score. A high score is a reason to fix quickly, and to watch for exploitation evidence.

Is a CVE in the CISA KEV catalog automatically reportable?

No. The regulation does not mention the catalog. A listing is strong evidence to weigh, but the question is whether the vulnerability has been exploited via your product (recital 68), so confirm it is present and exploitable there. The assessment is yours to make and document.

Do open-source software stewards have to report?

To the extent they are involved in developing the product, and for severe incidents affecting the systems they provide for its development (Article 24(3)). See the applicability checker if you are unsure which role you have.