The ENISA Single Reporting Platform
The SRP is the single entry point for CRA notifications. A manufacturer files once and the platform delivers to the coordinating CSIRT and ENISA at the same time. It carries a mandatory channel for the Article 14 cascade and a voluntary channel open to anyone. This page covers what it collects at each stage, who may file on which channel, and the four things it does not do.
What the SRP is, in one paragraph
Article 16 of the Cyber Resilience Act establishes a single reporting platform to simplify manufacturers' reporting obligations. Article 16(1) has the platform established by ENISA and its day-to-day operations managed and maintained by ENISA, with Member States and ENISA putting in place their own electronic notification end-points. You submit through the end-point of your coordinating CSIRT, and Article 14(7) makes that submission simultaneously accessible to ENISA. Under Article 16(2) the receiving CSIRT then disseminates it to the coordinating CSIRTs of the territories where you indicated the product is available. The mandatory channel carries the Article 14 cascade, an early warning within 24 hours, a full notification within 72 hours and a final report. A separate voluntary channel under Article 15 is open to any person and accepts a wider set of report types. The platform is scheduled to be operational by 11 September 2026.
Filing once sounds simple, and it is simple only if you can produce the required fields under a clock that started the moment you became aware. That is where the preparation goes.
Two channels, different rules
The mandatory channel is narrow and binds manufacturers. The voluntary channel is wide and binds nobody. Collapsing the two is the most common misreading of the platform.
Mandatory
Article 14- Who may file
- Manufacturers, and open-source software stewards where they are involved with products with digital elements.
- What it accepts
- Actively exploited vulnerabilities contained in the product, and severe incidents having an impact on the security of the product. A high bar on both counts.
- When
- From 11 September 2026, the date the platform is scheduled to be operational.
Voluntary
Article 15- Who may file
- Any natural or legal person. Security researchers, downstream integrators, customers and other vendors all qualify.
- What it accepts
- Vulnerabilities in general rather than only exploited ones, cyber threats affecting a product's risk profile, incidents below the severe threshold, and near misses that could have become an incident.
- When
- ENISA has indicated the voluntary function arrives after the mandatory channel rather than alongside it.
What the form collects, by stage
ENISA marks each field to show how it behaves as a report matures. A field that is mandatory at 24 hours becomes a confirmed field later, and a field that is optional at 24 hours often becomes mandatory at 72 hours once you have had time to assess.
A core requirement at that stage. The report is incomplete without it.
The value given earlier is carried forward, then confirmed or refined at the later stage.
Provide it if you have it. Not required at that stage.
The platform fills it for you, typically a timestamp or the reporter identity.
Provided if applicable to the notification.
Fields common to every notification
| Field | 24h | 72h | Final |
|---|---|---|---|
| Notification type (vulnerability or incident) | Mandatory | Confirmed | Confirmed |
| Notification level (24h, 72h, final) | Mandatory | Mandatory | Mandatory |
| Reporting time and reporter identity | Automated | Automated | Automated |
| Name of manufacturer or open-source steward | Mandatory | Confirmed | Confirmed |
| Product | Mandatory | Confirmed | Confirmed |
| Product type (default, important, critical) | Optional | Confirmed | Confirmed |
| Product category (Annex III or IV, if not default) | Optional | Confirmed | Confirmed |
| Member States where the product is available | If applicable | Confirmed | Confirmed |
| Title | Mandatory | Confirmed | Confirmed |
The early warning is genuinely lightweight, which is the design. Vulnerability notifications then add exploitation and identifier fields, and incident notifications add nature, assessment and root-cause fields. The full field map covers both branches stage by stage.
What happens after you file, and when it is held back
The receiving CSIRT disseminates your notification onward without delay by default. Article 16(2) then builds in an exception that most summaries of the platform leave out entirely.
Dissemination can be delayed on request
In exceptional circumstances, and in particular on the manufacturer's request in light of the sensitivity indicated under Article 14(2), point (a), the coordinating CSIRT may delay onward dissemination on justified cybersecurity-related grounds, for a period strictly necessary. A vulnerability under a coordinated disclosure procedure per Article 12(1) of the NIS2 Directive is named as a case where this applies.
A withholding CSIRT must answer to ENISA
Where a CSIRT decides to withhold, it must immediately inform ENISA of the decision, provide a justification, and indicate when it will disseminate. ENISA may support the CSIRT on applying the cybersecurity grounds. The delay is a supervised exception rather than a discretionary pause.
A narrower gate exists for single-Member-State exploitation
Article 16(2) adds a particularly exceptional tier where the manufacturer indicates under Article 14(2), point (b), that the vulnerability has been actively exploited by a malicious actor and, per the information available, in no Member State other than the one notified, or that further dissemination would supply information contrary to that Member State's essential interests.
The practical consequence is that the sensitivity indication on your 24-hour filing is a real lever. It is the input the withholding decision is weighed against, so it deserves a considered answer rather than a default one.
Four things the SRP does not do
The platform is an exit point. Everything that decides whether you reach it happens on your side first.
There is no manufacturer submission API
Article 14(7) routes notifications through the platform, and ENISA does not currently expose a submission API for manufacturers. The filing itself is a manual step whatever tooling sits behind it. Any vendor claiming automatic filing to the SRP is describing something the platform does not offer.
The SRP does not decide whether you must report
The awareness judgement, the active exploitation finding and the severity assessment all happen on your side before the platform is involved. The SRP receives a decision you have already made and starts no clocks of its own.
It does not replace your Article 13 obligations
The single point of contact, the coordinated vulnerability disclosure policy and the intake channel that tells you a thing is being exploited are all your responsibility. The SRP is the exit, and it presumes the entrance already exists.
It does not report for you under NIS2 or GDPR
One event can trigger CRA, NIS2 and GDPR duties at once, on different clocks and to different recipients. The SRP covers the CRA leg. The others still need filing separately.
Going deeper
Each of these takes one part of the platform further.
Inside the SRP Reporting Form: The Data Fields You Need at 24h, 72h, and Final
ENISA has published the data fields its Single Reporting Platform will collect at each stage of a CRA notification. Here is the full field map for vulnerabilities and incidents, what is mandatory when, and why the staged design rewards preparation.
Voluntary Reporting on the SRP: What the Platform Accepts Beyond Mandatory Notifications
The Single Reporting Platform is built for mandatory CRA notifications, but it will also accept voluntary reports from anyone, covering vulnerabilities, cyber threats, incidents, and near misses. Here is who can use it, what it accepts, and when the function turns on.
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.
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.
Frequently asked
What is the SRP under the Cyber Resilience Act?
Who can report through the SRP?
What can you report voluntarily on the SRP?
When does the ENISA SRP go live?
Does the ENISA SRP have an API for manufacturers?
What information does the SRP ask for at 24 hours?
Do you report to ENISA or to your national CSIRT?
Arrive at the SRP with the fields already filled
CVD Portal takes reports through a branded disclosure portal, starts the Article 14 timers the moment a case is flagged as exploited, drives triage, and assembles a submission-ready package in the shape the platform asks for. A human still files it, because the platform offers no other route.
Receiving and tracking reports is free. EU data residency by default, no card required to start.
CVD 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.