Most vulnerability management runs on severity scores, and most of it is therefore sorted by the wrong key. A severity score is a hypothetical: it describes the damage if somebody exploited this. Whether anybody is doing so is a separate fact, and it is the one that determines what happens to you this month.
What each one actually measures
| CVSS | KEV | |
|---|---|---|
| Question answered | How bad would this be? | Is this being used? |
| Form | A score from 0.0 to 10.0 | Membership — in the catalogue or not |
| Basis | Attack vector, complexity, impact | Evidence of exploitation in the wild |
| Who assigns it | The publisher of the advisory | CISA, on evidence |
| Size | Tens of thousands of entries a year | 1,676 total in late August 2026 |
| Changes over time | Rarely | Grows as exploitation is observed |
The size row is the important one. CVSS describes a population; KEV describes a subset small enough to act on. A list you can work through in a quarter is operationally different from a list you cannot.
Why severity alone misprioritises
Sorting by CVSS produces a queue headed by critical vulnerabilities in software nobody is currently attacking, while a moderate one under active exploitation sits below the fold. Two failure modes follow, and both are common.
- Effort goes to the theoretically worst rather than the actually exploited, so patching is busy and exposure does not fall.
- A moderate-severity flaw that is being used in ransomware campaigns waits behind a critical one that has no public exploit.
We have covered several instances of the second pattern: a flaw patched by the vendor months earlier, entering KEV only once ransomware crews picked it up, at which point federal agencies were given days to act on something that had been available to install since the spring.
How entry into KEV works
Three conditions: the vulnerability has a CVE identifier, there is reliable evidence of active exploitation, and there is a clear remediation — usually a vendor patch. The third matters more than it looks: KEV is a to-do list, so an entry with no available fix would be a to-do nobody can do.
This also explains what the catalogue leaves out. Exploitation that has not been observed and reported does not appear, so KEV is a lagging indicator by construction. It tells you what is confirmed, not what is happening.
A triage order that uses both
| Tier | Condition | Why here |
|---|---|---|
| 1 | In KEV, present in your estate, internet-facing | Confirmed exploitation plus confirmed reachability |
| 2 | In KEV, present in your estate, internal only | Confirmed exploitation, requires a foothold first |
| 3 | High CVSS, internet-facing, public exploit code exists | Not yet observed, but the barrier has already been removed |
| 4 | High CVSS, no known exploit | The conventional queue, worked in the time remaining |
The dimension that does most of the work in that table is not KEV or CVSS. It is whether the affected thing is reachable from outside and whether you actually run it. A KEV entry for software you do not have is not your problem, and an asset inventory that cannot answer that question makes the whole exercise guesswork.
What KEV does not cover
- Exploitation nobody has reported — the catalogue lags reality by however long observation takes.
- Vulnerabilities with no CVE, including a good deal of what happens in package ecosystems.
- Misconfiguration, which causes a large share of real incidents and has no identifier at all.
- Supply-chain compromises, where the defect is not in your software but in something it pulled in.
The last two are worth stating plainly, because a programme built entirely around KEV would have missed the incidents we have found most instructive this year — including a package registry attack whose exposure window was about ninety minutes and which never involved a CVE at all.
Reading the numbers
In late August 2026 the catalogue held 1,676 entries, with 5 added in the preceding seven days and 21 in the preceding thirty. Additions over a short window are a reasonable proxy for how busy the period has been; the running total is not, since it only grows.
These figures are on the front page of this publication, refreshed every ten minutes from CISA.
Questions
- Should we stop using CVSS?
- No. CVSS answers a question you still need answered — how much damage this would do — and it covers the whole population, where KEV covers a small subset. Use KEV to decide the order and CVSS to decide how much effort each item deserves once it comes up.
- We are not a US federal agency. Does KEV apply to us?
- The binding deadlines apply to United States federal civilian agencies. The catalogue is public and applies to everybody in the sense that matters: it is the best free record of what attackers are actually using, and nothing about that is jurisdictional.
- How quickly does a vulnerability appear in KEV after exploitation begins?
- There is no fixed interval, and by construction there cannot be — entry requires that exploitation has been observed and reported. Treat the catalogue as confirmation rather than early warning, and do not read absence from it as evidence that something is not being used.
- What single change most improves patch prioritisation?
- An asset inventory good enough to answer whether you run the affected software and whether it is reachable from outside. Without that, both KEV and CVSS produce a list you cannot act on, and the sophistication of the scoring is irrelevant.