KEV-First Vulnerability Management in 2026
Why CISA's Known Exploited Vulnerabilities catalogue should drive your patch queue — and how to operationalise KEV+EPSS prioritisation in production.
The CVSS-only fallacy
CVSS scores answer one question: how bad would this CVE be if exploited? They do not answer the more important operational question: how likely is it to actually be exploited in your environment?
Of the ~28,000 CVEs published in 2025, fewer than 5% had any observed exploitation. A patch program that treats every CVSS 9.0+ as urgent will burn cycles on theoretical risk while a CISA KEV entry sits unfixed for weeks.
What KEV+EPSS gives you
The CISA Known Exploited Vulnerabilities catalogue lists CVEs with confirmed exploitation in the wild. EPSS (Exploit Prediction Scoring System) gives you a probability that a CVE will be exploited in the next 30 days.
Combine the two and you get a sharp filter: KEV-listed vulnerabilities go to the top of the queue regardless of CVSS, EPSS-high vulnerabilities go next, and CVSS becomes the tiebreaker.
Operationalising the prioritisation
In Threatstealth's CVE Scanner, the default sort is KEV → EPSS → asset criticality → CVSS. Every finding is tagged with the CISA KEV inclusion date and federal remediation deadline.
- KEV-first ordering across hosts, web apps, containers, and code
- EPSS exploit-probability rendered alongside CVSS for context
- Asset criticality weighting so internet-facing assets surface first
- One-click ticket creation with the patch path baked in
What changes operationally
Teams that switch to KEV+EPSS prioritisation typically shrink their actionable backlog by 60–80% in the first week. Patch SLAs become achievable because the queue is now ranked by real risk, not theoretical severity.
The remaining work is the work that actually matters — and your auditors get a defensible story for why you patched what you patched, when you patched it.