Topic starter
21/08/2026 4:53 pm
TL;DR: Vulnerability prioritisation becomes a compliance obligation under the Cyber Resilience Act, with KEVs, EPSS and reachability used to explain what gets fixed first, per Xygeni. Release decisions now need auditable proof that reachable exploited flaws were fixed before they shipped.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “Risk Based Vulnerability Management and CRA”.
Key questions
Q: Why do KEVs carry more weight than CVSS for CRA compliance?
A: KEVs confirm that attackers are already using the vulnerability in the wild, while CVSS only estimates potential impact.
Q: How do organisations know whether a vulnerability is truly actionable?
A: A finding is actionable when the vulnerable code is reachable at runtime, the asset is exposed in a meaningful way, and the surrounding permissions or misconfigurations create a usable attack path.
Q: What breaks when vulnerability management is still severity-first under the Cyber Resilience Act?
A: Severity-first programmes miss the CRA expectation that teams can prove they understood active exploitation and product exposure.
Practitioner guidance
- Implement KEV-driven release blocking Block merges or deployments when a known exploited vulnerability affects reachable code or shipped components, and require an explicit exception for any override.
- Combine EPSS with reachability checks Score every relevant finding with exploitation likelihood and actual code-path exposure so remediation effort follows demonstrated risk, not raw severity.
- Preserve decision traceability for every exception Log the vulnerability signal, the exposure test, the remediation choice, and the approver so auditors can reconstruct why a flaw was accepted or fixed.
Bottom line: The article frames the Cyber Resilience Act as making vulnerability prioritisation a compliance obligation, not just an internal security practice.
Glossary terms: Known Exploited Vulnerability, Reachability analysis, Risk-based Vulnerability Prioritisation, Identity Traceability
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
21/08/2026 5:11 pm
CRA pushes vulnerability management out of the security backlog and into governance. The article's core shift is that prioritisation is no longer just about reducing noise, it is about proving why one flaw was fixed before another. That matters because decision traceability becomes part of the control itself, especially when the product ships into regulated markets.
A question worth separating out:
Q: What evidence should security teams keep when they defer a reachable vulnerability?
A: They should keep the detection signal, the reachability result, the prioritisation rationale, the remediation owner, and the approval trail. CRA-style governance depends on being able to reconstruct why a decision was made, especially when a known exploited or reachable flaw was not fixed immediately.
👉 Read our full editorial: Risk based vulnerability management under the Cyber Resilience Act