ENISA Single Reporting Platform (SRP), explained

From 11 September 2026, the EU CRA’s reporting obligations kick in. Manufacturers placing products with digital elements on the EU market must report actively exploited vulnerabilities and severe incidents to the relevant national CSIRT and to ENISA. The reporting infrastructure is the Single Reporting Platform (SRP).

What the SRP actually is

The SRP is a central EU intake system operated by ENISA. Manufacturers submit a notification once; the platform routes it to the appropriate national CSIRT based on where the manufacturer (or its EU authorised representative) is established.

Goals:

• One platform instead of 27 national portals
• Common schema for vulnerability and incident reports
• Automated cross-border information sharing where appropriate

Who registers

Every manufacturer of in-scope products. Importers and distributors do not need their own registration if the original manufacturer is registered. Non-EU manufacturers register through their authorised representative.

Registration is free. You provide:

• Company / authorised representative legal entity
• Manufacturer contact and security contact
• Product portfolio summary (categories, not full SBOM)
• Member State of establishment (drives CSIRT routing)

What triggers a report

Two events:

1. An actively exploited vulnerability in a product with digital elements you placed on the EU market
2. A severe incident that has an impact on the security of one of your products

“Actively exploited” is the key phrase. It means there is reasonable evidence that a malicious actor has used the vulnerability. A theoretical CVE is not an actively exploited vulnerability. A CVE that the same researcher who found it has demonstrated exploiting in the wild generally is.

The reporting timeline

The clock starts when a sufficiently informed person inside the company becomes aware. Article 14 runs two tracks, and they diverge at the final report.

Actively exploited vulnerability (Article 14(2))

• Within 24 hours: Submit an early warning. Short notification: “we are aware, this product is affected, this is the suspected nature”.
• Within 72 hours: Submit a vulnerability notification. More detail: nature, impact, mitigations applied or recommended.
• Within 14 days of a corrective or mitigating measure becoming available: Submit a final report. Description of the vulnerability including severity and impact, information on any malicious actor exploiting it, and details of the security update or other corrective measures.

Severe incident impacting product security (Article 14(4))

• Within 24 hours: Submit an early warning.
• Within 72 hours: Submit an incident notification. Nature of the incident, an initial assessment, mitigations applied or recommended.
• Within one month of the 72-hour incident notification: Submit a final report. Detailed description including severity and impact, the type of threat or likely root cause, and applied and ongoing mitigation measures.

The 14-day clock is not 14 days from awareness. It starts when a fix or mitigation exists, which can fall well after the 72-hour notification.

Microenterprises and small enterprises still have to meet the 24-hour deadline, but Article 64(10)(a) exempts them from administrative fines for missing it. Corrigendum 2025/90555 of 2 July 2025 widened that derogation to paragraphs 2 to 9, which is what pulls the Article 14 fines in paragraph 2 inside it. The exemption covers the early warning only. The 72-hour notification and the final report are not covered, and medium-sized enterprises are not covered at all.

How to prepare

Three steps in order of priority:

1. Register the manufacturer profile in advance. Do not wait for an incident. The SRP will publish onboarding material in 2026, so get your profile before September.
2. Decide who has authority to file. The 24-hour clock is too tight for ambiguous escalation paths. Pick named people, write the runbook, publish it internally.
3. Run a tabletop exercise. The first time you submit through the SRP UI should not be in production. Walk through a hypothetical vulnerability end-to-end.

What if you under-report?

Failure to report is a manufacturer-obligation breach, and it sits in the top penalty tier. Article 64(2) covers the essential requirements in Annex I together with the obligations in Articles 13 and 14, at up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. The lower €10 million / 2% tier in Article 64(3) lists Articles 18 to 23, 28, 30(1) to (4), 31(1) to (4), 32(1), (2) and (3), 33(5), 39, 41, 47, 49 and 53. Article 14 is not among them. Honest interpretation gets considered, wilful concealment does not.

What about over-reporting?

The CRA does not penalise reasonable over-reporting. If you genuinely don’t know whether a vulnerability is being actively exploited, it’s safer to file the early warning. The SRP can downgrade or close a notification later.

Tooling

The platform itself is provided by ENISA. We build the CRA Incident Reporter on top: pre-formatted templates, internal approval workflows, and clocks tied to the moment you flag awareness. Optional, but it’s the difference between a calm Tuesday filing and a panicked Saturday filing.

This article is general information about the EU Cyber Resilience Act, not legal advice, and reading it creates no advisory relationship. It reflects our reading of the regulation and the guidance available on the date shown above, both of which change. Classification, deadlines and obligations turn on the specific facts of your product. Verify against the primary sources before you rely on any of it, and take professional advice for decisions that carry legal or financial consequences. See our terms.