CRA Flips the Timeline: Why Retroactive Vulnerability Management Is the Real Challenge

CRA Flips the Timeline: Why Retroactive Vulnerability Management Is the Real Challenge

The EU Cyber Resilience Act (CRA) holds manufacturers accountable for the vulnerabilities in every connected product they still support, including devices shipped years ago, long before anyone was planning for CRA. That’s likely to be a challenge for product security teams that are used to securing new development, not reaching back across years of shipped products.

The CRA is specific about disclosure timelines, documentation, and how manufacturers must manage the risk of third-party components. Established companies—those that have built a reputation of successful products and which have weathered regulation changes in the past—may find themselves at a disadvantage with the CRA. Because these requirements apply equally to all products still within their support window, manufacturers of products with long support tails have extra work to do. All products, even those on the market for years, must be accompanied by a software bill of materials, a list of known vulnerabilities, regular security updates, and a cybersecurity risk assessment.

Companies may be tempted by tooling that promises to automate this work. But deciding which risks actually matter, and what the mitigation options are, takes judgment no scanner or general-purpose AI can deliver on its own. This is Finite State’s specialty: pairing a platform that establishes what is inside each product and what the real-world risks are with a services team that helps manufacturers make risk-based decisions they can stand behind.

A Shift in Responsibility: Reactive vs. Retroactive

Under the pre-CRA model, securing technology is primarily a customer responsibility. Customers scan for vulnerabilities, monitor threat intelligence, track CVE disclosures, and try to balance patching obligations with operational needs. It’s constant triage, and it’s not sustainable.

CRA shifts the responsibility for securing a product upstream, back to the manufacturer who built the product and knows what’s inside. This is a new accountability model for product security. The burden of explaining significant cybersecurity incidents has traditionally fallen on the end user to justify patching timelines and configuration decisions. In the future, the manufacturer is on the hook to explain why the vulnerability was present in the first place. And these questions will apply not just to new products but to products already on the market—products that may have been quietly hiding vulnerabilities for years.

Under CRA, the manufacturer's responsibility comes with specific, recurring obligations. Across the full support lifecycle, a manufacturer has to:

• Maintain a continuous inventory, including a current SBOM, of the components inside every released product.
• Monitor those components as new vulnerabilities surface.
• Confirm which vulnerabilities are actually exploitable in a given product.
• Issue coordinated disclosures wherever the regulation requires them.
• Document the reasoning behind each decision so it holds up when a regulator asks.

The first hard deadline is closer than most teams realize. On September 11, 2026, CRA's Article 14 obligation to notify ENISA of an actively exploited vulnerability within 24 hours takes effect, more than a year ahead of the December 11, 2027 date most CRA planning still centers on.

For example, a vulnerability disclosed today in a common open-source library might affect a device shipped eight years ago. As long as the manufacturer still supports that product, they are responsible for evaluating the vulnerability, reporting to regulators, and notifying affected customers. Those processes hold for every product still in the field.

Why This Breaks Traditional Programs

Most security programs were never built to look backward. The constant pressure to scan, secure, and ship new products means that technical debt accrues on older products over time. The first time someone scans an old firmware image, the result can be discouraging. Imagine a product shipped years ago, with thousands of CVEs and no way to tell which ones matter. The product lacks SBOMs for legacy builds, engineers have no access to the original source code, and even known third-party components have incomplete documentation.

Firmware binary analysis is what makes that backlog manageable. Analyzing the compiled binary rebuilds an accurate component inventory, even when the source code and the original SBOM are long gone. Reachability analysis then separates the exposures that actually execute from the ones that never will, which is what makes risk-based prioritization under CRA workable. On the Finite State Product Security OS, reachability analysis reduces vulnerability noise by up to 90%.

Until a team knows what is genuinely in a product and which exposures are real, it cannot meet a 24-hour reporting deadline, produce evidence that holds up, or help a customer mitigate risk.

From Detection to Defensible Decisions

Once a team can finally see inside its products, the next problem is prioritization. Some tools may produce a list of CVEs with severity scores and may calculate an EPSS estimate of exploitation in the wild. That doesn’t tell you whether a vulnerability is reachable in your specific product, or what you owe a regulator if it is.

To make a defensible decision, a team needs to establish whether the vulnerability is present in the shipped binary, whether the affected code can be reached and exposed, and whether anyone is exploiting it in the wild. Both enterprise buyers and regulators in the EU will expect manufacturers to have that information, use it to make product security decisions, and maintain documentation of those decisions.

Once a vulnerability is exploited, a team has to decide quickly whether the finding triggers the 24-hour notification to ENISA, how serious it really is, which mitigation fits, and how to tell affected customers without shaking their confidence. Finite State helps with both. The platform surfaces the findings and shows what is reachable. Deciding what it means and what to do is where Finite State's experts work alongside your team, reading the findings in the context of your product, supply chain, and obligations, and helping you act under pressure.

Building a Program That Keeps Pace

CRA expects product security and documentation to keep up with the accelerating pace of cybersecurity threats. That requires continuous, automated documentation—building evidence every time you ship, so the record is always current. When a new CVE lands in the morning, you should know by that afternoon which products are affected, whether the code is reachable, and what you are obligated to report, without opening a spreadsheet. Maintaining that pace reliably, for every product, requires a continuous workflow: SBOM, vulnerability identification, reachability analysis, prioritization, remediation, verification, evidence, and reporting.

Finite State runs this workflow for you as a managed CRA service: a continuous program that maintains the necessary data and generates compliance documentation at every step, even for older legacy products. Our team will be standing by to advise on any close judgment calls. You stay in control; we support your decisions with evidence.

The Real Payoff

The deadline may be the forcing function for CRA compliance, but the payoff will last well beyond September. A manufacturer with a comprehensive understanding of its products and a real-time response capability builds trust and credibility in every procurement conversation. Customers will recognize that early compliance with the CRA demonstrates stability and reinforces the security of their own supply chain. Companies that wait will be under time pressure, risking non-compliance penalties, and facing hard questions from customers.

September 11 is the first real test of which group a company is in. There’s still time to land in the right one.

Worried about September 11 with no workflow in place? You don’t have to build it alone. Talk to our team about a managed CRA plan that can be operational within weeks. Request a CRA consultation →