TL;DR: The EU Cyber Resilience Act shifts product security from new development to retroactive support obligations, forcing manufacturers to track SBOMs, reachability, disclosure and reporting across older shipped products as well as current releases, according to Finite State. The real challenge is not finding more vulnerabilities, but making defensible decisions fast enough to satisfy regulators and customers.
At a glance
What this is: Finite State says the EU Cyber Resilience Act turns legacy products into a live compliance problem by requiring manufacturers to maintain SBOMs, assess reachability and report actively exploited vulnerabilities across the full support lifecycle.
Why it matters: This matters to product security, GRC and supply chain teams because CRA makes vulnerability management an evidence-driven lifecycle obligation, not a point-in-time scan-and-patch exercise.
Context
The EU Cyber Resilience Act changes the unit of accountability from a single release to the full supported life of a product. That matters because many organisations still treat vulnerability management as a release-stage activity, even though shipped firmware, embedded software and third-party components keep accumulating exposure long after launch. For identity and access programmes, the parallel is lifecycle governance: what exists in the field must still be inventoried, justified and defensible.
The article’s core governance gap is retroactive vulnerability management. Manufacturers are expected to know what is in older products, which exposures are reachable, when disclosure duties start, and what evidence will stand up to regulators. That is a different control problem from scanning active development pipelines, and it rewards organisations that can reconstruct product composition and risk from legacy binaries rather than relying on incomplete historic records.
Key questions
Q: What breaks when CRA obligations reach legacy products with no current SBOM?
A: The failure mode is evidentiary, not just operational. If a manufacturer cannot reconstruct what is inside an older shipped product, it cannot reliably decide whether a vulnerability is present, reachable or reportable. That creates missed deadlines, inconsistent customer guidance and weak regulator-facing justification for any decision.
Q: Why does the EU Cyber Resilience Act make vulnerability management a regulatory issue?
A: Because the manufacturer, not the end user, is now responsible for knowing what is inside supported products and for explaining how known vulnerabilities are handled. CRA turns vulnerability handling into an accountability model with disclosure, documentation and support-lifecycle obligations attached to it.
Q: How do security teams know which application vulnerabilities matter most?
A: Prioritise flaws that are externally reachable, have known exploit patterns, or expose sensitive identity material such as credentials, sessions, or privileged APIs. A long vulnerability list is not useful on its own. Teams need a ranked view based on exploitability, business exposure, and whether the issue can lead to authenticated access or lateral movement.
A: They should rapidly confirm product scope, assess reachability, document the decision, and determine whether the finding triggers the CRA notification duty to ENISA. The key is to contain uncertainty before it becomes a reporting and customer-communication problem.
Technical breakdown
Why legacy products become the hardest CRA problem
CRA does not stop at current development work. It extends manufacturer accountability across products already in the market, including devices with long support tails and incomplete historical records. That creates a retroactive visibility problem: teams may not have original source code, a trustworthy SBOM, or clear documentation for older firmware and software builds. In practice, the product security question becomes whether a vulnerability can be tied to a specific shipped artefact and whether it is still in scope for support and reporting obligations. The hard part is not volume alone, but evidentiary certainty across old releases.
Practical implication: Build a way to reconstruct legacy product composition before you can credibly answer CRA reporting and remediation questions.
How reachability analysis changes vulnerability triage
A raw CVE list is not enough for CRA decisions. Reachability analysis tests whether vulnerable code paths actually execute in the specific product build, which separates theoretical exposure from actionable risk. This is especially important for products with large historical vulnerability backlogs, where most findings may never be hit in normal operation. The point is not to ignore severity, but to add execution context so teams can prioritise what matters and document why they chose one mitigation path over another. That is what turns scanner output into defensible product security judgment.
Practical implication: Use reachability analysis to reduce false urgency and focus remediation on code paths that are actually exposed in shipped products.
Why the 24-hour disclosure clock forces operational evidence
CRA’s disclosure timelines compress the entire decision chain. Once an actively exploited vulnerability appears, manufacturers need enough evidence to decide whether the issue is present, reachable, exploitable and reportable, then document the reasoning behind the response. That requires a workflow linking inventory, vulnerability identification, prioritisation, remediation, verification and reporting. The governance shift is toward continuous evidence generation, because ad hoc spreadsheet-based processes cannot support regulator-facing deadlines or customer communication under pressure. The control failure is not just slow patching; it is slow proof.
Practical implication: Automate evidence capture around each product so notification, mitigation and customer communications can be supported immediately.
NHI Mgmt Group analysis
Retroactive vulnerability management is now a product governance discipline, not a security afterthought. CRA pushes accountability back to the manufacturer for products that may have been shipped years ago, which means old releases cannot be treated as closed records. Organisations that only operationalise security in active development will struggle to produce the evidence regulators now expect. The practitioner conclusion is that support lifecycle governance must extend as far back as the oldest product still in scope.
The real control gap is not vulnerability discovery, but evidential reachability. A long CVE list does not tell a regulator, customer or product team which findings matter in a specific shipped build. CRA exposes the weakness of programs that rely on severity alone, because they cannot separate theoretical risk from code paths that actually execute. The practitioner conclusion is to treat reachability as the decision layer between inventory and remediation.
CRA creates a documentation debt problem that looks a lot like identity lifecycle debt in other domains. Once a product is in the field, every update, component change and disclosure decision becomes part of a long-lived governance record. That record has to be coherent enough to defend under audit, procurement scrutiny and customer challenge. The practitioner conclusion is to build product evidence trails with the same discipline normally reserved for privileged access and lifecycle controls.
Security teams should stop assuming the hardest part of CRA is remediation speed. In many cases, the bottleneck will be proving what is inside a legacy product and whether the vulnerable code is reachable. That means manufacturers need a decision model that can survive regulatory questions, not just a scanner that can enumerate issues. The practitioner conclusion is to align vulnerability management, product engineering and compliance around the same evidence standard.
Support tails are now a strategic risk surface. Products with long service lives create more retroactive exposure than teams usually budget for, because obligations compound across years of releases and third-party dependencies. That changes how product security leaders should think about portfolio risk, especially in embedded and connected-device environments. The practitioner conclusion is to prioritise the oldest supported products first, because they are most likely to carry undocumented exposure.
What this signals
Retroactive product governance will expose where vulnerability programs still depend on incomplete history. Manufacturers that cannot reconstruct older builds will struggle to answer the two questions CRA now makes unavoidable: what is in the product, and can the vulnerable code actually run? The operational consequence is that product security, compliance and engineering have to share one evidence model, not separate spreadsheets.
Reachability is becoming the deciding control for product vulnerability prioritisation. When support obligations apply to years of shipped releases, severity-only triage becomes too noisy to support defensible decisions. Teams need to know which vulnerabilities are actually executable in the field, because that is what determines whether remediation, disclosure or customer notification is warranted.
Legacy support tails are the hidden compliance surface in connected products. The longer a product remains supported, the more likely its documentation, component inventory and risk decisions will have drifted from the current reality. Practitioners should treat old releases as active governance objects, because CRA will.
For practitioners
- Define a legacy product inventory Create a complete inventory of every supported product, release and firmware build that could fall under CRA obligations, including long-tail products and embedded versions.
- Reconstruct shipped binaries before triage Use binary analysis to rebuild component inventories where source code and historic SBOMs are missing, so older releases can be assessed with evidence.
- Add reachability to remediation decisions Classify vulnerabilities by whether the affected code path is actually reachable in the shipped product, not just by CVSS or EPSS.
- Prebuild your reporting evidence trail Capture the inventory, triage, mitigation and disclosure rationale for each product so 24-hour notification and customer communication can be supported under pressure.
Key takeaways
- CRA shifts product vulnerability management from a release-time task to a full support-lifecycle obligation.
- The hardest part is often proving what is inside a legacy build and whether the vulnerable code is reachable.
- Manufacturers that cannot generate defensible evidence quickly will struggle with disclosure, remediation and customer communication under CRA.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while EU Cyber Resilience Act defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | CRA forces manufacturers to govern product risk across the full support lifecycle. |
| PR.DS-09 — Availability of Information | Legacy product evidence and SBOM records must remain available for regulatory response. | |
| Recommendation — Align product support decisions to a documented risk strategy that covers legacy releases and reporting obligations. Preserve product evidence so shipped builds can be assessed and reported without delay. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article centres on ongoing vulnerability identification and prioritisation across supported products. |
| Recommendation — Extend continuous vulnerability management to released products, not just active development streams. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Defensible CRA decisions depend on testing and evaluation of shipped product risk, not just scanning. |
| Recommendation — Use evaluation evidence to support product security decisions for vulnerabilities in shipped software. | ||
| EU Cyber Resilience Act | Article 13 — Vulnerability handling and notification | The article is directly about CRA obligations for supported products and exploited vulnerabilities. |
| Recommendation — Map your product security workflow to CRA vulnerability handling and notification duties. | ||
Key terms
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- Retroactive Vulnerability Management: Retroactive vulnerability management is the discipline of assessing and governing security issues in products that were shipped long before the current regulatory or threat context existed. It requires reconstructing old builds, deciding what is still in scope and documenting those decisions in a way that stands up to audit or enforcement.
- Support Lifecycle: A support lifecycle is the vendor-defined timeline that shows when a product is released, maintained, and eventually retired. Security teams use it to determine whether a version can still receive patches, bug fixes, and other maintenance needed to keep risk within tolerance.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern security programmes. It is suitable for practitioners who need to connect identity control to broader operational risk.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org