CRA Vulnerability and Incident Reporting

From 11 September 2026, CRA manufacturers must report actively exploited vulnerabilities and severe incidents through the ENISA Single Reporting Platform. This guide explains what triggers a report, how the 24-hour, 72-hour, 14-day, and 1-month deadlines work, and where CVD, VEX, and user notifications fit.

What must be reported

CRA reporting has two mandatory event streams and one user-notification duty. The duty sits with the manufacturer of the product with digital elements placed on the EU market:

1. Notify any actively exploited vulnerability in the product simultaneously to the coordinator CSIRT and to ENISA, on the 24h / 72h / 14d cadence.
2. Notify any severe incident affecting the security of the product on a 24h / 72h / 1-month cadence.
3. Inform users of the affected product about the vulnerability or incident and any corrective measures, without undue delay.

This page also covers two adjacent controls that feed the reporting decision: the mandatory CVD policy and vulnerability applicability evidence such as VEX. None of these duties has a size threshold. Microenterprises and small enterprises get only a narrow penalty carve-out for the 24-hour early warning; they are not exempt from reporting.

The ENISA Single Reporting Platform (SRP)

The SRP is the single channel for mandatory CRA vulnerability and incident reports. It exists because the manufacturer must notify the coordinator CSIRT and ENISA through one reporting platform, rather than filing separately in every Member State where the product is available. ENISA establishes and manages the platform.

How it works in practice:

• You submit once, using the electronic end-point of the CSIRT designated as your coordinator.
• The submission is addressed to the coordinator CSIRT and is simultaneously accessible to ENISA, unless the exceptional dissemination-delay mechanism applies.
• The coordinator CSIRT then disseminates the notification to CSIRTs in other Member States where your product is placed on the market. That secondary dissemination is the CSIRT's responsibility, not the manufacturer's.
• The dissemination-delay rule allows a CSIRT to delay onward dissemination on justified cybersecurity-related grounds in exceptional circumstances. The coordinated-disclosure rule can also allow delay with the manufacturer's consent.

Status as of June 2026: the SRP remains scheduled to be operational by 11 September 2026, with a testing period before then. ENISA states it will provide the access and registration instructions, plus training and dry-run support material, during June 2026, so the registration mechanics are still being published. ENISA also says no SRP API is provided at this stage, so plan reporting readiness around submission through the platform rather than API automation. For the registration mechanics see ENISA SRP onboarding. Track the Commission CRA reporting page and the ENISA SRP page before relying on a specific registration step.

What manufacturers should do now: identify your coordinator CSIRT, draft and pre-approve report templates for the 24h, 72h, and final-report submissions in both streams, and define an out-of-hours escalation rota. Templates and processes cannot be drafted while the 24-hour clock is running.

Reporting timelines in detail

Both vulnerabilities and severe incidents follow a staged reporting model. The clocks differ on the final-report leg.

Reporting timetable

What each submission contains

Early warning (24 hours). The early warning is an alert, not a full analysis. For vulnerabilities, it must be sent without undue delay and within 24 hours of awareness, and it should indicate the Member States where the manufacturer knows the product has been made available where applicable. For severe incidents, it must also state at least whether the incident is suspected to be caused by unlawful or malicious acts. Internal templates can add product version, severity, impact scope and owner fields, but those are operational fields, not all legal minimums.

Detailed notification (72 hours). Two distinct duties live at this stage. The 72-hour vulnerability notification applies to actively exploited vulnerabilities and gives general information about the product, exploit, vulnerability, measures taken, user measures, and sensitivity where applicable. The 72-hour incident notification applies to severe incidents and gives general information about the incident, an initial assessment, measures taken, user measures, and sensitivity where applicable.

Final report. For vulnerabilities, the 14-day clock starts when a corrective or mitigating measure is available, not at discovery and not at the 72-hour notification. The final report must include at least the vulnerability description, severity and impact, information about malicious actors where available, and details of the security update or other corrective measures. For severe incidents, the 1-month clock anchors to the 72-hour incident notification and the final report must include at least a detailed incident description, severity and impact, likely threat type or root cause, and applied or ongoing mitigation measures.

1. Awareness Manufacturer awareness The 24-hour clock starts when the manufacturer becomes aware of reliable evidence of active exploitation.
2. +24h Early warning Submit the initial warning through the ENISA Single Reporting Platform.
3. +72h Detailed notification Add technical details, affected versions, exploitation status, and mitigation state.
4. Measure ready Corrective or mitigating measure available The vulnerability final-report clock starts here, not at discovery.
5. +14d Final report Submit the required final details for the vulnerability or severe-incident stream.

Severe incidents follow the same 24-hour and 72-hour opening steps, with the final report due within 1 month after the 72-hour notification.

Data fields in the SRP reporting template

ENISA's SRP FAQ (Q16) lists the fields expected at each reporting stage. ENISA frames these as fields that will be obligatory (directly from the CRA or by logical consequence) or optional, so treat them as provisional until the platform is final. Codes: X obligatory, O optional, C copied from the previous step by default or updated, A automated (not shown to the submitter), I obligatory if the information is available.

Severity criteria (i22): a severe incident is one that (1) negatively affects, or is capable of negatively affecting, a product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or (2) 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.

Source: ENISA SRP FAQ, Q16.

What triggers a reporting obligation?

CRA reporting has two trigger categories: actively exploited vulnerabilities and severe incidents having an impact on the security of the product.

1. Actively exploited vulnerabilities

An actively exploited vulnerability is a vulnerability in the product where there is reliable evidence that a malicious actor has exploited it in a system without permission. The manufacturer must also have become aware of that exploitation before the reporting clock starts.

This is not the same as public disclosure, a published proof-of-concept, or a researcher demonstrating exploitability in a lab. Those signals belong in vulnerability handling and CVD triage unless they create reliable evidence of malicious exploitation against a real system.

2. Severe incidents

A severe incident is an incident having an impact on the security of the product that meets either criterion:

• it negatively affects, or is 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 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.

Reportable vs non-reportable scenarios

Awareness and evidence

The CRA definition uses reliable evidence, not forensic certainty. Useful evidence can include exploit telemetry, customer compromise reports, threat intelligence naming your product, or logs showing exploit behaviour against the product. If the evidence is not yet reliable, keep the event in CVD or incident triage; if it becomes reliable, the 24-hour clock starts when the manufacturer becomes aware.

CVD intake and the reporting gate

The CVD policy is the intake process that turns external researcher reports into structured triage. When that triage produces reliable evidence of active exploitation, the urgent reporting clock runs in parallel with remediation and coordinated disclosure. The policy is mandatory for every product with digital elements, and there is no SME or size threshold. A public CVD page plus a security.txt file under /.well-known/security.txt is the practical way to make the reporting channel discoverable.

For the CVD policy itself, including required contents, disclosure-window conventions, safe-harbour language and researcher-communication templates, see the dedicated CRA Coordinated Vulnerability Disclosure guide. For how CVD sits among the wider vulnerability-handling lifecycle, see CRA vulnerability handling. For the combined Article 14 handling-and-reporting overview, see vulnerability handling and reporting.

VEX and vulnerability applicability

VEX (Vulnerability Exploitability eXchange) is a structured, machine-readable statement about whether a vulnerability in an SBOM component actually affects a specific product. It turns raw CVE matches into a defensible product-specific status:

For reporting, the key question is applicability plus active exploitation. A vulnerability marked affected and backed by reliable evidence of active exploitation is the kind of event that starts the 24-hour early-warning clock. A vulnerability marked not_affected with a sound justification supports a non-reporting decision. The CRA does not name VEX, but VEX is a practical way to preserve that justification. For VEX formats, examples, justification types, tooling, and SBOM integration, see the VEX implementation guide.

Small manufacturer relief

Microenterprises and small enterprises (defined as fewer than 50 employees and an annual turnover or balance sheet of up to EUR 10 million; microenterprises: fewer than 10 employees, EUR 2 million) are exempt from fines only for missing the first 24-hour early-warning deadline. The relief covers timing fines on that first leg only.

Still required, with no SME relief:

• The 72-hour detailed notification.
• The 14-day final report for vulnerabilities and the 1-month final report for severe incidents.
• The CVD policy.
• All other CRA product-security obligations, including the no-known-exploitable-vulnerabilities baseline.

Medium enterprises are not covered by the relief. It is a narrow penalty carve-out, not a reduced reporting regime. For the wider penalty structure, including recalls and market-surveillance powers, see CRA penalties and enforcement.

Common mistakes

• Waiting for forensic certainty before starting the clock. Reliable evidence is enough; the CRA does not require a completed forensic investigation before the early warning.
• Confusing CVD with urgent reporting. A researcher report is a CVD input; urgent reporting starts when there is reliable evidence of active exploitation. The CVD policy must contain an explicit gate for this.
• Single-point-of-failure escalation. One person authorised to report, unreachable on a Friday night. The 24-hour clock does not pause.
• First contact with the coordinator CSIRT during an incident. Establish the relationship and the routing now, while there is no clock running.
• No published CVD policy. A public policy is required; an internal document is not enough.
• No applicability decisions. Without VEX or an equivalent record, it is hard to defend why a known CVE in your SBOM is not exploitable in your product.
• Treating the SRP launch as a future problem. Templates, escalation rotas, and CSIRT relationships have to be in place before September 2026, not built afterwards.