Once a manufacturer has decided that an event is reportable, the next question is mechanical but consequential: where does the report actually go? The CRA's answer is more sophisticated than a single regulator inbox. It establishes a routing architecture that delivers each notification to both ENISA and the relevant national authority simultaneously, with onward distribution to other affected member states where needed.
Understanding this architecture matters before an incident, not during one. The 24-hour early-warning window is no time to discover that you do not have credentials for the reporting platform or that you do not know which national CSIRT is yours. This post explains how the reporting pipeline is organised and what each party does with what you send.
This is the third post in our CRA reporting series. Earlier posts covered when reporting becomes mandatory and which vulnerabilities and incidents must be reported. The next post covers the timelines and follow-up obligations. For a single-page overview of the whole reporting regime, see our guide to which CRA reporting obligations apply, when they start, and how to be ready.
The single reporting platform
The CRA establishes a single reporting platform operated by ENISA as the common entry point for Article 14 notifications. The design goal is to give manufacturers one place to file, rather than forcing them to submit separately to multiple national bodies and EU institutions during a live incident.
When a manufacturer submits an early warning, a detailed notification, or a final report, it goes to this platform. The platform then handles distribution. This is the central concept: the manufacturer files once, and the system routes the notification to the parties that need it.
The platform is structured around national endpoints. Each member state designates a point of entry, and notifications are routed to the appropriate one alongside ENISA. In practice the manufacturer interacts with one electronic notification system, and the regulatory distribution happens behind it.
Who receives a report
A single Article 14 notification is not a single recipient event. It reaches two kinds of party at once.
ENISA
ENISA, the EU Agency for Cybersecurity, sits at the centre of the reporting architecture. It operates the platform and holds the EU-level view across all member states. ENISA's role is coordination and situational awareness: aggregating notifications, identifying patterns that cross borders, and supporting a coordinated response where an exploited vulnerability or severe incident has Union-wide implications.
ENISA also maintains the broader European vulnerability landscape, including the European vulnerability database work that complements national and global sources. We have written about the trajectory of this infrastructure in ENISA and the future of EU vulnerability disclosure.
There is an important safeguard in the design. ENISA's central role is paired with provisions that allow a manufacturer or a member state to restrict the onward distribution of particularly sensitive information, for example where wide circulation of technical detail would itself increase risk before a fix is available. The architecture balances broad situational awareness against the danger of amplifying an exploitable weakness.
The relevant national CSIRT
In parallel with ENISA, each notification reaches the CSIRT designated as coordinator in the relevant member state. The CSIRT (Computer Security Incident Response Team) is the operational national body that can act on the report: coordinate with affected organisations in its territory, issue advisories, and liaise with the manufacturer on response.
Which national CSIRT is "relevant" generally follows from where the manufacturer has its main establishment in the Union, with rules to assign a coordinator where the situation spans multiple states. The practical task for a manufacturer is to know, in advance, which national CSIRT it will be reporting through and to have a verified contact for it.
How onward notification flows
The value of routing through a single platform is what happens after submission. A vulnerability being actively exploited rarely respects borders. An exploited flaw in a widely deployed industrial controller can affect operators across many member states at once.
The platform and ENISA enable that cross-border picture. When a notification arrives, the architecture supports informing other affected member states' CSIRTs where the event has implications for them, so that national bodies across the Union can warn and coordinate with the organisations they protect. The manufacturer does not have to identify and contact each affected state individually. That distribution is a function of the coordinated system.
This is the structural reason the CRA chose central routing. It turns a manufacturer's single notification into coordinated, Union-wide situational awareness, which is the entire point of mandatory reporting.
How the manufacturer interacts with it
For the manufacturer, the interaction is an electronic submission, not a phone call or an email to a generic mailbox. There are a few practical realities to prepare for.
- Credentials and access. You need verified access to the reporting platform before an incident. Establishing access and confirming it works is a readiness task, not an incident task.
- Structured submissions. Each notification is structured around defined fields: what the vulnerability or incident is, which product and versions are affected, the nature of the exploitation or impact, indicators of compromise, and the measures taken or planned. Having this content pre-templated saves critical time.
- A consistent identity across the cascade. The early warning, the detailed notification, and the final report relate to the same event. They need to reference each other so authorities can follow the thread. Maintaining that linkage is part of getting the mechanics right.
- The national CSIRT relationship. Know which CSIRT is yours and keep a working contact. In a serious incident you may end up in direct dialogue with them, and a cold start under pressure is avoidable.
What this means for an SME without a PSIRT
A large manufacturer with an established product security incident response team will absorb this architecture into existing processes. The challenge is sharpest for the small and medium manufacturers who make up most of the CRA's population: makers of routers, sensors, controllers, connected consumer devices, and embedded firmware, many of whom have never filed a vulnerability report to any authority.
For them, the routing architecture is not the hard part, because the platform does the routing. The hard part is being ready to feed it: having verified access, knowing the responsible national CSIRT, and being able to produce a structured, accurate notification inside a 24-hour window while also managing the technical incident. Building that capability from zero is the subject of our guide to standing up a PSIRT from scratch and of the post on internal detection and escalation later in this series.
How CVD Portal fits the pipeline
CVD Portal sits on the manufacturer's side of this architecture. It does not replace the official reporting platform. It prepares you to use it well.
The portal captures incoming vulnerability reports through your branded disclosure channel, runs them through a CVSS-based triage that flags potential active exploitation, and generates structured notification content aligned to the early-warning, detailed-notification, and final-report stages of Article 14. It maintains the linkage between the three reports for a single event and keeps a complete audit trail of what was sent and when. The aim is that when an Article 14 event occurs, producing an accurate submission for the platform is a matter of minutes, not a scramble to assemble facts from scratch.
The bottom line
Article 14 reporting is organised around a single ENISA-operated platform that delivers each notification to ENISA and the relevant national CSIRT at once, with onward distribution to other affected member states built into the system. The manufacturer files once. The architecture turns that single filing into coordinated, Union-wide awareness.
For the manufacturer, the work is readiness: verified platform access, a known national CSIRT contact, and the ability to produce structured notifications fast. With the routing understood, the next question is timing, which the next post addresses in detail: reporting timelines and follow-up obligations.