From September 11, 2026, manufacturers must report actively exploited vulnerabilities within 24 hours. The hard part is proving a flaw is in your product.
By Doc McConnell, Head of Policy and Compliance, Finite State
The EU Cyber Resilience Act’s vulnerability reporting obligation takes effect on September 11, 2026. From that date, any company that places a connected product on the EU market must notify the European Union Agency for Cybersecurity (ENISA) and a designated national computer security incident response team (CSIRT) within 24 hours of learning that a vulnerability in that product is being actively exploited, with a detailed follow-up in 72 hours and a final report within 14 days of a fix. The obligation is operational rather than administrative, and the hard part is determining, within hours, whether the flaw sits inside a product you ship, whether attackers are using it, and which customers are affected. Most manufacturers are not yet equipped to make that determination on a 24-hour clock.

Most CRA planning centers on December 11, 2027, when the full range of obligations comes into force: secure-by-design requirements, conformity assessments, and a complete technical documentation package. The reporting duty arrives more than a year earlier, and it falls on any manufacturer that places a product with digital elements on the EU market, such as industrial controllers, networking equipment, connected consumer electronics, and the standalone components sold into other products. Even in sectors with their own rules, such as vehicle type approval or medical device regulations, a component sold on its own can still fall under the CRA. The reporting duty also applies to products already on the market, not just new ones, so a team that waits until 2027 to stand up a process will already be months behind.
Familiarity with the regulation has not turned into readiness. In a survey of 194 small and medium-sized manufacturers across 31 countries conducted in early 2026, ENISA found that two-thirds had heard of the CRA, yet only 13% were confident they could produce the technical documentation it demands.
“The 24-hour clock doesn’t start when a vulnerability is published; it starts when you can confirm the flaw is in a product you ship and being exploited in the wild. Getting to that answer is the real test.”
— Doc McConnell, Head of Policy and Compliance, Finite State
The 24-hour window is short, but the deadline is only part of the problem. Reporting starts only after a manufacturer establishes two things: that its product is affected, and that the vulnerability is being actively exploited in the wild. Publication of a CVE does not start the clock; confirmation does. And without a solid inventory of which components are in which products—including older products already in the field—it can be impossible to confirm whether an actively exploited CVE creates exposure for a manufacturer.
Most inventories are unreliable because companies assemble them from supplier paperwork rather than from the shipped product itself. Finite State’s own research bears this out. In a joint study with Forescout of firmware from widely used OT and IoT routers, the analysis found open-source components years out of date, and cases where a vendor had patched a known flaw without changing the component’s version number. A version-based inventory can read as clean while the shipped code is still vulnerable.
The consequences show up in products in the field. Finite State researchers test products every day. Our research recently found CVE-2002-1819, a flaw first disclosed in 2002, was still present in a product sold in 2026, inside an outdated embedded web server. This flaw wasn’t listed in any supplier document. Because a vulnerable component may be present in many similar products, a single flaw may reach the market in several brands at once, each of them separately accountable for it.
A typical connected product carries thousands of known vulnerabilities, most inherited from open-source and third-party components, some sitting in code that has not been touched in years. You cannot fix all of them, and the CRA does not ask you to. It asks for a risk-based, documented decision about each one. Reachability, meaning whether the vulnerable code is both present and able to run in your build, is what separates the finding that warrants a 24-hour report from the one that can wait. A critically severe flaw in a library that never executes in your firmware is a different obligation from one an attacker can reach.
Reachability is also what makes the timeline survivable, because most components in a firmware image are never reachable in the shipped build. In practice, that analysis typically removes 90 to 95% of vulnerability findings from the triage queue, reducing a multi-hour process to minutes, and focusing the team’s efforts on the exposures that actually matter.
Meeting the CRA disclosure deadline is a coordination problem as much as a technical one. By hour 24, a manufacturer needs engineering to confirm whether the flaw is real and present, threat intelligence to confirm exploitation, legal to decide what must be said, customer teams to identify who is affected, and an executive who can approve the filing. Few organizations have mastered those handoffs.
The practical work is to build that chain before it is needed. Pre-designate the individual (not a committee) with authority to approve an ENISA notification, establish the reporting channels to your coordinating CSIRT and ENISA in advance, and draft the 24-hour, 72-hour, and 14-day templates now. Then run a tabletop against a real finding from your own portfolio; it’s better to find the gap during a drill than under the pressure of a real mandatory disclosure.
The deadline is the forcing function, but building this capability is a good investment for any product manufacturer. Enterprise buyers and OEM procurement teams increasingly expect a software bill of materials and a documented disclosure process from all their suppliers. A manufacturer that can produce this evidence on demand moves through procurement faster, while one that cannot risks extended audits, delayed deals, and eventually the loss of access to the EU market.
Finite State builds this capability alongside manufacturers: a software inventory generated from the firmware you actually ship, reachability analysis that ties each finding to your build, and disclosure support drafted to the CRA’s timelines. Your team makes the judgment calls, informed by evidence that is ready the moment a regulator or a customer asks.
The reporting obligation under Article 14 applies beginning September 11, 2026. The remaining CRA obligations, including secure-by-design requirements and the full technical documentation package, take effect on December 11, 2027. Preparing for September also lays the groundwork for meeting the 2027 requirements.
The clock starts when a manufacturer confirms that its product is affected by a vulnerability and that the vulnerability is being actively exploited in the wild. Publication of a CVE does not start it. Once both conditions are met, the manufacturer must notify ENISA and a designated national CSIRT.
If you place a product with digital elements on the EU market, the CRA likely applies, and applicability is decided product by product. Some sectors have their own rules: finished vehicles fall under type approval, and medical devices under their own regulations. Even so, a standalone component sold on its own can be in scope.
A manufacturer owes an early-warning notification within 24 hours of awareness, a detailed follow-up within 72 hours, and a final report within 14 days of a corrective or mitigating measure becoming available. All are filed to ENISA and a designated national CSIRT.
September 11 measures something specific: whether a manufacturer can turn security work it has already done into an answer a regulator will accept, inside a day. The teams that can will carry that same capability into the December 2027 obligations and into every customer security review that follows. The work to get there takes weeks, and the window to start it is now.
Finite State’s CRA resources are available at finitestate.io/cra.

About the Author:
Doc McConnell is a public policy and cybersecurity leader with over a decade of experience shaping national technology policy within the U.S. government. Prior to joining Finite State, he led strategic policy development for federal cybersecurity at the Cybersecurity and Infrastructure Security Agency and served as a policy advisor within the White House Office of Management and Budget. Doc holds a Master of Information and Cybersecurity from the University of California, Berkeley, and a Master of Public Policy from the University of Virginia. He is a Certified Information Systems Security Professional (CISSP).
Read more from the author:
CRA Vulnerability Reporting: September 2026 is Around the Corner | Finite State, May 28, 2026
CRA Readiness Takes More Than Reading the Regulation | Finite State, August 20, 2026
As manufacturers offer more customization than ever before, managing product complexity has become a critical challenge. Tune in with Dan Joe Barry, Vice President of Product Marketing at Configit, who explores how companies are tackling the growing number of product configurations across engineering, sales, manufacturing, and service. He explains how Configuration Lifecycle Management (CLM) helps organizations maintain a single source of truth for configuration data. The result: fewer errors, faster quoting, and the ability to deliver customized products at scale.