By Matthew Brady, Senior Security Engineering Manager, Black Duck
As of September 11, 2026, Article 14 of the EU Cyber Resilience Act (CRA) is in force. Manufacturers, importers, and distributors of products with digital elements sold into the EU must notify ENISA or their national CSIRT within 24 hours of learning that a vulnerability is being actively exploited, with a mitigation report due in 72 hours and a full analysis due within two weeks. This is the first CRA milestone, not the last: broader secure development obligations arrive in December 2027. Organisations that prepared deserve credit, but this deadline is a starting point, and several parts of the requirement are more nuanced than they appear.
Who and What Is in Scope
The CRA applies to products with digital elements that connect to a device or network: operating systems, IoT devices, browsers, routers, and similar technology. These fall into four criticality tiers, from a broad “default” category up through important and critical classifications, each with different obligations. The highest tier requires third-party assessment; default-tier products can be self-certified, though manufacturers must still retain evidence of certification.
Some categories are excluded outright, including pure open source software and purely hosted services, unless a service connects to a product with digital elements such as a companion app. Products regulated under other frameworks, including automotive and medical devices, are excluded too, though narrowly: an infotainment system inside a car, for example, likely remains in scope even though the vehicle’s driving systems do not.
Defining “Actively Exploited”
A key clarification from ENISA concerns what triggers a report. Earlier guidance implied that all actively exploited vulnerabilities found anywhere in a supply chain might need reporting, a standard that would have buried regulators given how many vulnerabilities surface daily. ENISA has since clarified that the obligation applies only to vulnerabilities actively exploited within a manufacturer’s own product, which eases the burden but raises the bar on diligence: it requires knowing what is in your supply chain, monitoring it continuously, and evaluating incoming data against your deployment.
A decision not to report still has to be documented; for example, if a known exploited vulnerability in the supply chain subsequently becomes exploited with the specific product, then this would be a clear derogation of duty for vulnerability management and secure-by-design mandates which are part of the wider CRA requirements. Lack of process here could result in penalties which could reach 2.5 percent of global turnover or 15 million euros, whichever is greater.
Public Data Has Limits, So Automate
Anyone building a reporting process on public vulnerability data alone will hit a messy landscape. Monthly disclosures have grown roughly twelvefold in a few years, NIST’s National Vulnerability Database has stopped scoring most new CVEs, and the EU Vulnerability Database largely mirrors the NVD and inherits its inconsistencies. Organisations need a scoring approach that goes beyond any single feed, ideally grounded in CVSS version 4, currently the only standard that accounts for exploit maturity, including whether exploitation has been observed in the wild.
Manual, periodic scanning also cannot keep pace with a 24-hour reporting clock. Our own research found that organisations with continuous, automated monitoring fixed critical issues in under a day at two to four times the rate of less automated peers, and that regulatory pressure, including the CRA, is now the second-largest driver of investment in automated testing, trailing only direct experience with an incident. Frameworks like SLSA or NIST’s Secure Software Development Framework force the dependency visibility and SBOM validation that make faster remediation possible.
Everyone Is Both Supplier and Customer
Primary reporting responsibility sits with the manufacturer, vendor, or distributor placing a product on the EU market, but that entity must maintain an aggregated SBOM covering its entire supply chain. Suppliers of paid components may themselves count as manufacturers, with obligations often passed downstream by contract; open source is the exception, folded into the composite SBOM by the vendor assembling the final product. Many organisations sit on both sides of this relationship, receiving SBOMs upstream while producing their own downstream, and validating incoming SBOMs against actual delivered artifacts, rather than accepting them at face value, is becoming standard practice.
What Comes Next
December 2027 brings broader secure development lifecycle requirements, from secure-by-default configuration to structured vulnerability handling and coordinated disclosure. It is also worth understanding how the CRA connects to the revised EU Product Liability Directive, which reclassifies software as a product for liability purposes, takes effect by December 2026, and introduces no-fault liability with a lower burden of proof for claimants. In practice, the CRA defines what a reasonable manufacturer looks like, and the directive determines the consequences for those who cannot demonstrate they met that standard. Documentation built for CRA conformity may end up as evidence in a liability claim.
AI matters here in two ways. It is expanding both the attack surface and the volume of vulnerabilities to manage, so every organisation should plan for its applications to be targeted, likely repeatedly. AI tools also have a role in vulnerability assessment, but CRA compliance depends on processes that are documented, repeatable, and deterministic. Code run through a large language model may surface useful findings, but if it produces different results on a different day with no record of what was assessed, that does not meet the bar the CRA sets. AI can support the work; it cannot substitute for the evidence trail the regulation requires.
A Team Effort
CRA conformity is not a problem any single function can solve alone. Security needs visibility only engineering can provide, engineering needs risk context security is best positioned to deliver, and GRC needs both to oversee compliance. Building security testing and compliance checks into existing development workflows tends to produce better results with less friction, since conformity becomes a natural output of how software already gets built.
The reporting requirement that took effect this week is demanding, but it is also a useful forcing function toward the supply chain visibility, automated monitoring, and cross-functional coordination that will matter for December 2027, and for the liability and competitive differentiation that come with proving you can secure what you ship.
