How CRA vulnerability reporting works in practice — SRP submission, CSIRT follow-up and user notification 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 while simultaneously informing affected users. It starts as soon as the manufacturer becomes aware of the event and ends only with the final report and completed user notifications. The actual submission on the platform is only one part of this.
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.
Recipients are always two authorities 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 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 on reporting deadlines. This article focuses on the process: who does what, when and to whom.
Why the notification itself is the easy part
In practice, manufacturers tend to underestimate the organizational effort and overestimate the technical one. The technical act of reporting via the platform is a manageable form-filling task. The descriptions below are based on the platform’s test operation (status June 2026). Fields and procedures are not final and may change before release.
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 check this; ENISA assumes that you have identified 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 report even if the account has not yet been validated.
The three reporting stages as a form
Reporting proceeds in three stages, which appear in the portal as successive 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 selection of distribution countries determines which additional national CSIRTs are notified.
- Detailed notification (72h Notification): The second stage supplements the content, for vulnerabilities for example the method of exploitation and the remediation measures taken.
- Final report: The third stage contains the full description. Once submitted the report is closed; no further changes are possible.
How to use the platform step by step and the exact timing of the three stages are described in detail in the detail article on reporting deadlines.
What happens after submission? CSIRT follow-up questions
Submission does not end the process. The CSIRT named as coordinator that receives the report first can, if necessary, ask the manufacturer to provide an interim report on relevant status updates to the vulnerability or security incident. You should therefore expect further exchanges after filing and ensure an internally reachable contact person is available.
On the platform the field “Additional Notes” is used for exchange with the national CSIRT. You can use this channel to provide status updates and supplementary information.
One open question concerns the consequences of a missed follow-up submission. In the test operation the dashboard shows a notice 48 hours after the initial report that the follow-up submission (due at the latest after 72 hours) is still outstanding. What effects a truly missed follow-up will have is not yet known. You should follow 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 duty, communication and time pressure come together here.
Once a manufacturer becomes aware of an actively exploited vulnerability or a serious security incident, they inform the affected users and, where appropriate, all users about the event. If necessary, they also inform about risk mitigation and corrective measures users can take, possibly in a structured, machine‑readable format.
This duty must be interpreted on a risk basis. 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 distributed indiscriminately. Where appropriate, manufacturers can limit the dissemination of detailed information to affected users or customers. This applies especially to 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 the manufacturer fails to inform users in time, the CSIRTs named as coordinators may provide this information on their behalf if they consider it proportionate and necessary. User notification therefore cannot simply be outsourced without the authority communicating externally on your behalf. That is a good reason to keep communications under your own control.
A prerequisite is the central point of contact. Manufacturers must designate a central point of contact that allows users to communicate directly and quickly with them, including to report vulnerabilities. The information and guidance for users must also give the central contact where vulnerabilities can be reported and where the coordinated disclosure policy can be found, the type of technical security support offered, and the end date of the support period. Building these channels only once an incident occurs wastes valuable time.
An example from mechanical engineering: for a networked machine controller with remote maintenance you reach affected operators directly via stored contact details and a security advisory without broadly publishing the vulnerability. The prerequisite is that you know where your products are in use and have a functioning communication channel to them.
How ready are you for the CRA?
The readiness check shows in minutes where your product stands regarding reporting process, vulnerability management and documentation.
A PSIRT bundles reporting, authority contact and user notification
The following section is a practice recommendation from Secuvise and not a CRA requirement. The regulation does not prescribe a specific organizational model; it only requires that obligations are fulfilled.
In practice a Product Security Incident Response Team, or PSIRT, has proven 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, the exchange with the CSIRT and informing your own users.
Why is this consolidation worthwhile? The three strands run in parallel under time pressure and interact. An early warning must be sent within 24 hours while technical analysis is ongoing and user communication is being prepared. If platform access, authority contact and communication channels are split across different people without an aligned process, time is lost in an emergency. A PSIRT defines responsibilities in advance: who holds the EU Login, who decides on classification, who handles user communication, who liaises 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 the risk‑based notification 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 tasks, responsibilities and the respective recipient. The PSIRT role is a practical recommendation, not a CRA requirement.
| Phase | Task | Responsibility (PSIRT role) | Recipient/goal |
|---|---|---|---|
| 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 the report 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 basis, possibly with 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 sensible steps:
- Designate the central point of contact and the central reporting contact and include these 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.
- Prepare communication templates for informing users so you do not have to draft them under time pressure.
Those who establish these basics now turn the reporting process from an improvised emergency into a practiced routine. If you would like to assess how the reporting process specifically affects your products, processes and responsibilities, this can be clarified in a non‑binding conversation.
Reporting process setup: we support you
From the central point of contact to platform access and the PSIRT: we help you set up a practical CRA reporting process.
