Inside the ENISA Single Reporting Platform: How CRA Vulnerability Reports Actually Flow
The ENISA Single Reporting Platform (SRP) is the one system through which every CRA vulnerability report must flow from 11 September 2026. One submission. One platform. Routed automatically to the right authorities.
The catch: as of late June 2026, the platform is not yet live. ENISA has committed to having it operational by the reporting start date, but the registration instructions, access mechanics, and onboarding materials are still being published. That leaves manufacturers with a narrow window - and a clear imperative to build their internal process now, before the tool arrives.
This article is general guidance, not legal advice. For binding interpretations, consult the official regulation text or qualified legal counsel.
What the SRP actually is - and what it isn't
The SRP is established under Article 16 of Regulation (EU) 2024/2847 (the Cyber Resilience Act). Its purpose is consolidation. Before it existed, a manufacturer selling into multiple EU Member States would theoretically need to notify each national CSIRT separately. The SRP eliminates that.
Manufacturers submit notifications electronically through the platform, which automatically routes them to the designated CSIRT coordinator (based on the manufacturer's main establishment) and ENISA simultaneously. The coordinator CSIRT then disseminates the notification to CSIRTs in other Member States where the product is available - that secondary routing is the CSIRT's job, not yours.
A few things the SRP is not:
- Not an API (yet). ENISA has confirmed no SRP API will be provided at this stage. Submissions are manual, through an online form. That means a qualified person must be ready to log in and populate fields under time pressure.
- Not a substitute for internal triage. The platform receives your report; it does not help you decide whether a signal qualifies as active exploitation. That judgment happens before you open a browser.
- Not optional. Emailing your national CSIRT directly is not a valid substitute. The SRP is the only mandatory channel.
Open-source software stewards also report through the SRP, to the extent they are involved with products with digital elements under Article 24(3).
How a report flows through the platform
Understanding the flow helps you design the internal process that feeds it. There are three submission stages, all through the same platform endpoint.
Filed within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident. At this stage you do not need a root cause analysis or a patch. You confirm awareness, flag whether malicious or unlawful acts are suspected, and provide an initial severity assessment. The clock starts at awareness, not forensic confirmation — if you have reasonable belief of active exploitation, report.
A fuller account submitted within 72 hours. This should include an initial assessment of severity and impact, affected product versions, and any corrective or mitigating measures already taken. The platform routes this to the same coordinator CSIRT and ENISA simultaneously.
Due within 14 days of a corrective or mitigating measure being available for actively exploited vulnerabilities, or within one month of the 72-hour notification for severe incidents. This is a description of the vulnerability or incident, its severity and impact, and the remediation applied. The final report is tied to a fix being available — you cannot file it on a fixed calendar date if the fix isn't ready.
Once submitted, the coordinator CSIRT disseminates the notification without delay to other relevant CSIRTs in Member States where the product is available, and to market surveillance authorities as needed. For sensitive reports, dissemination can be delayed - but that brake belongs to the authority, not to you. You cannot unilaterally hold back a report on sensitivity grounds.
Platform status: what's confirmed, what's still pending
Here is an honest summary of where things stand as of late June 2026.
| Item | Status | Notes |
|---|---|---|
| Go-live date | ✅ Confirmed | 11 September 2026, coinciding with mandatory reporting start |
| Testing period | ✅ Confirmed | A testing period is expected before go-live |
| Registration instructions & access manual | ⚠️ Pending | ENISA indicated these would be published during June 2026; verify on the ENISA SRP page |
| Reporting fields (data structure) | ✅ Published | ENISA published the required data fields in its updated FAQ (Q16) |
| API access | ❌ Not provided | No SRP API at this stage; submissions are manual |
| Voluntary reporting | ⚠️ Post-launch | Voluntary reporting functionality enabled after 11 September 2026 |
| Helpdesk (SME focus) | ✅ Planned | ENISA will operate a helpdesk, with particular attention to SMEs |
The European Commission's CRA reporting page confirms that ENISA launched a public tender and procured services from a contractor to assist with the development of the SRP, and that a testing period is expected before the go-live date. Watch both the Commission page and the ENISA SRP page for registration details as they are published.
The obligation is fixed; the tool is still arriving. The 24-hour, 72-hour, and 14-day deadlines apply in full from 11 September 2026 regardless of when ENISA publishes the final onboarding materials. Build your internal process now — do not wait for the platform to go live before starting.
Who must file - and who your coordinator CSIRT is
The reporting duty sits with the manufacturer of the product with digital elements placed on the EU market. If you are an importer or distributor, the obligation falls on the manufacturer - but you should know who that is and whether they have a process in place.
Your coordinator CSIRT is determined by where your organisation has its main establishment in the EU. If you are based outside the EU, it is determined by where your EU-authorised representative is established. Manufacturers select the coordinating CSIRT at the point of filing; that CSIRT then disseminates the notification to other Member States where the product is available.
One practical note: micro and small enterprises are exempt from fines specifically for missing the 24-hour early warning timing, but they are not exempt from reporting - and the 72-hour and final-report obligations carry no such relief for any company size.
What to build before the platform goes live
The work that matters most right now does not depend on the SRP being accessible. Here is what to put in place.
1. Designate who watches and who files
Identify the person responsible for monitoring exploitation signals - CVE feeds, threat intelligence, your coordinated vulnerability disclosure (CVD) inbox, and customer reports. Separately, identify who has authority to make the call that a signal qualifies as "actively exploited" and who submits the report. Name a backup for each role. Write it down.
2. Map your products to the filing entity
If you have multiple product lines or legal entities, establish which legal entity is the manufacturer for each product. The SRP registration will require your legal name, main establishment address, and the products you are registering. Resolve any ambiguity before a real incident forces the question.
3. Pre-draft your early-warning template
The 24-hour early warning does not require a root cause analysis. It requires: confirmation of awareness, whether malicious acts are suspected, and an initial severity assessment. Draft a template now. Get it approved. The 24-hour clock does not pause while you write from scratch.
4. Wire your CVD intake into this process
Your coordinated vulnerability disclosure process is the upstream feed for CRA reporting. A researcher report that confirms active exploitation in the wild starts the Article 14 clock. Make sure your CVD intake has a clear escalation path to the person who files SRP reports.
5. Know when the final report is due
The final report is not due on a fixed calendar date after the incident. It is due within 14 days of a corrective or mitigating measure being available for actively exploited vulnerabilities, and within one month of the 72-hour notification for severe incidents. That means your fix timeline directly affects your reporting timeline. Track both together.
6. Register and do a dry run as soon as the platform opens
When ENISA publishes the access manual and registration instructions, register immediately. Do not wait for a real incident to be your first attempt at navigating the platform. Run a tabletop exercise timed from signal to filed early warning.
A readiness check: where does your process stand?
Use this widget to assess the gaps in your current CRA reporting readiness before the SRP goes live.
Where to go next
- Check whether your products are in scope on the CRA deadlines & timeline page.
- Review the CRA compliance checklist for the broader sequenced readiness roadmap.
- Read the coordinated vulnerability disclosure guide to make sure your CVD process feeds correctly into Article 14 reporting.
- Monitor the ENISA SRP page and the European Commission CRA reporting page for registration instructions as they are published.
The SRP onboarding materials, registration instructions, and any implementing acts that affect report formats will land in the coming weeks. Subscribe to The CRA Brief at /subscribe to get a plain-English summary the moment anything changes — so you can register and run your dry run before 11 September arrives.
Related reading
CRA and AI Act: Do You Have to Comply with Both - and Can the Work Be Shared?
If your product has digital elements and contains AI, both the Cyber Resilience Act and the EU AI Act can apply. Here's how the two regimes interact - and how one cybersecurity workstream can serve both.
Your CRA Compliance Checklist: A Sequenced Readiness Roadmap
A practical, deadline-ordered CRA compliance checklist for manufacturers, importers and distributors. Know what to do first, what can wait, and why September 2026 matters now.
CE Marking and the EU Declaration of Conformity Under the CRA: What You Sign and What Sits Behind It
For most products with digital elements, CE marking under the CRA means one thing: you self-assess, build a technical file, and sign the EU Declaration of Conformity yourself. Here is exactly how that works.