How CRA vulnerability reporting works in practice: SRP submission, CSIRT follow-up and informing users step by step.
The reporting process of the Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA, is the sequence of steps by which a manufacturer reports an actively exploited vulnerability or a serious security incident to the competent authorities and simultaneously informs affected users. It begins as soon as the manufacturer becomes aware of the event and ends only with the final report and the completed notification of users. 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 security of the product.
Recipients are always two bodies at the same time: the CSIRT named as coordinator and ENISA. Both are reached by the manufacturer via the same report, submitted through the Single Reporting Platform. The competent CSIRT is the one corresponding to the manufacturer’s main establishment in the Union.
Which deadlines apply to the individual reporting stages is discussed in detail in the sister article on reporting deadlines. This article focuses on the process: who does what, when and to whom.
Why the report itself is the easy part
Experience shows that manufacturers underestimate the organizational effort and overestimate the technical one. Submitting the report via the platform is a manageable form-filling task. More demanding is everything that happens around the mere submission: the follow-up questions from the responsible CSIRT and timely informing of your users.
The following descriptions are based on the platform’s test operation (status June 2026). The fields and workflows are not final and may change before the platform goes live.
Registration on the Single Reporting Platform
You need an EU Login for access, a personal account that is later associated with the company. During registration you select the national endpoint yourself, i.e., the CSIRT responsible for you. A German company would choose the endpoint “CSIRT Germany”.
Selecting the correct CSIRT is your responsibility. The portal does not verify it; ENISA expects that you have identified the competent CSIRT in advance. Afterwards the CSIRT validates the link between person and manufacturer, for example by phone or email. Important for practice: this validation is not a prerequisite for a valid report. You can report even if the account has not yet been validated.
The three reporting stages as a form
The report proceeds in three stages, which appear in the portal as sequential forms.
- Early Warning: The first stage requires only a few details, such as title, summary, affected manufacturer and the member states where the product is available. The choice of distribution countries determines which additional national CSIRTs are notified.
- Detailed notification (72h Notification): The second stage adds substantive information, for vulnerabilities for example the nature of the exploitation and the mitigation measures taken.
- Final report: The third stage contains the comprehensive description. Once submitted, the report is closed; no further changes are possible.
How to use the platform step by step and the exact timing for the three stages are described in detail in the detail article on reporting deadlines.
What happens after the report? CSIRT follow-up questions
Submitting the report does not end the process. The CSIRT named as coordinator, which receives the report first, can require the manufacturer to provide an interim report on relevant status updates regarding the vulnerability or security incident. You should therefore expect further exchange after the report and keep an available contact person internally.
On the platform the field “Additional Notes” serves 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 report. In the test operation the dashboard shows a notice 48 hours after the initial report that the follow-up report (due within 72 hours at the latest) is still outstanding. Which consequences a truly missed follow-up report will have is not yet known. You should monitor developments until the platform is released.
The real challenge How to 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 obligation, communication and time pressure converge here.
Once a manufacturer becomes aware of an actively exploited vulnerability or a serious security incident, they inform the affected users and, if necessary, all users about the event. If required, they also provide information on risk mitigation and corrective measures that 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 that these details must be made public or distributed indiscriminately. Where appropriate, manufacturers can limit detailed information to the affected users or customers. This is especially true for products used 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 the manufacturer fails to inform users in time, the CSIRTs named as coordinators can provide this information instead if they consider it proportionate and necessary. User notification cannot simply be taken off your hands without the authority communicating externally on your behalf. That is a good reason to keep communication under your control.
Upstream of this is the central point of contact. Manufacturers must designate a central point of contact that allows users to communicate directly and quickly with them, for example to facilitate the reporting of vulnerabilities. User information and guidance must also include the central contact point where vulnerabilities can be reported and the coordinated disclosure concept can be found, as well as 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 networked machine controller with remote maintenance you can reach affected operators directly via stored contact data and a security advisory without making the vulnerability widely public. The prerequisite is that you know where your products are deployed and that you have a functioning communication channel to them.
How well are you prepared for the CRA?
The readiness check shows in a few minutes where your product stands regarding the reporting process, vulnerability management and documentation.
A PSIRT consolidates reporting authority and user notification
The following section is a practical recommendation from Secuvise and not a requirement of the CRA. The regulation does not prescribe a specific organizational model; it only requires that the obligations are met.
In practice a Product Security Incident Response Team, or PSIRT, has proven effective. This is a fixed team with clear roles that brings together all three strands of the reporting process: the technical report to the platform and authority, the exchange with the CSIRT and notifying the company’s own users.
Why is this consolidation worthwhile? The three strands run in parallel under time pressure and are interdependent. An early warning must be sent within 24 hours while technical analysis and user communication are prepared at the same time. If platform access, authority contact and communication channels are held by different people without a coordinated process, time is lost in an emergency. A PSIRT records responsibilities in advance: who holds the EU Login, who decides on classification, who manages user communication, who keeps the line to the CSIRT.
Operationally a PSIRT performs triage of incoming reports, assesses whether a reportable event exists, makes timely reports in all three stages, answers CSIRT follow-up questions and controls the risk-based informing of users. This turns the scattered individual obligations of the CRA into a continuous, rehearsed workflow.
The reporting process at a glance
The following table assigns the phases of the process to the tasks, responsibilities and respective addressees. The PSIRT role is a practical recommendation, not a CRA requirement.
| Phase | Task | Responsibility (PSIRT role) | Addressee/target |
|---|---|---|---|
| Discovery | Record indication of vulnerability or incident (internally or via the central point of contact) | Triage lead | internal |
| Triage | Assess whether an actively exploited vulnerability or serious incident exists; record time of knowledge | Triage lead | internal |
| Early warning | Submit early warning via the platform | Reporting officer (EU Login) | CSIRT + ENISA |
| Notification | Supplement substantive information with assessment and measures | Reporting officer | CSIRT + ENISA |
| Final report | Prepare and submit final report; answer CSIRT follow-up questions | Reporting officer | CSIRT + ENISA |
| User notification | Inform affected and, if applicable, all users on a risk-based basis, possibly about corrective measures | Communications officer | affected users |
What you should set up now
The obligation applies from 11 September 2026. Until then you can establish the organizational prerequisites without time pressure. Four steps make sense.
- Designate 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 that is possible.
- Define roles, ideally combined in a PSIRT, so that in an emergency it is clear who reports, who decides and who communicates.
- Keep communication templates ready for informing users so you don’t have to draft messages under time pressure.
Those who establish these basics now turn the reporting process from an improvised emergency into a rehearsed routine.
Who reports who decides who communicates
Triage lead, reporting officer, communications officer: this set describes who is responsible for which phase, where the information for each reporting stage comes from and who the recipients are. You enter your names and document the process.
Download templates for free
