CRA reporting obligations
The CRA reporting obligations require every manufacturer of a product with digital elements to notify ENISA and the coordinating CSIRT when a vulnerability in that product is actively exploited, or when a severe incident affects its security. Two triggers, three stages each, and a 24-hour clock that starts the moment you become aware. This page sets out what to report, what not to report, where it goes, and when the duty begins.
The obligations in one paragraph
Article 14 of the Cyber Resilience Act obliges a manufacturer to notify the CSIRT designated as coordinator and ENISA simultaneously, through the single reporting platform, on becoming aware of either an actively exploited vulnerability contained in its product or a severe incident having an impact on that product's security. Each trigger runs the same first two stages, an early warning within 24 hours and a full notification within 72 hours, both measured from awareness. The final report differs. For a vulnerability it is due no later than 14 days after a corrective or mitigating measure is available. For an incident it is due within one month of the 72-hour notification. The duty applies from 11 September 2026, 15 months before the rest of the regulation.
The obligation attaches to awareness, so the hard part is rarely the filing. It is having a disclosure process that tells you a thing is being exploited while there are still 24 hours left to act on it. That process is an Article 13 obligation and it does not formally apply until 11 December 2027, which is an ordering trap worth naming: the duty that depends on CVD lands more than a year before the duty to run CVD.
The two triggers and the three-stage cascade
Article 14(2) governs actively exploited vulnerabilities. Article 14(4) governs severe incidents. They look alike until the final report, where the clocks start from different events.
| Stage | Deadline | Actively exploited vulnerability — Art. 14(2) | Severe incident — Art. 14(4) |
|---|---|---|---|
| Early warning | 24 hoursFrom becoming aware | That exploitation is happening, plus the Member States where you know the product was made available. | That a severe incident occurred, including whether you suspect unlawful or malicious acts. |
| Full notification | 72 hoursFrom becoming aware | General information about the product, the nature of the exploit and the vulnerability, and any corrective or mitigating measures taken or available to users. | The nature of the incident, an initial assessment, and any corrective or mitigating measures taken or available to users. |
| Final report | 14 days / one monthDiffers by trigger | Within 14 days after a corrective or mitigating measure is available. Describes the vulnerability with its severity and impact, any known malicious actor exploiting it, and the security update shipped. | Within one month after the 72-hour incident notification. Describes the incident with its severity and impact, the likely threat type or root cause, and applied plus ongoing mitigations. |
Under Article 14(6) the coordinating CSIRT that received the notification may also request an intermediate report on status updates at any point between these stages.
What you do not report
Over-reporting is its own failure mode. It buries the coordinating CSIRT and trains your own team to treat the 24-hour clock as routine. These four cases fall outside Article 14.
A vulnerability nobody is exploiting
Article 14(1) is triggered by an actively exploited vulnerability. A vulnerability that is merely exploitable, however severe its CVSS score, does not start the 24-hour clock. Evidence of real-world exploitation is the line. Proof-of-concept code alone is not exploitation.
An ordinary report from your CVD channel
Most of what arrives through your disclosure inbox is a researcher describing a flaw that nobody has used against anyone. You must handle it, but you do not notify ENISA about it. The reporting duty attaches only once you become aware of active exploitation or a severe incident.
An incident that is not severe
Article 14(5) defines severe narrowly. The incident must negatively affect, or be capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. Or it must have led, or be capable of leading, to malicious code being introduced or executed in the product or in a user's network and information systems.
A vulnerability in someone else's product
You report vulnerabilities contained in your own product with digital elements. If the flaw sits in a third-party component you ship, it is contained in your product and you report it, while also notifying the component vendor. If you are the component supplier, you notify the manufacturers downstream who integrate you.
Where the reports go
Article 14(7) routes every notification through the single reporting platform established under Article 16. You submit using the electronic notification end-point of the CSIRT designated as coordinator of the Member State where your main establishment in the Union sits, and the notification reaches ENISA at the same time. ENISA and the coordinating CSIRT are not alternatives, and you do not pick the friendlier one.
If you have no establishment in the Union, the routing follows the Member State where your authorised representative or importer is placed. Determining which CSIRT is your coordinator is something to settle before an incident, not during one.
ENISA does not currently expose a submission API for the platform, so the filing itself is a manual step whatever tooling you use. What can be automated is everything around it: starting the clocks on intake, driving triage, and assembling the package so the manual step takes minutes.
When the obligations apply
Article 71(2) sets 11 December 2027 as the date the Regulation applies, then carves out exactly two derogations. Chapter IV on notified bodies applies from 11 June 2026, and Article 14 applies from 11 September 2026. Nothing else moves early.
This is worth being precise about, because Article 13 and Article 14 are often quoted as a pair with a single date. They are not. The reporting cascade binds from September 2026. The Article 13 obligations, including the coordinated vulnerability disclosure policy and the single point of contact, bind from December 2027 along with conformity assessment, CE marking and the Annex I essential requirements.
Going deeper
Each of these takes one part of the reporting obligations further.
When Vulnerability and Incident Reporting Become Mandatory Under the CRA
The CRA's reporting obligations do not switch on with the rest of the regulation. Article 14 applies from 11 September 2026, ahead of full conformity in December 2027, and it binds manufacturers the moment a product becomes actively exploited. Here is exactly when the duty begins and who it binds.
Which Vulnerabilities and Incidents Must Be Reported, and Which Do Not
Most vulnerabilities a manufacturer handles never trigger a report to authorities. The CRA's Article 14 duty is narrow: actively exploited vulnerabilities and severe incidents affecting product security. Here is how to tell what is in scope, with worked examples and a decision framework.
Understanding Reporting Timelines and Follow-Up Obligations
Article 14 is a three-stage cascade: a 24-hour early warning, a 72-hour detailed notification, and a final report within 14 days or one month. Here is what each stage must contain, when the clock starts, and the follow-up duties that continue after the final report.
How Reporting to ENISA and National Authorities Is Organised
When an Article 14 event occurs, a manufacturer does not file with a single regulator. The CRA routes reports through a single platform to ENISA and the relevant national CSIRT at once. Here is how that architecture works, who receives what, and how onward notification flows.
CRA Incident and Vulnerability Reporting: Which Obligations Apply, When They Start, and How to Be Ready
The CRA separates vulnerability reporting from incident reporting, imposes different timelines for each, and routes notifications through ENISA and national authorities via the Single Reporting Platform. Here is what applies to your products, when it starts, and the internal processes you need before September 2026.
Exploitable vs. Exploited: The Legal Distinction That Defines Your CRA Compliance
The CRA draws a sharp legal line between 'exploitable' and 'actively exploited' vulnerabilities - with very different consequences for each. We break down the three-tier obligation framework, the EUVD's role as authoritative reference, and the September 2026 reporting deadlines that apply to products already on the market.
Frequently asked
What are the CRA reporting obligations?
When do the CRA reporting obligations start?
What is the difference between the Article 13 and Article 14 obligations?
Who do you report to under the CRA?
Does a vulnerability with a high CVSS score have to be reported?
What happens if you miss a CRA reporting deadline?
Can you report to ENISA through an API?
Be ready before the clock starts
CRA Portal takes reports through a branded disclosure portal, starts the Article 14 timers the moment a case is flagged as exploited, drives triage and remediation, and assembles a submission-ready package for the single reporting platform.
Receiving and tracking reports is free. Article 14 filing with the submission-ready package is on the Reporting plan. EU data residency by default, no card required to start.
CRA Portal supports CRA compliance work but does not provide legal advice and does not by itself establish conformity or a presumption of conformity. It is an independent platform, not affiliated with or endorsed by the EU or ENISA.