How CRA vulnerability reporting works in practice: SRP submission, CSIRT follow‑up questions and user notification explained step by step.
The reporting process of the Cyber Resilience Act (Regulation (EU) 2024/2847), hereinafter CRA, is the sequence of steps a manufacturer follows to report an actively exploited vulnerability or a serious security incident to the competent authorities while simultaneously informing affected users. It begins as soon as the manufacturer becomes aware of the event and only concludes with the final report and completed user notifications. The actual submission on the platform is only one part of the process.
Two types of events trigger the reporting obligation. First, any actively exploited vulnerability contained in a product with digital elements of which the manufacturer becomes aware. Second, any serious security incident that affects the product’s security.
There are always two recipients simultaneously: the CSIRT named as coordinator and ENISA. The manufacturer reaches both via the same submission transmitted through the single reporting platform. The competent CSIRT is determined by the manufacturer’s main establishment in the Union.
Which deadlines apply to the individual reporting stages is covered in detail in the sister article to the reporting deadlines. Here we focus on the process: who does what, when and towards whom.
Why the notification itself is the easy part
In practice, manufacturers tend to underestimate the organisational effort and overestimate the technical task. The technical submission via the platform is a manageable form-filling exercise. The following descriptions are based on the platform’s test operation (status June 2026). Fields and procedures are not final and may change before the platform is officially released.
Registration on the single reporting platform
Access requires an EU‑Login, a personal account that is then associated with the company. During registration you choose the national endpoint yourself, i.e. the CSIRT responsible for you. A German company selects the endpoint “CSIRT Germany”.
Selecting the correct CSIRT is your responsibility. The portal does not verify it; ENISA assumes you have determined the competent CSIRT in advance. The CSIRT then validates the association between person and manufacturer, for example by phone or e‑mail. Important in practice: this validation is not a prerequisite for an effective report. You can submit a report even if the account has not yet been validated.
The three reporting stages as a form
The report proceeds in three stages, presented in the portal as successive forms.
- Early warning: The first stage asks for only a few details, such as title, summary, affected manufacturer and the Member States where the product is available. The selection of distribution countries determines which additional national CSIRTs are notified.
- Detailed notification (72h notification): The second stage supplements the substantive details; for vulnerabilities this includes the type of exploitation and the mitigation measures taken.
- Final report: The third stage contains the full description. Submitting it closes the report; no further changes are possible afterwards.
How to operate the platform step by step and the exact deadlines for the three stages are described in detail in the detail article to the reporting deadlines.
What happens after the submission The CSIRT follow‑up questions
Submitting the form does not end the process. The CSIRT named as coordinator, which receives the submission first, can, if necessary, require the manufacturer to provide an interim report on relevant status updates regarding the vulnerability or security incident. Expect that further exchange may be required after the submission and ensure you have an internally reachable contact person available.
On the platform the field “Additional Notes” is used for exchange with the national CSIRT. Status updates and supplementary information can be transmitted via this channel.
One open question concerns the consequences of a missed follow‑up notification. In the test operation the dashboard displays a notice 48 hours after the initial submission indicating that the follow‑up (due at the latest after 72 hours) is still outstanding. The actual consequences of a missed follow‑up are not yet known. Monitor further developments until the platform is released.
The real challenge How do you inform your users in time
In advisory practice it becomes clear: informing users is the most demanding strand of the process, not the platform submission itself. Legal obligations, communication and time pressure converge here.
After a manufacturer becomes aware of an actively exploited vulnerability or a serious security incident, they must inform affected users and, where appropriate, all users about the event. If necessary, they must also inform about risk mitigation and corrective measures users can take, possibly in a structured, machine‑readable format.
This obligation must be interpreted in a risk‑based way. According to the Commission’s draft guidelines, informing about an actively exploited vulnerability or a security incident does not mean these details must be made public or disseminated indiscriminately. Where appropriate, manufacturers can restrict the disclosure of detailed information to affected users or customers. This is particularly true for products in sensitive or critical environments where public disclosure of technical details could itself create new risks. Broader disclosure may become appropriate once the vulnerability is fixed or contained.
If a manufacturer fails to inform users in time, the CSIRTs named as coordinators can provide that information instead if they consider it proportionate and necessary. The authority will not, however, replace your user communication without communicating externally on your behalf. That is a good reason to keep communications under your own control.
A prerequisite is the central contact point. Manufacturers must designate a central point of contact that allows users to communicate directly and quickly with them, including to facilitate vulnerability reporting. User information and guidance must also include the central contact point where vulnerabilities can be reported and the coordinated disclosure concept can be found, the type of technical security support offered and the end date of the support period. Those who only set up these channels in an emergency lose valuable time.
An example from mechanical engineering: for a connected machine controller with remote service you can reach affected operators directly via recorded contact details and a security notice without making the vulnerability widely public. The prerequisite is that you know where your products are deployed and have a functioning communication path to them.
How ready are you for the CRA?
The readiness check shows in minutes where your product stands regarding the reporting process, vulnerability management and documentation.
A PSIRT brings together reporting, authority contact and user notification
The following section is a practical recommendation from Secuvise and not a CRA requirement. The regulation does not prescribe a specific organisational model; it only requires that obligations are met.
In practice a Product Security Incident Response Team, or PSIRT, proves effective. This is a dedicated team with clear roles that brings together all three strands of the reporting process: the technical report to the platform and authority, exchange with the CSIRT and informing the company’s users.
Why is this consolidation worthwhile? The three strands run in parallel under time pressure and are interdependent. The early warning must be sent within 24 hours while technical analysis runs and user communication is prepared. If platform access, authority contact and communication channels are handled by different people without a coordinated process, time will be lost in an emergency. A PSIRT defines responsibilities in advance: who holds the EU‑Login, who decides on classification, who handles user communication, who maintains contact with the CSIRT.
Operationally, a PSIRT performs triage of incoming reports, assesses whether a reportable event exists, submits timely reports in all three stages, answers CSIRT follow‑up questions and manages risk‑based user notification. This turns the CRA’s scattered individual obligations into a continuous, rehearsed workflow.
The reporting process at a glance
The following table assigns the phases of the process to tasks, responsibilities and the respective recipients. The PSIRT role is a practical recommendation, not a CRA prescription.
| Phase | Task | Responsibility (PSIRT role) | Recipient/target |
|---|---|---|---|
| Discovery | Record indication of vulnerability or incident (internally or via the central contact point) | Triage owner | internal |
| Triage | Assess whether an actively exploited vulnerability or serious incident exists; record time of knowledge | Triage owner | internal |
| Early warning | Submit early warning via the platform | Reporting owner (EU‑Login) | CSIRT + ENISA |
| Notification | Supplement substantive report with assessment and measures | Reporting owner | CSIRT + ENISA |
| Final report | Create and submit final report; answer CSIRT follow‑up questions | Reporting owner | CSIRT + ENISA |
| User notification | Inform affected and, if appropriate, all users in a risk‑based manner, possibly about corrective measures | Communications owner | affected users |
What you should set up now
The obligation applies from 11 September 2026. Until then you can establish the organisational prerequisites without time pressure. Four steps are useful.
- Name the central point of contact and the central contact point and include them in the user information (see above).
- Prepare platform access: set up EU‑Login, determine the competent CSIRT and run through registration in the test environment while possible.
- Define roles, ideally consolidated in a PSIRT, so it is clear in an emergency who reports, who decides and who communicates.
- Keep communication templates ready for informing users so you do not have to draft messages under time pressure.
Those who put these basics in place now turn the reporting process from emergency improvisation into a practised routine.
Who reports, who decides, who communicates
Triage owner, reporting owner, communications owner: the templates describe who is responsible for which phase, where the information for each reporting stage comes from and to whom it is sent. You insert names and document the process.
Vorlagen kostenlos herunterladen
