CRA Vulnerability and Incident Reporting

Since 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 lets the coordinator CSIRT delay onward dissemination in exceptional circumstances, on justified cybersecurity grounds, for as long as is strictly necessary. The manufacturer can ask for that and can flag how sensitive the information is, but the decision belongs to the CSIRT, not to you. There is a second, distinct delay for a vulnerability the coordinator CSIRT learned about through a coordinated vulnerability disclosure procedure. There the CSIRT may hold the notification back on justified cybersecurity grounds, for no longer than is strictly necessary and until the parties to that disclosure consent to it being disclosed. Worth knowing if you run a CVD process, but the decision belongs to the CSIRT here too, so do not plan on an embargo holding.
• Particular exceptional circumstances, or PEC, is a narrower and separate mechanism. It applies only to the 72-hour notification for an actively exploited vulnerability, and only where the exploitation is confined to your coordinator's Member State, where wider disclosure would run against that State's essential interests, or where dissemination itself would create an imminent high cybersecurity risk. You raise it with a toggle in the platform and may add a justification; the coordinator CSIRT decides. While it holds, ENISA still receives a reduced set: that a notification was made, general product information, the general nature of the exploit, and that security grounds were raised. The full notification follows when the delay ends. ENISA's PEC guidance sets out the procedure.

Status, 11 September 2026: the SRP is available at portal.cra-srp.enisa.europa.eu. On the landing page you select the Assigned Representative role, the SRP account that files on behalf of a manufacturer or an open-source software steward. That is not the same thing as a CRA authorised representative. Sign-in uses EU Login, and EU Login accounts are personal and must have multi-factor authentication enabled. ENISA refreshed its FAQ and its Assigned Representative registration guide on 10 September 2026, and its interface and notification guides on 9 September 2026. On 9 September 2026 it also published a 55-page AR User Manual, the click-by-click walkthrough of registration, the three submission stages and updating a notification. The SRP Glossary is at version 1.3 and is the field-by-field reference. It is English only. The list of CSIRTs designated as coordinators carries the date 10 September 2026. There is no API at the initial release, so every notification goes through the platform interface, and voluntary reporting is not available at launch. ENISA marks all of its guidance as current best knowledge and subject to change. Create your EU Login account now, use the ENISA SRP onboarding guide, and contact cra-srp-helpdesk@enisa.europa.eu if needed.

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 a prompt initial assessment gives the manufacturer a reasonable degree of certainty that a vulnerability in its product is being actively exploited.
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 Glossary is the field-by-field reference for what the platform asks at each stage. Version 1.3 lists 39 fields: 18 common to both streams, 12 that apply only to an actively exploited vulnerability, and 9 that apply only to a severe incident. It is English only, and ENISA marks it as current best knowledge and subject to change. Codes: X required, O optional, C copied from the previous step by default or updated, I required if such information is available, - not applicable at that stage.

Severity criteria for i34: 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 Glossary, version 1.3, last update 10 September 2026.

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 to identify an actively exploited vulnerability. Awareness is a separate test: after a prompt initial assessment, the manufacturer must have a reasonable degree of certainty that a vulnerability in its product is being actively exploited. A completed forensic investigation is not required.

CVD intake and the reporting gate

The CVD policy is the intake process that turns external researcher reports into structured triage. When triage indicates active exploitation, assess it promptly. The urgent reporting clock starts when that initial assessment gives the manufacturer a reasonable degree of certainty. 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. A prompt initial assessment and a reasonable degree of certainty are enough; a completed forensic investigation is not required.
• Confusing CVD with urgent reporting. A researcher report is a CVD input; urgent reporting starts when the initial assessment gives the manufacturer a reasonable degree of certainty 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 as a future problem. Templates, escalation rotas, and CSIRT relationships have to be in place before the first reportable event, not built during it.

1. The Glossary marks this field as required at the 24-hour early warning and, in the same row, notes that it arrives in the next release of the platform. Until that release lands you may not find it on screen. Keep your own awareness timestamp and be ready to supply it either way. ↩︎

2. The Glossary notes that in the current release this field is labelled "Date and time when the incident was detected (UTC time)". Detection is not the same thing as awareness, so record both. ↩︎