ENISA Single Reporting Platform: how to report under CRA
The ENISA Single Reporting Platform has been live since 11 Sep 2026: how CRA reports work, which deadlines apply and the role of the coordinating CSIRT.
Hendrik-Hauke Rux6 min readDeutsche Fassung
ENISA's Single Reporting Platform (SRP) has been operating since 11 September 2026. Manufacturers use it to report actively exploited vulnerabilities and severe incidents under Art. 14 CRA; the report goes to the competent coordinating CSIRT, and ENISA gets simultaneous access.
ENISA describes the launch as 'initial operating capability': core functions are running, more features are planned. For manufacturers: the obligation is live and so is the channel. See our post on CRA reporting for the deadline basics.
What is the Single Reporting Platform?
Art. 16 CRA tasks ENISA with establishing, managing and maintaining a single reporting platform. Instead of reporting separately in each member state, manufacturers submit once. The coordinating CSIRT distributes the report to the CSIRTs of member states where the product is made available. According to ENISA, the platform includes security measures to protect the confidentiality of submitted information.
Prepare registration
ENISA describes the exact registration steps in its manuals. Regardless, clarify internally beforehand:
- Who reports on behalf of the company, and who is the deputy?
- Which main establishment is decisive – and therefore which CSIRT coordinates?
- Which product and version data must be at hand quickly?
How a report flows
Three reporting stages under Art. 14 CRA
- 1. Early warning
- ≤ 24h
- 2. Notification
- ≤ 72h
- 3. Final report
- 14 days after fix / 1 month after incident notification
Early warning (24h)
The first stage signals that an actively exploited vulnerability or severe incident exists and, where applicable, names the member states where the product is made available. Completeness is not the goal here; speed is.
Notification (72h)
The second stage adds general product information, the nature of the exploit or incident, corrective or mitigating measures taken, measures users can take and an indication of how sensitive the information is.
Final report
For vulnerabilities no later than 14 days after a corrective measure is available, with description, severity, information on the actor (if known) and security update details. For severe incidents within one month of the notification, with root cause and mitigation.
The competent CSIRT in Germany
The coordinating CSIRT is the one of the member state where the manufacturer has its main establishment in the EU. For manufacturers based in Germany, the BSI is the central CRA contact. The national implementation act, which also assigns market surveillance to the BSI, is going through parliament; the reporting obligation applies directly from the regulation regardless.
User information under Art. 14(8)
Reporting to authorities is only half the duty. After becoming aware, you must also inform affected users – and where appropriate the public – about the vulnerability or incident and about mitigation and protective measures, where appropriate in a structured, machine-readable and easily automatically processable format. Plan channels: security advisories, CSAF documents, customer portal.
What about open-source stewards?
According to ENISA, reporting obligations for open-source stewards under Art. 24(3) only apply from 11 December 2027 – not from the manufacturer start date. More on stewards in open source under the CRA.
Checklist for your first report
So that your first real report is not improvised, keep this information available at all times:
| Information | Where it typically lives | Needed for |
|---|---|---|
| Company data, main establishment | Master data | All stages |
| Product name, versions, member states | Product inventory, sales | Early warning |
| Affected component | SBOM | Notification |
| Mitigations for users | Engineering, support | Notification, customer notice |
| Patch version and availability | Release management | Final report |
Practical examples
Manufacturer based in Germany, selling across the EU
A Hamburg-based maker of access control systems sells in Germany, Austria and the Netherlands. It reports once via the SRP; the German CSIRT coordinates and forwards the report to the bodies of the other affected member states. It does not need to inform three authorities separately.
Agency as supplier
An agency builds the app of a client who is the manufacturer. The agency does not report itself but supplies the technical details the client needs for the report fields. It makes sense for the agency to hand over its information already structured along the three reporting stages.
Putting first impressions in context
The platform has only been running for a few days, and ENISA has announced further features. Do not rely on details that may still change; keep your data ready independently of the platform. Check the ENISA FAQ regularly for updates and adjust your runbook.
Common misunderstandings
- 'Reporting to ENISA replaces customer information.' No, they are separate duties.
- 'We will wait until the platform is complete.' The obligation has applied since 11 September 2026, regardless of future features.
Prepare reporting data with Nuowei
Nuowei (beta, launch November 2026) keeps product, version and SBOM data ready so you can fill in early-warning, notification and final-report fields quickly. You submit on the SRP yourself. If you still have gaps, start with the reporting readiness check – or join the waitlist.
No. You report once via the SRP; the coordinating CSIRT forwards to affected member states and ENISA gets simultaneous access.
The one of the member state of your main EU establishment – for German manufacturers the BSI is the central contact.
ENISA calls the launch initial operating capability; further features are planned.