The CISA KEV catalog
The KEV (Known Exploited Vulnerabilities) is the catalog maintained by CISA, the US cybersecurity agency, listing vulnerabilities whose exploitation has been confirmed in the wild. It is neither a severity estimate nor a probability: it is an observed fact. A CVE in the KEV gets fixed before the others.
You have a hundred overdue patches and two days ahead of you. Where do you start? The KEV is the shortest answer to that question, and the only one based on facts rather than models.
Two images to make it concrete
The KEV is the list of fires already reported. It is not a fire-risk map, and it is not a weather forecast: it is the dispatch board at the fire station, with the addresses burning right now. Nobody debates probability there; they send the trucks.
The KEV is also a vehicle recall notice. As long as a defect is theoretical, the manufacturer documents it. Once accidents are observed, it issues a recall — and the question is no longer “should I bring it in?” but “when can you come by?”. This second image adds what the first one lacks: the recall comes after the first accidents, never before.
What the catalog is, exactly
Created in late 2021, the KEV catalog lists the CVEs for which there is reliable evidence of active exploitation. It now holds more than a thousand entries and has become the reference priority list far beyond the United States.
We don't publish an exact count here: CISA shows the current total at the top of its catalog, which grows by a few entries a week. A number frozen in an article goes stale within days; better to point you to the source.
The three inclusion criteria
A vulnerability enters the KEV only if it meets all three of the following conditions:
- it has an assigned CVE ID;
- there is reliable evidence of active exploitation — a published proof of concept is not enough; attacks must have been observed;
- a clear remediation exists: a patch, an update, or instructions to remove the product.
The third criterion explains why the catalog is conservative: CISA lists only what an organization can actually act on. That's a strength for prioritization, and a limitation for detection.
What an entry contains
| Field | What it tells you |
|---|---|
| CVE | The vulnerability identifier, which allows automatic matching against an inventory. |
| Vendor and product | The affected software, as free text — it has to be matched to a standardized identifier before a machine can use it. |
| Vulnerability name | A human-readable title, useful in a ticket. |
| Date added | The day exploitation was confirmed. Compared with the CVE's publication date, it shows the real window. |
| Required action and due date | The expected remediation and its deadline, binding on US federal agencies. |
| Known ransomware use | Indicates whether the flaw is known to be used in ransomware campaigns. |
A real, dated case: MOVEit, May–June 2023
On May 31, 2023, the vendor Progress releases an emergency patch for its file transfer tool, MOVEit Transfer. The flaw is assigned CVE-2023-34362: a SQL injection that allows unauthenticated remote code execution.
On June 2, 2023, CISA adds it to the KEV catalog. Two days between the patch and confirmed exploitation. But the full timeline is harsher still: when the patch ships, the Cl0p group has already been exfiltrating data for several days. Public tallies have since passed 2,700 organizations affected, including government bodies and payroll providers that had never heard of MOVEit — but their subcontractor used it.
Two lessons you can reuse as is: the gap between a CVE's publication and its addition to the KEV is sometimes less than 48 hours; and exploitation has often started before publication. The KEV is not an early warning, it is a catch-up signal — all the more reason to act fast.
KEV, EPSS, CVSS: three different questions
| Standard | Question | Type of answer | What it misses |
|---|---|---|---|
| KEV | Is it exploited? | Yes or no, observed | Anything exploited without public evidence. |
| EPSS | Is it likely to be? | A probability from 0 to 1 | Targeted attacks, which are rare and therefore poorly predicted. |
| CVSS | How much damage if it is? | A score from 0 to 10 | Timing, and your context. |
The three work together in this order: KEV triggers, EPSS anticipates, CVSS breaks ties.
The regulatory framework: from BOD 22-01 to BOD 26-04
The catalog was created by directive BOD 22-01 (November 2021), which required US federal agencies to fix KEV vulnerabilities by a set due date. In 2026, that directive was revoked and replaced by BOD 26-04, which focuses on risk-based patch prioritization. The catalog itself remains active and maintained.
Neither directive is legally binding on a French company. Their value lies elsewhere: they made the KEV a common reference, cited in tenders, audit reports and patch policies across every sector.
What it means for you, in practice
Three steps, in this order:
- Cross-reference the KEV with your inventory, not with all of your alerts. The whole catalog doesn't concern you; its overlap with your products does.
- Set a written rule: any CVE in your environment that appears in the KEV is handled within 48 hours, whatever its CVSS score. A rule with a number in it avoids renegotiating every alert.
- Watch for additions to the catalog, not just CVE publication. A flaw you set aside three months ago can be added tomorrow: that's a transition, and it is what should trigger the alert.