Topic starter
21/08/2026 4:53 pm
TL;DR: The Cyber Resilience Act turns vulnerability prioritisation into a compliance obligation, with KEVs, EPSS and reachability used to prove what gets fixed first, according to Xygeni. The governance shift is from backlog management to evidence-backed remediation decisions, where exploitable flaws and release controls matter more than raw CVSS scores.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “Risk Based Vulnerability Management and CRA”.
Key questions
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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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