How the CRA Reporting Process Works in Practice
Since September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents via ENISA's Single Reporting Platform. Filling in the form on the platform is quick. The harder part is everything around it: follow-up requests from the competent CSIRT and informing your own users in time.
The reporting process under the Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA, is a sequence of steps. With it, a manufacturer reports an actively exploited vulnerability or a severe incident to the competent bodies. In parallel, it informs the affected users. The process starts as soon as the manufacturer becomes aware of the event. It ends only with the final report and once users have been informed. Submitting the notification on the platform is just one part of it.
Contents
- The CRA reporting process in brief
- Why submitting the notification is the easy part
- What happens after you report? Follow-up requests from the CSIRT
- The real challenge: informing your users in time
- A PSIRT brings together reporting, authorities, and user notification
- Overview of the reporting process
- What you should set up now
The CRA reporting process in brief
Two types of event trigger the reporting obligation. The first is any actively exploited vulnerability contained in a product with digital elements that the manufacturer becomes aware of. The second is any severe incident having an impact on the security of the product.
There are always two recipients at the same time: the CSIRT designated as coordinator and ENISA. The manufacturer reaches both with the same notification, submitted via the single reporting platform. Which CSIRT is competent depends on the manufacturer's main establishment in the Union.
The deadlines for each reporting stage are covered in detail in our companion article on the CRA reporting deadlines. This article is about the process: who does what, when, and toward whom.
Why submitting the notification is the easy part
In our experience, manufacturers underestimate the organizational effort and overestimate the technical effort. Reporting on the platform is a manageable form-filling exercise. The descriptions below are based on the platform's test phase (as of June 2026). The platform has been in operation in a first release since September 11, 2026. Fields and workflows may still change as ENISA extends it.
Registering on the Single Reporting Platform
To get access, you need an EU Login, a personal account that is then linked to your company. During registration, you select the national endpoint yourself, that is, the CSIRT competent for you. As a manufacturer, you select the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment in the Union.
Choosing the right CSIRT is your responsibility. The portal does not check your choice; ENISA assumes that you have identified the competent CSIRT beforehand. The CSIRT then validates the link between the person and the manufacturer, for example by phone or email. One point matters in practice: this validation is not a precondition for a valid notification. You can report even if your account has not been validated yet.
The three reporting stages as forms
Reporting runs in three stages. In the portal, they appear as forms that build on each other.
- Early warning: The first stage asks for only a few details. Examples are a title, a summary, the manufacturer concerned, and the Member States in which the product is available. The countries you select determine which other national CSIRTs are notified.
- Detailed notification (“72h Notification”): The second stage adds the substance. For vulnerabilities, this includes the nature of the exploit and the corrective or mitigating measures taken.
- Final report: The third stage contains the full description. Once you submit it, the notification is closed and can no longer be changed.
How to use the platform step by step and how the deadlines for the three stages run is covered in our detailed article on the reporting deadlines.
What happens after you report? Follow-up requests from the CSIRT
Submitting the notification does not end the process. Where necessary, the CSIRT designated as coordinator that initially receives the notification may ask the manufacturer for an intermediate report on relevant status updates about the vulnerability or incident. Expect further exchanges after you report, and keep a contact person available internally for them.
On the platform, the “Additional Notes” field is used for exchanges with the national CSIRT. You can send status updates and additional information through this channel.
One question is still open: what happens if you miss a follow-up notification. In the test phase, the dashboard shows a notice 48 hours after the initial notification that the follow-up notification (due within 72 hours at the latest) is still outstanding. What consequences an actually missed follow-up notification has is not yet known. You should follow how this develops.
The real challenge: informing your users in time
In our consulting work, informing users turns out to be the most demanding strand of the process, not the platform notification itself. This is where the legal obligation, communication, and time pressure meet.
After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must inform the impacted users and, where appropriate, all users about it. Where necessary, it must also inform them about risk mitigation and corrective measures that users can deploy, where appropriate in a structured, machine-readable format.
This obligation should be interpreted on a risk basis. According to the Commission's guidance on applying the CRA, informing users about an exploited vulnerability or an incident does not mean making it public or disseminating it indiscriminately. Where appropriate, manufacturers can limit detailed information to the 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 has been fixed or contained.
If the manufacturer fails to inform users in time, the CSIRTs designated as coordinators may provide this information instead, where they consider it proportionate and necessary. So the only way this task is taken off your hands is for the authority to communicate externally in your place. That is a good reason to keep communication under your own control.
The single point of contact comes first. Manufacturers must designate a single point of contact that enables users to communicate with them directly and rapidly, including to make it easier to report vulnerabilities. The information and instructions for the user must name the single point of contact where vulnerabilities can be reported and where the policy on coordinated vulnerability disclosure can be found. They must also state the type of technical security support offered and the end date of the support period. If you only set up these channels when an incident occurs, you lose valuable time.
Take an example from machine building. For a connected machine controller with remote maintenance, you reach the affected operators directly through the contact details on file and a security advisory, without making the vulnerability broadly public. This requires that you know where your products are in use and that you have a working communication channel to them.
Not sure where your product stands?
We look at where your product stands on the reporting process, vulnerability handling, and documentation, and what to tackle next.
A PSIRT brings together reporting, authorities, and user notification
The following section is a practical recommendation from Secuvise, not a requirement of the CRA. The regulation does not prescribe a particular organizational model; it only requires that the obligations are met.
In practice, a product security incident response team (PSIRT) has proven itself. It is a permanent team with clear roles. It brings together all three strands of the reporting process: the notification to the platform and the authorities, the exchange with the CSIRT, and informing your own users.
Why is this worth it? The three strands run in parallel under time pressure and depend on each other. The early warning must be submitted within 24 hours, while the technical analysis is still running and user communication is being prepared. If platform access, contact with the authority, and communication channels sit with different people without an agreed process, you lose time when it counts. A PSIRT settles responsibilities in advance: who holds the EU Login, who decides on the classification, who handles user communication, and who stays in contact with the CSIRT.
Operationally, a PSIRT triages incoming reports and assesses whether a reportable event has occurred. It submits all three stages on time, answers CSIRT requests, and steers the risk-based information of users. This turns the scattered individual obligations of the CRA into one continuous, practiced workflow.
Overview of the reporting process
The following table maps the phases of the process to tasks, responsibility, and recipient. The PSIRT roles are a practical recommendation, not a CRA requirement.
| Phase | Task | Responsibility (PSIRT role) | Recipient or target |
|---|---|---|---|
| Discovery | Record the report of a vulnerability or incident (internally or via the single point of contact) | Triage lead | internal |
| Triage | Assess whether an actively exploited vulnerability or a severe incident exists; record the time of becoming aware | Triage lead | internal |
| Early warning | Submit the early warning via the platform | Reporting lead (EU Login) | CSIRT + ENISA |
| Notification | Add the detailed notification with assessment and measures | Reporting lead | CSIRT + ENISA |
| Closure | Prepare and submit the final report; answer CSIRT requests | Reporting lead | CSIRT + ENISA |
| User information | Inform affected users and, where appropriate, all users on a risk basis, including corrective measures where needed | Communication lead | affected users |
What you should set up now
The obligation has applied since September 11, 2026. If you have not yet put the organizational prerequisites in place, you should do so now. Four steps make sense:
- Designate the single point of contact and include it in the information for users (see above).
- Prepare platform access: set up an EU Login, determine the competent CSIRT, and go through the registration steps using ENISA's guide to registering as an assigned representative.
- Define the roles, ideally bundled in a PSIRT, so that 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 them under time pressure.
With these foundations in place, reporting becomes a practiced routine rather than improvisation in an emergency.
Who reports, who decides, who communicates
Triage lead, reporting lead, communication lead: the templates describe who is responsible for each phase, where the information for each reporting stage comes from, and where it goes. Enter your names and your process is documented.
