Topic starter
24/10/2026 8:48 pm
TL;DR: Retroactive vulnerability management shifts from release-time work to a full support-lifecycle obligation, with Finite State saying manufacturers must track SBOMs, reachability, disclosure and reporting across older shipped products too. Legacy products now need defensible evidence fast enough to support disclosure, remediation and customer communication under CRA.
Editorial analysis by NHI Mgmt Group, based on content published by Finite State: “CRA Flips the Timeline: Why Retroactive Vulnerability Management Is the Real Challenge”.
Key questions
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.
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.
Q: What breaks when CRA obligations reach legacy products with no current SBOM?
A: The failure mode is evidentiary, not just operational.
Practitioner guidance
- 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.
Bottom line: CRA shifts product vulnerability management from a release-time task to a full support-lifecycle obligation.
Glossary terms: Retroactive Vulnerability Management, Reachability analysis, Software Bill of Materials, Support Lifecycle
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/10/2026 11:13 am
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.
A question worth separating out:
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.
👉 Read our full editorial: CRA makes retroactive vulnerability management the new product burden
This post was modified 6 days ago by NHI Mgmt Group