Can Your Team Meet the CRA's 24-Hour Reporting Clock? - Industry Today - Leader in Manufacturing & Industry News
 

August 27, 2026 Can Your Team Meet the CRA’s 24-Hour Reporting Clock?

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

Key Takeaways

  • The EU Cyber Resilience Act’s vulnerability reporting obligation takes effect September 11, 2026, more than a year before the December 2027 deadline most manufacturers are planning around.
  • Any company that ships a connected product into the EU must report an actively exploited vulnerability to regulators within 24 hours of becoming aware of it, including products already on the market.
  • The real work is determining, within hours, whether the flaw is in a product you ship and whether attackers are using it, rather than filing the report.
  • Most manufacturers can’t quickly confirm whether a newly disclosed flaw is even present in what they shipped, because their software inventories come from supplier paperwork that rarely matches the actual product.
  • Reachability, meaning whether the vulnerable code actually runs in your build, separates the findings that demand a 24-hour report from the thousands that do not.
  • The manufacturers who can produce this evidence on demand are already turning it into a sales advantage; the ones who cannot face stalled deals, longer audits, and eventually the loss of EU market access.

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.

CRA vulnerability reporting
The CRA’s reporting duty begins September 11, 2026, more than a year before its full obligations apply.

You’re Planning for the Wrong Deadline: Which CRA Obligations Apply in 2026, Not 2027

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 Component List You Can’t Trust

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.

Reachability Decides What Needs a Report

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.

Who Approves the Filing in Under a Day?

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.

Why CRA Readiness Outlasts the Deadline

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.

EU Cyber Resilience Act Reporting Obligations: FAQs

When does the CRA’s vulnerability reporting requirement take effect?

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.

What starts the 24-hour reporting clock?

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.

Does the CRA apply to my company if we don’t think of ourselves as a software maker?

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.

What are the EU Cyber Resilience Act reporting deadlines?

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.

What the Deadline Actually Measures

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.

Doc McConnell Finite State

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

 

Subscribe to Industry Today

Read Our Current Issue

Forging the Next 250 Years: Powering the Next Era of American Manufacturing

Most Recent EpisodeManaging Complexity in the Age of Mass Customization

Listen Now

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.