The CISA Known Exploited Vulnerabilities catalog, often called KEV, is a list of vulnerabilities that are known to be actively exploited in the wild. CISA maintains the catalog to help organizations prioritize vulnerabilities that attackers are already using, not just vulnerabilities that are theoretically severe.
KEV is important because vulnerability teams face more findings than they can fix immediately. A vulnerability that is known to be exploited usually deserves faster attention than a vulnerability with the same CVSS score but no active exploitation evidence.
How KEV is built and what an entry contains
CISA adds a vulnerability to the catalog when there is reliable evidence of active exploitation, the vulnerability has an assigned CVE identifier, and there is clear remediation guidance such as a vendor patch or mitigation. That bar matters: KEV is deliberately not a list of everything that is severe, only of what is being used. Each entry includes the CVE ID, the affected vendor and product, a short description, the date it was added, and a required action with a due date for U.S. federal civilian agencies. The catalog is published openly and updated as new exploitation is confirmed, so it can be consumed programmatically and matched against your own inventory.
For background, the catalog and its governing directive are maintained by CISA. Content was rephrased for compliance with licensing restrictions.
How KEV is used
Security teams use KEV as a prioritization signal. When a CVE appears in the KEV catalog, teams should quickly determine whether affected software exists in their environment, whether the asset is internet reachable, whether compensating controls exist, and who owns remediation.
For federal agencies and many regulated teams, KEV also influences remediation expectations and deadlines. Even outside government, KEV has become a practical baseline: if attackers are already exploiting something and it exists in your environment, it belongs near the top of the queue regardless of its CVSS number. Many teams wire KEV directly into their pipeline, so that when a new entry lands, an automated job checks it against the software bill of materials and the live asset inventory and opens a ticket only where there is an actual match.
KEV vs CVSS
CVSS measures technical severity. KEV indicates known exploitation. Both matter, but they answer different questions:
- CVSS: How severe could this vulnerability be?
- KEV: Are attackers known to be exploiting this vulnerability?
A high CVSS score does not always mean active exploitation. A KEV entry means exploitation has been observed or confirmed strongly enough to warrant urgent attention.
KEV vs EPSS
EPSS estimates the probability that a vulnerability will be exploited. KEV identifies vulnerabilities already known to be exploited. EPSS is predictive. KEV is evidence-based.
The best programs use both, along with asset context. A KEV vulnerability on an internet-facing production workload is different from the same vulnerability on an isolated test system.
A practical KEV workflow
A KEV signal is only useful if it reaches the right asset and the right owner quickly. A workable loop looks like this:
- Ingest new KEV entries continuously rather than checking the catalog by hand.
- Match each entry against your inventory and SBOM to find where the affected software actually runs. Most new entries will have zero matches, and that is fine, it keeps the noise down.
- Enrich the matches with context: is the asset internet reachable, does it hold or reach sensitive data, does compromising it lead to higher privilege?
- Prioritize using that context. A KEV match on an exposed production service outranks the same CVE on an isolated internal host.
- Route the finding to the owning team with the evidence attached, and track it to closure against a defined deadline.
The steps that separate a mature program from a spreadsheet are matching and enrichment. Without them, a KEV entry is just news; with them, it becomes a specific, assigned action.
Why cloud context matters
KEV by itself does not know your environment. It cannot tell whether the affected package runs in production, whether the workload is exposed, whether compensating controls exist, or whether sensitive data is reachable.
That is why KEV works best when combined with cloud inventory, runtime context, network exposure, ownership, and attack path analysis. The same CVE can be an emergency on one asset and a low-priority backlog item on another, and only environment context tells you which is which. Pairing KEV (evidence of exploitation) with EPSS (probability of exploitation) and reachability data gives a far more honest ranking than any single score.
Strengths and limits of KEV
KEV’s strength is its high signal. Inclusion requires evidence of real exploitation, so a KEV match is rarely a false alarm about whether attackers care; they demonstrably do. That makes it an excellent forcing function for prioritization and a defensible basis for remediation deadlines.
Its limits are worth understanding so you do not lean on it for more than it offers. KEV is not exhaustive: a vulnerability being absent from KEV does not mean it is safe, only that confirmed, reportable exploitation has not been catalogued. It also lags first exploitation by design, because evidence has to accumulate before an entry is added, which is exactly the window predictive signals like EPSS try to cover. And KEV says nothing about your environment; a catalogued CVE for software you do not run is simply noise you should filter out early. Treating KEV as one strong input among several, rather than the whole prioritization strategy, keeps expectations calibrated.
Building KEV into an SLA
Many organizations formalize KEV by attaching a remediation service-level agreement to it. A common pattern is a tiered clock: KEV entries that match an internet-facing or sensitive asset get the shortest window, KEV entries on lower-exposure assets get a longer one, and everything else follows the normal severity-based schedule. The clock starts when the match is detected, not when the CVE was published, so the metric reflects your responsiveness rather than the vendor’s disclosure timing. Tracking two numbers, time-to-detect a KEV match and time-to-remediate it, gives a program honest feedback on whether its pipeline is fast enough to matter, since exploitation of a KEV item is by definition already happening somewhere.
How Cloudanix helps
Cloudanix correlates KEV and other exploit-intelligence signals with cloud assets, workloads, exposures, identities, and owners. Teams can use Zero-Day Watch, Vulnerability Prioritization, and Reports to move from raw CVE lists to actionable remediation.
Frequently asked questions
What does KEV stand for?
KEV stands for Known Exploited Vulnerabilities.
Is every KEV vulnerability a zero-day?
No. Some KEV entries are newly exploited; others are older vulnerabilities that attackers continue to use.
Should KEV vulnerabilities always be patched first?
They should be reviewed urgently, but priority should also consider exposure, asset criticality, exploitability, data sensitivity, and compensating controls.
How often should teams check KEV?
Continuously. New vulnerabilities can be added at any time, and remediation workflows should react quickly when an affected asset appears in your environment.
