The Vulnerability Was Real; The Exploit Was Impossible; The EU Cyber Resilience Act Reporting Obligation Was … Unclear?

Beginning last Friday (11 September 2026), manufacturers of products with digital elements that are made available on the European Union market must report actively exploited vulnerabilities and severe security incidents concerning those products under the EU Cyber Resilience Act (CRA).

The CRA applies to products with digital elements, including hardware and software products such as smart home devices, industrial sensors, operating systems and firmware. The CRA entered into force on 10 December 2024, with its substantive obligations being phased in over the following three years.

Article 14 of the CRA requires manufacturers to notify the relevant EU Member State CSIRT (the national computer security incident response team that coordinates vulnerability handling) and the European Union Agency for Cybersecurity (ENISA) of actively exploited vulnerabilities contained in their products and severe incidents having an impact on the security of those products. Notifications are made through the ENISA-managed Single Reporting Platform (SRP). 

For an actively exploited vulnerability, the manufacturer must make an early warning notification within 24 hours of becoming aware of it, followed by a notification within 72 hours and a final report no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the manufacturer must submit an early warning within 24 hours of becoming aware of the incident, an incident notification within 72 hours, and a final report within one month of the 72-hour notification.

The “capable of” question

One immediate question for manufacturers is how far the Article 14 reporting obligation extends where a vulnerability exists in a component of a product but cannot realistically be exploited in the manufacturer’s particular implementation.

Article 14(1) requires manufacturers to notify “any actively exploited vulnerability contained in the product with digital elements” of which they become aware. The definition of an “actively exploited vulnerability” is fact-specific: there must be reliable evidence that a malicious actor has exploited the vulnerability in a system without the permission of the system owner. As such, the provision establishes a factual trigger rather than an impact threshold.

But this raises an interpretive challenge. Does a literal reading of Article 14(1) mean that a manufacturer must report an actively exploited vulnerability even where the vulnerability exists in a third-party component but the manufacturer’s particular product configuration makes exploitation impossible or highly impracticable? For manufacturers of complex software products that incorporate numerous third-party components, the distinction can be significant.

This is because a vulnerability may have been exploited in the wild while being unreachable in the manufacturer’s implementation because, for example, the affected functionality is disabled, the relevant interface is not exposed, the vulnerable component is sandboxed or the relevant network path does not exist.

The CRA contains language elsewhere that could support a product-specific approach. Annex I Part I sets out mandatory essential cybersecurity requirements requiring products to protect the confidentiality, integrity and availability of data, including data stored, transmitted or otherwise processed. Annex I Part II separately requires manufacturers to identify, document and remediate vulnerabilities throughout the support period. 

Article 3(44), rather than Annex I, defines an “incident having an impact on the security of the product with digital elements” by reference to an incident that “negatively affects or is capable of negatively affecting” the product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions. And Article 14(5) separately uses similar language in defining when an incident is considered “severe”.

The difficulty with “capable of” is not simply that the phrase is broad, but that the CRA does not clearly identify how realistic or proximate a potential consequence must be before it becomes legally relevant. Indeed, almost any vulnerability can be characterised as “capable of” causing harm if the analysis is sufficiently hypothetical. A vulnerability may, for example, be technically capable of leading to code execution, but only if a series of other conditions are first satisfied that cannot realistically arise in the manufacturer’s implementation.

If a vulnerability in a component cannot be exploited in the manufacturer’s implementation because the affected functionality is disabled, inaccessible or adequately isolated, the manufacturer could therefore argue that the product-specific security characteristics materially reduce or eliminate the security impact of the vulnerability. On that view, treating the vulnerability as reportable solely because the same flaw has been exploited in another implementation arguably would produce notifications that are of limited operational value to the CSIRTs and ENISA.

The question is therefore not simply whether a vulnerability is theoretically capable of causing harm, but whether there is a technically realistic pathway by which it could do so in the product as implemented. Unhelpfully, the CRA does not clearly articulate where that line should be drawn.

Three reasons for caution

That uncertainty provides a basis for arguing that “capable of” should be understood by reference to the product as actually implemented, rather than to hypothetical scenarios in which harm is merely conceivable. It is a coherent argument on the basis of regulatory policy and, indeed, common sense. But it is not necessarily a secure basis for treating product-specific impact as a reporting exemption, for three reasons.

1. Article 14(1) uses different language from the incident definition and the severe incident provisions

The CRA distinguishes between the capabilities that products and manufacturers must possess, the circumstances that constitute a reportable vulnerability or incident, and the information that must be supplied to the authorities. Article 14(1) refers specifically to “any actively exploited vulnerability”, but it does not qualify that obligation by reference to severity, materiality or impact. The fact that Article 3(44) and Article 14(5) use capability-based language therefore does not, by itself, establish that the same standard should be read into Article 14(1). Doing so would require treating the incident definition and severity provisions as an interpretive limitation on a separate reporting obligation.

The structure of Article 14 points in the opposite direction. Severity and impact are expressly relevant to the information to be provided in the subsequent reporting stages. Article 14 requires the manufacturer to provide, among other things, a description of the vulnerability, including its severity and impact. That suggests that severity and impact can be assessed and communicated through the reporting process, rather than necessarily being conditions precedent to an Article 14(1) early warning notification.

This also does not mean that every vulnerability associated with a third-party component is automatically reportable. The concepts of an actively exploited vulnerability and a vulnerability “contained in” the product still have to be satisfied. But those questions should not be conflated with a general materiality test that Article 14(1) does not expressly contain.

2. Commission and ENISA guidance does not clearly introduce a materiality filter

The Commission’s implementation material describes the actively exploited vulnerability reporting obligation in terms of reliable evidence of malicious exploitation. ENISA’s SRP material similarly treats severity and impact as information to be assessed and supplied through the reporting process. Neither provides a clear basis for treating a vulnerability’s lack of practical impact on the manufacturer’s particular implementation as a general exemption from Article 14(1).

That is important because, if the Commission or ENISA intended manufacturers to apply an express materiality threshold before submitting an actively exploited vulnerability notification, one might expect the implementation guidance to identify the relevant threshold and provide criteria for applying it. At present, that does not appear to be the approach.

3. Market surveillance authorities may take a strict approach

A manufacturer that decides not to report an actively exploited vulnerability because it considers the vulnerability incapable of materially affecting its implementation would be taking an interpretive position for which there is, at present, limited authoritative support. A market surveillance authority could instead conclude that Article 14(1) deliberately imposes a broad reporting obligation and that the manufacturer was required to notify once the statutory conditions for an actively exploited vulnerability were satisfied.

What the “capable of” argument can – and cannot – do

A reasonable view, at least for now, is that the “capable of” language gives manufacturers a useful product-specific analytical framework, but not a clearly established reporting exemption. It goes without saying that a manufacturer should (i) determine whether a vulnerability can actually be exploited in its product, and (ii) document whether the relevant functionality is capable of producing the consequences associated with exploitation. That analysis is relevant to understanding the vulnerability, assessing its severity and impact, determining appropriate corrective measures and explaining the manufacturer's assessment to regulators.

But the analysis can also help to distinguish a realistic technical pathway to harm from a merely theoretical possibility. Without that distinction, “capable of” risks becoming an open-ended concept under which almost any vulnerability could be said to be capable of causing some adverse consequence in a hypothetical set of circumstances.

What is less certain is whether that analysis can lawfully be used to conclude that an otherwise qualifying Article 14(1) notification does not need to be filed. The difficulty is not simply whether “capable of” is sufficiently broad to capture potential harm, but where the legal boundary lies between a genuine technical capability and a remote or hypothetical possibility. And until the Commission, ENISA or national authorities establish a clearer proportionality or materiality approach, manufacturers relying on the latter interpretation would be accepting some residual regulatory risk.

The more conservative approach is to treat product-specific exploitability and impact as an internal prioritisation and assessment tool rather than a reporting gate. Where the Article 14(1) conditions are met, the manufacturer should consider making the notification within the applicable 24-hour period and use the subsequent reporting stages to explain the product-specific circumstances, including why the vulnerability has limited or no practical impact in the manufacturer’s implementation.

That approach does not resolve the underlying interpretive question, but it does place the manufacturer in a stronger position if its reporting decision is scrutinised. What’s more, the CRA’s obligations extend beyond regulatory notification. Following awareness of an actively exploited vulnerability or severe incident, manufacturers may have obligations to inform affected users and, where appropriate, other users about the vulnerability or incident and relevant corrective or mitigating measures. This reinforces the importance of having a documented product-specific assessment rather than treating the question as a purely regulatory reporting exercise.

The UK position

The UK’s proposed Cyber Security and Resilience (Network and Information Systems) Bill provides an interesting comparison, but one that should be drawn carefully.

The Bill amends the NIS Regulations’ definition of an “incident” to include events “having, or capable of having, an adverse effect on the operation or security of network and information systems”. The Government’s policy rationale is to address a perceived gap in the existing NIS regime. Its April 2025 policy statement explained that cyber attacks such as ransomware, pre-positioning and spyware may not currently be reportable where they have not yet disrupted the provision of an essential or digital service, even though they may have the potential to cause significant disruption or compromise later.

The Bill introduces a forward-looking element into the definition of an incident, whereby an event does not necessarily have to have produced the ultimate harm before it falls within the concept of an incident. But this should not be expressed as meaning that every event “capable of” causing harm automatically triggers a reporting obligation. 

The Bill also distinguishes between the definition of an incident and the provisions governing when an incident becomes reportable. The relevant reporting provisions impose additional conditions, including requirements concerning the effect or potential significance of the incident. However, the precise operation of the “capable of having” language will also depend on the secondary legislation and guidance made under the new regime. At the time of writing, the Bill is before Parliament and the relevant provisions may be amended during the legislative process.

The UK and EU regimes therefore illustrate two different uses of the concept of potentiality. Under the CRA, potential impact is expressly incorporated into the definition of an incident having an impact on the security of the product, while the separate Article 14(1) trigger for an actively exploited vulnerability is framed around actual exploitation. Under the UK Bill, potentiality is expressly incorporated into the definition of an incident, but that does not mean that the phrase alone determines the reporting threshold.

The comparison is more nuanced than a simple distinction between an EU regime asking, “did it happen?” and a UK regime asking, “could it happen?” Rather, both regimes recognise potential impact but they address that concept differently in the legislation. As discussed below, that makes it important for organisations operating in both markets to map the definitions, substantive triggers and reporting obligations separately rather than assuming that the same vulnerability assessment will produce the same reporting result.

Next steps for manufacturers

The CRA’s reporting obligations applied from 11 September 2026, whereas the UK’s regime will take effect on a separate timetable, with important elements still dependent on when the law comes into force and on secondary legislation. However, manufacturers should act now – not because every question discussed in this article has been resolved, but because compliance will depend on processes and evidence that cannot be stood up after a vulnerability is discovered.

• Build separate EU and UK reporting trees. Map each regime’s statutory triggers and test them against real scenarios, including third-party vulnerabilities, disabled functionality and ransomware. Do not rely on a single “report/no report” test.
• Document product-specific exploitability. Record whether the affected functionality is enabled, exposed and reachable, and what impact it could have. This evidence can support severity and impact assessments and, where appropriate, explain why a vulnerability has limited practical significance.
• Know your third-party components. Maintain an accurate software bill of materials and map components to the products and functions in which they are used. When a vulnerability is exploited in the wild, you should be able to establish quickly whether it is present, reachable and exploitable in your product.
• Protect the 24-hour clock. Decide in advance who receives vulnerability intelligence, who determines when the manufacturer became aware, who assesses exploitation and who makes the reporting decision. Preserve the evidence supporting those decisions, including where the decision is not to report.
• Test SRP readiness. Complete the ENISA Single Reporting Platform registration and access arrangements. Then test the process through a tabletop exercise, including an out-of-hours scenario, with the objective being to prove that a notification can actually be submitted within the deadline.
• Report first, then investigate further. Where the Article 14 CRA trigger is met, do not delay the early warning notification while waiting for a complete technical investigation. Use the 72-hour notification and final report to develop the analysis of severity, impact, exploitability and remediation.
• Maintain one technical record but make separate legal assessments. Use a single vulnerability management system to capture affected products, components, exploitability, evidence of exploitation, severity, impact and remediation. Feed that information into separate EU and UK decision trees, and monitor Commission, ENISA and UK regulatory developments so that the process can be updated as the regimes mature.

Subscribe to Ropes & Gray Viewpoints by topic here.