KEVs confirm that attackers are already using the vulnerability in the wild, while CVSS only estimates potential impact. Under CRA logic, that confirmed exploitation is a stronger trigger for remediation and release blocking than a score that may never translate into real abuse. It turns prioritisation from theory into evidence.
Why KEVs change CRA prioritisation
KEVs matter because they move a vulnerability from a theoretical weakness to a confirmed abuse case. For CRA compliance, that distinction is important: a known exploited vulnerability is evidence that the issue already sits in an active attacker workflow, so remediation and release decisions should be based on actual exposure rather than estimated severity alone.
CVSS still has value, but it answers a different question. It helps describe potential impact and exploitability in a general sense, while KEV status says the vulnerability has crossed into real-world exploitation. That makes KEVs a stronger compliance signal when deciding what must be fixed first, what can block a release, and what needs immediate escalation.
In practice, the two signals should be read together. CVSS can help size the technical severity of a flaw, but KEV status helps determine whether the organisation is already behind the threat curve. Under CRA-style secure-by-design expectations, that confirmed exploitation usually deserves the stronger operational response.
How KEV and CVSS differ as compliance inputs
CVSS is a scoring model, so it standardises how teams compare vulnerabilities. It is useful for sorting, reporting, and trend analysis, especially when many flaws are competing for attention. But the score is an estimate, and a high score does not guarantee active abuse in the wild.
KEVs come from a different evidence base. They are grounded in observed exploitation and therefore align more closely with the question regulators and product teams care about: is this vulnerability being used against real systems now? That makes KEVs a better trigger for immediate release gating, patch urgency, and compensating controls when the organisation needs to prove it responded to known exploitation.
CISA Known Exploited Vulnerabilities Catalog is the clearest reference point for the “already exploited” signal, while FIRST CVSS remains the standard way to express severity. The compliance lesson is that severity and exploitation are related, but they are not interchangeable.
What CRA-oriented teams should do with both signals
Product and security teams should treat KEV status as the higher-priority operational input when the two conflict. A medium-scored KEV can be more urgent than a high-scored but unexploited issue if the release or deployed product is exposed to the same attack path. That is especially true where patching is slow, internet exposure is broad, or the affected component is reused across many products.
For governance, the useful decision rule is simple: use CVSS to understand potential harm, but use KEV to decide whether the vulnerability has crossed into mandatory-response territory. If a flaw is on the KEV list, teams should assume the threat is no longer hypothetical and require a documented remediation or blocking rationale.
EU Cyber Resilience Act matters here because CRA compliance is built around secure product behaviour, vulnerability handling, and timely response to known risk. That is why evidence of exploitation tends to outweigh a scoring model when the question is whether a product should ship, stay available, or be held until the issue is addressed.
Risk and Threat Considerations
Relying on CVSS alone can create a dangerous timing gap. A vulnerability may score well on paper yet remain dormant, while a lower-scored issue may already be under active exploitation and therefore represent immediate exposure to customers and regulators.
Failure mechanism: Teams prioritise by estimated severity instead of observed attacker use, so known exploited issues stay open because they look less urgent than a higher-score finding that has not been abused in practice.
Impact: The organisation can miss remediation deadlines, ship an exposed product, or fail to demonstrate the responsive vulnerability handling expected under CRA-oriented compliance programmes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while EU Cyber Resilience Act defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Cyber Resilience Act | CRA directly governs secure product vulnerability handling and response to known exploited flaws. |
| Recommendation — Prioritise known exploited vulnerabilities for rapid remediation and release blocking under CRA obligations. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | KEV versus CVSS is a vulnerability prioritisation question that maps to continuous vuln monitoring. |
| Recommendation — Use RA-5 to track exploited vulnerabilities and accelerate remediation of high-risk findings. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The question is about how to prioritise vulnerability remediation using evidence of exploitation. |
| Recommendation — Apply CIS-7 to maintain a risk-based remediation queue that elevates known exploited vulnerabilities. | ||
| NIST CSF 2.0 | ID.RA-01 — Vulnerability, Threat, and Risk Assessment | KEV and CVSS are inputs to risk assessment and remediation prioritisation decisions. |
| Recommendation — Incorporate KEV status into risk assessment so remediation reflects observed exploitation, not score alone. | ||
Practitioner Guidance
What to verify: Before you treat a vulnerability as “important enough,” check whether it is in a KEV list, whether the affected asset is actually reachable, and whether any compensating control is real rather than assumed. If the issue is actively exploited and externally exposed, it should move ahead of score-only findings.
Decision rule: Use CVSS for triage ordering within a backlog, but use KEV status to override that backlog when release gating, emergency patching, or customer-impact decisions are on the table. In CRA workflows, a known exploited weakness should normally be handled as a higher-priority compliance event than a theoretical high-severity weakness.
Practitioner takeaway: CVSS helps you compare vulnerabilities; KEVs tell you which ones attackers have already converted into real risk, and that evidence should carry more weight when compliance depends on proving timely, outcome-based remediation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org