CRA vulnerability reporting begins – What do manufacturers need to know?

Recently, organisations across the globe have woken up to the critical importance of vulnerability management, as AI models have become highly capable of identifying and exploiting vulnerabilities, which has in some cases even led to unintended infiltration of third-party systems. In a world where these enhanced vulnerability identification and exploitation capabilities are included in a regular AI subscription, the need for robust vulnerability management in connected software and devices is crucial. Although the legislator probably did not anticipate that the pace of AI development would be so fast, this is the reality in which the Cyber Resilience Act (Regulation (EU) 2024/2847, the "CRA") is now arriving. In this article, we take a closer look at the CRA's reporting obligations.

The CRA introduces comprehensive cybersecurity requirements for hardware and software products with digital elements traded within the EU market, setting a baseline for acceptable product security in the EU going forward. While most of its substantive obligations, such as secure design, vulnerability handling, risk management and continued security support, apply from 11 December 2027, the manufacturer's vulnerability and incident reporting obligations start applying already as of 11 September 2026. In practice, this means that companies manufacturing products with digital elements need to start building effective vulnerability management and incident reporting capabilities for their products right away.

What are the new reporting obligations about?

From September 2026, manufacturers of products with digital elements must notify the relevant authorities when they become aware of either of the following:

1. Actively exploited vulnerabilities contained in their products; and
2. Severe incidents having an impact on the security of those products.

The reporting obligations have two dimensions: first, a notification must be made to the relevant authorities, and second, the affected users of the product must be informed.

The authority notification must be submitted to the national Computer Security Incident Response Team (CSIRT) and simultaneously to ENISA (the EU Agency for Cybersecurity) via the single reporting platform, which is expected to be operational by the application date. The notification is made available to the relevant national CSIRT through the platform, and it is the CSIRT that coordinates the investigation into the notified exploit or incident. In Finland, the CSIRT role is held by the Cyber Security Centre within Traficom.

The authority notification must be submitted in three phases: an early warning within 24 hours of becoming aware of the vulnerability or incident; a follow-up notification within 72 hours of the same awareness trigger; and a final report on the handling of the actively exploited vulnerability or incident, including corrective measures taken or mitigations applied, within 14 days after a corrective or mitigating measure is available (for vulnerabilities) or 30 days after submission of the incident notification (for incidents).

Because the reporting obligation only covers situations where the security of the product is, or is likely to be, compromised without action by the manufacturer or the users, the CRA also requires manufacturers to inform affected users of the relevant vulnerability or incident. This applies to both consumers and B2B users. Importantly, there is no separate or higher threshold for user notification: whenever an authority notification is required, impacted users must also be informed. In this respect, the CRA's reporting obligations differ from the logic of, for example, GDPR breach notifications, which apply different risk-based thresholds for authority and data subject notifications.

What kind of vulnerabilities and incidents trigger the reporting obligation?

The CRA defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited the vulnerability in a system without the permission of the system owner. In practice, when a manufacturer becomes aware of a vulnerability likely to affect its product, it should promptly investigate whether the vulnerability is in fact being exploited in the context of that product. The reporting obligation is only triggered where there is reason to believe a malicious actor is behind the exploitation. For example, a vulnerability discovered during good-faith testing, a bug-bounty submission, or academic security research, without any evidence of malicious real-world exploitation, would not trigger the mandatory reporting obligation.

The CRA's reporting obligations also extend to vulnerabilities originating in integrated third-party components and remote data-processing solutions, as these are considered part of the product. Where a manufacturer's product contains a component sourced from a third party, and that component has an actively exploited vulnerability, both the manufacturer of the end product and the manufacturer of the component (if it has been separately placed on the market as a product under the CRA) must independently notify: each in respect of their own product. Especially with commonly used components, this may lead to multiple reports where the same vulnerability has been exploited across several products. This makes sense: the purpose of the reporting obligation is to provide transparency about which products are being compromised, so that users can take the necessary precautions and authorities can supervise that manufacturers are taking appropriate remedial steps.

In addition to actively exploited vulnerabilities, the CRA's reporting obligations cover severe incidents. Similar to the NIS2 Directive's definition, an incident under the CRA is an event that negatively affects, or is capable of negatively affecting, the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of data or functions. Under Article 14(5) of the CRA, an incident is considered severe where the data or functions involved are "sensitive or important" or the incident has led, or is capable of leading, to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of that product. According to Recital 68, such severe incidents refer to situations where a cybersecurity incident affects the development, production or maintenance processes of the manufacturer in a way that could result in increased cybersecurity risk for users or other persons.

It is also worth noting that, apart from the reporting obligations, the CRA includes broader vulnerability handling requirements that become applicable for new products placed on the market as of 11 December 2027. These include, among other things, a prohibition on making products containing known exploitable vulnerabilities available, a requirement to identify and document product vulnerabilities and components in a software bill of materials (SBOM), and a requirement to patch or otherwise remediate security vulnerabilities during the product's intended lifetime (support period). These full vulnerability handling requirements do not, however, take effect at the same time as the reporting obligations.

What is the scope of products affected by the reporting obligations?

One significant aspect of the CRA's reporting regime is its reach back to products already on the market. Manufacturers must comply with Article 14 for all products with digital elements falling within the CRA's scope, including products placed on the market before 11 December 2027. There is no general exemption for legacy software or older hardware generations.

The Commission's FAQ acknowledges the practical difficulty this creates. For legacy products, manufacturers may face real-world obstacles: tools to scan old software versions may no longer exist, build environments may be impossible to recreate, dependencies may be incompatible with modern systems, and staff with knowledge of legacy codebases may have moved on. The CRA does not require manufacturers to overcome these obstacles for legacy products. It does, however, require them to notify the vulnerability or incident if and when they become aware of it.

When does an organisation become aware of a vulnerability or an incident?

The notification clock starts ticking when the organisation "becomes aware" of a product vulnerability being actively exploited or a severe incident occurring.  The CRA does not prescribe how that awareness is to be obtained, nor does it impose an obligation to actively seek out such information. However, once an organisation does become aware, it must notify within the timeframes set out in the CRA.

The Commission's FAQ provides an illustrative list of channels through which such awareness may arise:

• Customers or partner organisations reporting unusual activity or compromise;
• Threat intelligence reports from security researchers or cybersecurity firms;
• Notifications from governmental cybersecurity agencies;
• Reports from ethical hackers;
• Internal monitoring, scanning, telemetry, or honeypot data;
• Dark web monitoring activities by the manufacturer's own security team.

As noted, the CRA does not require manufacturers to monitor all of these channels. However, if a manufacturer detects a suspicious event, receives a notification from a vendor or customer, or learns from a media outlet that a component supplier has suffered a major incident, the Commission's Guidance indicates that the manufacturer should immediately assess whether its own product has been affected. If, after that initial assessment, the manufacturer has a reasonable degree of certainty that a vulnerability in its product has been actively exploited, or that a severe incident compromising its product security has occurred, it must proceed with the reporting process set out in Article 14 of the CRA.

The Commission acknowledges that the circumstances in which a manufacturer can be considered to have become aware of an actively exploited vulnerability or a severe incident may vary. In some cases, it may take time to establish whether a vulnerability has in fact been exploited and whether the actor behind the exploitation was malicious. While the Commission does not expressly address whether there is a point at which a manufacturer may objectively be deemed to have become aware, it seems clear that mere inaction or reluctance to investigate would not relieve a manufacturer of the mandatory reporting obligation. In such situations, it would ultimately fall to the supervisory authorities to determine whether the manufacturer reasonably had, or should have had, knowledge of the actively exploited vulnerability or incident.

In practice, organisations with mature security and vulnerability monitoring capabilities are also more likely to become aware of actively exploited vulnerabilities early, and therefore more likely to trigger the notification clock sooner than those with less developed capabilities. On the other hand, more mature organisations are also better positioned to respond to and defend against security threats and incidents affecting their products. Conversely, inadequate preparedness and slow or indecisive responses can lead to more severe consequences when an actual incident occurs. Such failures may also be reflected in the level of consequences of non-compliance, including potential fines.

Practical takeaways

To prepare for the upcoming reporting obligations, manufacturers should consider taking the following steps:

• First, they should review their product portfolios to identify which products fall within the scope of the CRA. While the SBOM requirement as such does not become applicable until December 2027, it is advisable to begin mapping product components and collecting the relevant product information for vulnerability handling purposes well ahead of that deadline.
• Second, manufacturers should establish clear internal procedures for detecting, assessing and responding to suspected vulnerabilities and incidents. This includes ensuring that the organisation has the capability to promptly determine whether a vulnerability in its product is being actively exploited by a malicious actor or whether a severe incident has occurred. The steps and conclusions of any such assessments should be documented.
• Third, product teams should be made aware of the new requirements, and roles and responsibilities for identifying and escalating reportable events should be clearly defined. Internal processes should also be reviewed to ensure they can meet the strict reporting timelines imposed by the CRA.
• Finally, manufacturers should put in place mechanisms and templates for notifying affected users and ensure that their suppliers are subject to adequate notification obligations.

This article is intended as general information only and does not constitute legal advice. If you would like to discuss how the CRA's reporting obligations apply to your specific products or operations, please contact our Technology, Data & IP team.