KEV (Known Exploited Vulnerabilities)

What is the known exploited vulnerabilities (KEV) catalog?

The known exploited vulnerabilities (KEV) catalog, maintained by CISA, is the authoritative public list of vulnerabilities confirmed to have been exploited in the wild. Inclusion is not a severity estimate or a probability. Exploitation has been observed and corroborated, which makes the catalog the least ambiguous priority list available to defenders.

Key takeaways

• KEV records observation, not prediction. Every other prioritization signal estimates something. An entry in the catalog reports something that has already happened.
• Entries carry remediation due dates. Those dates are binding on United States federal civilian agencies under operational directive, which is why the catalog functions as a de facto baseline far beyond government.
• It is short, and it is still slow to close. The Verizon 2026 Data Breach Investigations Report puts the median time to fully remediate a catalogued vulnerability at 43 days, with only 26 percent ever fully fixed.
• That gap isolates the real constraint. If the clearest possible list takes six weeks, the bottleneck is not analysis. It is ownership, change windows, testing and coordination.
• KEV is a floor, not a programme. It covers what has been observed and catalogued, which is a subset of what is exploitable at any moment.

Why it matters

The remediation interval matters more than any other figure in exposure management, because it removes every available excuse. A large backlog can be explained by volume, by disputed severity, or by unclear priorities. None of those explanations applies to a catalog that is short, externally maintained, unambiguous and accompanied by dates. When work still takes weeks, the delay is structural rather than analytical.

The pressure on that interval is increasing. Exploitation of known vulnerabilities is now the leading initial-access vector in the Verizon 2026 Data Breach Investigations Report at 31 percent, ahead of credential abuse for the first time, and attacker attention concentrates on exactly the population the catalog describes. Time to exploit for newly disclosed internet-facing flaws is frequently measured in days, so a 43-day median leaves a wide window on the vulnerabilities known to be in active use.

How an entry is added

• An assigned CVE identifier. The vulnerability must be formally identified through the CVE Program before it can be catalogued.
• Reliable evidence of active exploitation. Scanning for a vulnerable version or publication of a proof of concept does not qualify; the evidence must show exploitation in the wild.
• Clear remediation guidance. A vendor patch or a defined mitigation must exist, so that every entry is actionable on the day it appears.
• A remediation due date. Each record carries a deadline, typically shorter for vulnerabilities under widespread active exploitation.
• Continuous revision. Entries are added as exploitation is confirmed, and records are updated when vendor guidance changes, so the catalog grows in response to observed activity rather than on a schedule.

Where the catalog stops

KEV is a lagging indicator by design. A vulnerability appears only after exploitation has been observed, corroborated and documented, which means novel exploitation, narrowly targeted attacks against a single organization, and campaigns that never produce public evidence sit outside it. So does anything without an identifier to catalogue.

The 2025 Notepad++ supply-chain compromise illustrates the last case. A tampered distribution channel required remediation for months before CVE-2025-15556 was assigned in early 2026, and during that period no catalog entry could exist, because the prerequisite identifier did not. An organization operating the catalog as its complete definition of urgent work would have had nothing to act on.

The catalog is also silent on the two questions that determine local effort: whether a listed vulnerability sits in a reachable path in a particular environment, and which team owns the affected assets.

How to use KEV in practice

• Treat an entry as a trigger, not a queue. It should start an environment-specific check: is the affected version present, is the vulnerable code reachable, and who owns it.
• Measure the interval, not the count. The useful metric is elapsed time from publication to verified closure, segmented by asset class. A count of open entries hides where the delay occurs.
• Attach a named owner on day one. Where the constraint is dispatch rather than detection, an entry without an accountable team is already late.
• Plan for the unfixable case. Where a fix cannot land inside a risk-appropriate window, a compensating control or a detection scoped to that exposure is the interim position, and it should carry an expiry.

Common misconceptions

• That the catalog lists everything exploited. It lists confirmed, evidenced exploitation with remediation guidance available, which is a subset of real-world exploitation.
• That the deadlines apply universally. They bind United States federal civilian executive branch agencies. Other organizations adopt them voluntarily, though contracts and frameworks increasingly reference them.
• That an entry always outranks everything else. Almost always, but reachability still applies. A catalogued vulnerability in a component that is never loaded ranks below one that is internet-facing and callable.
• That inclusion implies high severity. The criterion is exploitation, not impact. Some entries carry modest severity ratings and are catalogued because attackers use them as one step in a chain.

Standards and sources

The catalog is published by CISA and derives its binding force from Binding Operational Directive 22-01, issued in 2021, which replaced a severity-based patching mandate with one driven by evidence of exploitation. Identifiers come from the CVE Program, and severity and exploitation probability are maintained separately by FIRST through CVSS and EPSS. The three signals are complementary: one describes consequence, one estimates likelihood, and the catalog confirms occurrence.

FAQ

Is KEV a complete list of exploited vulnerabilities? No. It records confirmed, evidenced exploitation for vulnerabilities that have an identifier and clear remediation guidance, which is a subset of what is exploited in practice.

Do private companies have to comply with the deadlines? The deadlines bind United States federal civilian agencies. Most other organizations adopt the catalog voluntarily as a baseline, and some contracts and regulatory frameworks reference it directly.

If a vulnerability is on the catalog, should it always be fixed immediately? Almost always, though reachability still governs sequence. A catalogued vulnerability in a component that is never in a runtime path is lower priority than one exposed to untrusted input.

How does KEV relate to EPSS? EPSS estimates the probability of future exploitation; the catalog confirms exploitation has occurred. A vulnerability typically carries a high probability before it is catalogued, and both signals precede any environment-specific analysis.

Sources

• CISA, Known Exploited Vulnerabilities Catalog, 2026.
• CISA, Binding Operational Directive 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, 2021.
• Verizon, 2026 Data Breach Investigations Report.
• FIRST, Exploit Prediction Scoring System (EPSS) Model and Specification, 2025.
• CVE Program, CVE Numbering Authority Operational Rules, 2025.