CRA Reporting Obligations for Vulnerabilities and Incidents

September 11, 2026 was the first binding date under the Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA. Since that day, manufacturers must report actively exploited vulnerabilities and severe incidents. This applies more than a year before the regulation applies in full on December 11, 2027.

If you have a product with digital elements on the EU market, you must be able to use the reporting channels in practice. They are a fixed part of the overall framework set by the Cyber Resilience Act.

Contents

1. What the CRA reporting obligations require
2. Reportable events: vulnerabilities and incidents
3. The three-stage reporting scheme and its deadlines
4. When the reporting deadline starts
5. Recipients: the CSIRT and ENISA via the single reporting platform
6. Informing affected users
7. Relief for microenterprises and small enterprises
8. Preparing for the reporting obligation

What the CRA reporting obligations require

The CRA reporting obligations require manufacturers to report actively exploited vulnerabilities and severe incidents that affect their products with digital elements. Each notification goes simultaneously to a computer security incident response team (CSIRT) designated as coordinator and to ENISA, the EU Agency for Cybersecurity. Reporting runs in three stages with fixed deadlines. The obligation is set out in Article 14 of the CRA.

Reportable events: vulnerabilities and incidents

The CRA distinguishes two triggering events. Which one applies determines the deadlines:

• Actively exploited vulnerability: a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. What counts is a documented real attack, not theoretical exploitability. The reporting obligation applies as soon as a manufacturer becomes aware of such a vulnerability in its product.
• Severe incident: an incident that negatively affects, or could negatively affect, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. An incident is also severe if it has led, or could lead, to malicious code being introduced or executed in the product itself or in a user's network and information systems.

The difference lies in the point of reference. A vulnerability is a defect in the product itself: in its code, its configuration, or its design. It counts as actively exploited only when reliable evidence shows a real attack, not merely because it could be exploited in theory. An incident, by contrast, is a security-relevant event connected to the product. It can also affect the manufacturer's own infrastructure if that infrastructure is critical to product security.

A typical example of a vulnerability is a buffer overflow in the routine that validates incoming network packets. An attacker can use it to run their own code and take over the system (remote code execution). The vulnerability is actively exploited as soon as documented evidence shows that it is actually being attacked. Here the defect sits in the product itself.

A severe incident looks different. If the manufacturer's code signing keys are lost or compromised, the authenticity and integrity of firmware or software updates can no longer be ensured. An attacker could then deliver malicious code that is signed and therefore accepted by the product. A second typical example is a compromise of the remote maintenance infrastructure the manufacturer uses to access products in the field. In both cases, the product itself is not defective. Instead, an event affects manufacturer systems that are critical to product security.

The two obligations are independent of each other. An actively exploited vulnerability and a severe incident can occur together, but they do not have to. The reporting obligation covers the product as a whole, including its remote data processing solutions. Software only counts as remote data processing if both of these conditions are met:

• Without this data processing, the product could not perform one of its functions.
• The manufacturer designed and developed the software itself, or had it built under its responsibility to its own specifications.

Who operates the software and on which servers it runs does not matter. A licensed off-the-shelf solution from a service provider does not meet the second condition.

Remote maintenance infrastructure is therefore remote data processing only if it supports a function of the product and the manufacturer developed it, or had it developed on its behalf. A backend developed by a third party does not release the manufacturer from its obligations. The manufacturer must address the risk at product level. For example, the product can cryptographically authenticate remote commands, check configuration changes for integrity, and raise an alarm when it behaves unusually.

Only the software components that carry out the remote processing for the product are covered, not the rest of the manufacturer's IT. The Commission's guidance explicitly names CI/CD pipelines and the distribution of security updates to edge locations as counterexamples. Whether an incident must be reported, however, depends on its impact on the security of the product, regardless of the system in which it occurred.

The three-stage reporting scheme and its deadlines

Both types of event follow the same three-stage reporting scheme. The first two stages are identical, the third differs.

1. Early warning notification: You must submit it without undue delay and in any event within 24 hours of becoming aware. At this stage, only brief information is required. For a vulnerability, this means the Member States in which, as far as you know, the affected product has been made available. For an incident, you must at least state whether it is suspected of being caused by unlawful or malicious acts.
2. Detailed notification: You must submit it within 72 hours of becoming aware. The CRA calls it a vulnerability notification or an incident notification. It contains general information about the affected product, the nature of the exploit or incident, and any corrective or mitigating measures already taken.
3. Final report: This is where the two types of event differ. For a vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available. The deadline is tied to the availability of the fix. For an incident, the final report is due within one month after the detailed 72-hour notification. Here the deadline runs from the second stage, not from the availability of a fix.

When the reporting deadline starts

All three deadlines start from the same point: the moment the manufacturer becomes aware. So the question is when a manufacturer counts as aware. The European Commission's guidance on applying the Cyber Resilience Act helps here. By its own account, the guidance is not binding on economic operators; only the Court of Justice of the European Union can give a binding interpretation. It does show, however, how the Commission understands becoming aware.

Under the guidance, a manufacturer is not yet aware when it merely receives an indication of a suspicious event, whether internally or from a customer, an authority, or the media. The 24-hour deadline only starts after an initial assessment shows with reasonable certainty that an actively exploited vulnerability exists or a severe incident has occurred. When the clock starts therefore depends on the circumstances of each case. Sometimes it is clear from the outset that a vulnerability is being exploited. Sometimes the assessment takes time.

This initial assessment is no license to delay. The guidance requires it to be carried out promptly, especially where there is a clearly significant risk. This moves the real bottleneck forward: without prepared processes, even this quick initial assessment is hard to deliver. The first day after a suspicion surfaces is the wrong time to settle responsibilities and assessment paths.

Many manufacturers are also subject to reporting obligations under other acts for the same incident, for example the NIS2 Directive. In its guidance, the Commission deliberately aligns the concept of becoming aware with the NIS2 implementing regulation and with the data protection guidelines on personal data breach notification. The aim is a consistent interpretation. If you are subject to NIS2, check whether additional reporting channels apply.

Recipients: the CSIRT and ENISA via the single reporting platform

A CRA notification never goes to just one recipient. The manufacturer reports an actively exploited vulnerability or a severe incident simultaneously to the CSIRT designated as coordinator and to ENISA.

Notifications are submitted via the single reporting platform that ENISA operates, the Single Reporting Platform (SRP).

The SRP is designed as a single entry point. Manufacturers report an incident once instead of notifying each competent national authority separately. The platform automatically forwards the notification to the competent coordinating CSIRT and, at the same time, to ENISA. Where needed, the coordinating CSIRT passes it on to other competent CSIRTs in the Member States where the product is made available, and to the market surveillance authorities.

The platform has been in operation since September 11, 2026, the day the reporting obligations started to apply. ENISA has launched a first release and plans to extend its functions in the coming months. A test phase preceded the launch.

Which CSIRT is competent depends on the manufacturer's main establishment in the Union. Under Article 14(7) of the CRA, this is the Member State where decisions related to the cybersecurity of its products are predominantly taken. If no such Member State can be determined, it is the Member State with the establishment that has the highest number of employees in the Union.

For manufacturers without a main establishment in the Union, a fixed order applies:

1. the Member State where the authorized representative acting for the highest number of the manufacturer's products is established;
2. if no authorized representative can be determined, the Member State where the importer placing the highest number of those products on the market is established;
3. next, the Member State where the distributor making the highest number of those products available on the market is established;
4. finally, the Member State where the highest number of users is located.

This cascade matters especially for manufacturers from third countries that sell their products through European partners.

Informing affected users

Reporting to authorities does not replace informing users. After becoming aware of the vulnerability or incident, the manufacturer must inform the affected users and, where appropriate, all users. Where necessary, it must point out risk mitigation and corrective measures that users can deploy themselves to reduce the impact. Where appropriate, this should happen in a structured, machine-readable format.

If the manufacturer fails to inform users in a timely manner, the CSIRTs designated as coordinators may inform them, where they consider this proportionate and necessary. For operators of connected machinery, this information is often relevant to security. It is the basis for temporary protective measures, such as disabling remote access.

The Commission's guidance suggests that this obligation does not necessarily mean public disclosure. Where appropriate, manufacturers may initially limit detailed information to the users or customers directly affected. This applies especially to products in sensitive or critical environments, where publicly disclosing technical details could create new attack surfaces. Once the issue has been sufficiently remediated or contained, broader disclosure may be appropriate. Its timing and level of detail should remain proportionate.

Alongside this discretion under Article 14(8), there is a separate obligation. Under Annex I, Part II, point 4, the manufacturer must publish information about a fixed vulnerability once it has made the security update available. In duly justified cases, it may delay publication until users have had the chance to apply the patch, if the security risks of publication outweigh the security benefits. This publication obligation does not cover products placed on the market before December 11, 2027. The reporting obligations under Article 14, however, have applied to those products since September 11, 2026.

Relief for microenterprises and small enterprises

The short 24-hour deadline is particularly hard on small manufacturers, which rarely run an established operations center. A relief applies here. Since the CRA corrigendum of July 2, 2025, microenterprises and small enterprises are not subject to administrative fines if they miss the 24-hour deadline for the early warning notification. The reporting obligation itself remains. For these company sizes, only the most severe penalty for simply missing the first deadline no longer applies.

The background to this correction is explained on our page on CRA penalties.

Preparing for the reporting obligation

Since September 11, 2026, manufacturers need the organizational setup to meet the deadlines at all. At its center is a response structure that can act. A product security incident response team (PSIRT) or a comparable incident response function makes sure that a clearly named, responsible person receives, assesses, and passes on each report in time. Reports then do not get lost in an inbox. The FIRST PSIRT Services Framework describes the services and roles such a team needs and can guide its setup.

Closely related is a process for coordinated vulnerability disclosure (CVD). If you set one up, you can follow established procedures such as those described in ISO/IEC 29147 and ISO/IEC 30111. These standards provide the framework for receiving, handling, and publishing vulnerability information. They therefore feed directly into the reporting chain under Article 14.

To meet the 24-hour deadline, you need clear escalation paths:

• Who decides whether an event must be reported?
• Who drafts the early warning notification?
• Who submits it via the reporting platform?

Standardized templates for the early warning notification, the detailed notification, and the final report shorten the response time considerably, because they structure the mandatory information in advance.

A dry run that takes a fictitious incident through all three stages reliably shows where responsibilities or information are missing. How the reporting obligations fit into the wider set of obligations of manufacturers under the CRA is covered separately.