Cyber Resilience Act: A Legal Bug in the Line of Fire

As of September 11, 2026, the Cyber Resilience Act is fully operational, and Article 14 obliges manufacturers to notify authorities within 24 hours of any actively exploited vulnerability. An analysis published by Ropes & Gray LLP on the very day the regulation took effect raises a question the regulator did not answer: does the reporting criterion apply to the presence of the defect in the product, or to its concrete exploitability in the specific implementation? For companies with complex software supply chains, the answer determines the difference between manageable compliance and structural alarmism.

The Fracture Between "Contained" and "Capable Of"

The core of the problem lies in the regulation's differing linguistic architecture. Article 14(1) merely requires notification of any actively exploited vulnerability "contained in the product with digital elements." It introduces no filters for severity, materiality, or practical impact. At the same time, Article 3(44) defines an "incident having an impact on the security of the product" using the formula "capable of negatively affecting"—language that Article 14(5) reprises for "severe incidents," but which Article 14(1) does not incorporate.

This asymmetry opens two readings. The first, literal: any actively exploited vulnerability in any third-party component is reportable, regardless of the manufacturer's configuration that incorporates it. The second, contextualized: reporting triggers only if a technically realistic exploitation path exists in the specific implementation. The CRA's structure draws no clear line between the two.

"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." — Ropes & Gray LLP

When the Vulnerable Component Is Inert

A manufacturer may integrate a library that contains an actively exploited vulnerability elsewhere, but render it technically unreachable: functionality disabled, interface not exposed externally, sandboxing blocking the attack path, absence of network connectivity in the execution perimeter. The vulnerability exists in the code. The vulnerability is not exploitable in the finished product.

According to the Ropes & Gray analysis, neither European Commission guidance nor ENISA guidance clearly introduces a materiality filter that would exempt Article 14(1) in these scenarios. The cited analysis states textually that there is no clear basis for treating the lack of practical impact on the specific implementation as a general exemption.

The Risk of a Restrictive Approach by Authorities

Market surveillance authorities could adopt a broad interpretation. The legal analysis explicitly cites this possibility: an authority could conclude that Article 14(1) deliberately imposes an extended reporting obligation, turning every actively exploited vulnerability in a third-party component into a notifiable event even without a technically realistic path in the final product.

This reading has immediate operational consequences. A manufacturer with hundreds of dependencies would have to monitor active exploits in every upstream component, evaluate its own implementation, and notify anyway—or assume the risk of not doing so. The overhead is not marginal: the primary source underscores that deciding not to report a vulnerability deemed harmless means assuming "an interpretive position for which there is, at present, limited authoritative support."

Why It Matters

The dossier does not specify corrective measures or regulatory workarounds that close the interpretive fracture. It does not emerge that ENISA or the Commission have scheduled dedicated clarifications on the product-specific exploitability criterion. It is unknown whether the Single Reporting Platform allows indicating in the report that the vulnerability is not exploitable in the specific implementation, nor whether enforcement cases exist to guide practice.

The source also does not document whether the "contained in the product" criterion has received judicial interpretations in other EU regulatory contexts that could serve as precedent. The uncertainty remains total: the manufacturer lacks reliable tools to calibrate its vulnerability disclosure and incident response program.

The penalties make the regulatory void costly. According to the cited source, material violations of Articles 13 and 14 expose companies to fines of up to approximately €15 million or 2.5% of global turnover. Micro-enterprises and small enterprises are exempt from penalties for missing the 24-hour deadline, but the exemption does not resolve the interpretive question on the merits of notifiability.

The Three Unanswered Questions

Does the CRA distinguish between an exploitable vulnerability and a present vulnerability? The text of Article 14(1) does not qualify the obligation with reference to technical exploitability in the specific implementation. Article 3(44) and Article 14(5) use "capable of" language that Article 14(1) does not replicate.

What does a company risk by not notifying a vulnerability deemed harmless? It assumes an interpretive position unsupported by authoritative guidance, with exposure to fines of up to approximately €15 million or 2.5% of global turnover, according to the cited source.

Is there a way to document in the report that the bug is not attackable? The dossier does not specify whether the Single Reporting Platform permits fields or flags describing product-specific non-exploitability.

The regulator wrote "contained in the product" likely envisioning a coherent technical unit. Modern software is an assembly, not a monolith. Until that line is drawn, compliance remains navigation without a compass—and the cost of error is written in euros in the penalties column.

Information is based on the cited advisory and current as of the time of publication.

Sources

• https://www.ropesgray.com/en/insights/viewpoints/2026/09/102o10i/the-vulnerability-was-real-the-exploit-was-impossible-the-eu-cyber-resilience-a
• https://www.consiliumsafety.com/en/eu-cyber-resilience-act-cra/
• https://cryptoticker.io/en/wallet-makers-reporting-duty-eu/
• https://www.secnews.gr/en/732068/eu-cyber-resilience-act-ypochreoseis-anaphoras/
• https://pssle.co/all-ropesgray-insights/s/102g97p?_gl=1*48tb5p*_gcl_au*MTczNTAyODQ4Mi4xNzM2Mjc3MTQ2
• https://www.cookiebot.com/
• https://www.consiliumsafety.com/en/products/

Information is based on the cited source and current as of the time of publication.

Sources