The CISA Known Exploited Vulnerabilities (KEV) catalog is a running, authoritative list of vulnerabilities that CISA has confirmed are being actively exploited in the wild, and it matters for prioritization because it answers a question no severity score can: is this specific vulnerability actually being attacked right now, not just theoretically dangerous. For a security team drowning in vulnerability findings, KEV status is one of the clearest, most defensible reasons to move something to the front of the queue.

The catalog has grown considerably since it launched in November 2021, now sitting at roughly 1,665 entries, and over 60% of those vulnerabilities were exploited the same year they were publicly disclosed. That's a meaningful data point on its own: attackers aren't waiting years to weaponize known flaws, and a growing share of what lands on KEV was exploited within months, sometimes days, of becoming public.

What exactly qualifies a vulnerability for the KEV catalog?

CISA doesn't add vulnerabilities to KEV based on theoretical risk or a high CVSS score. Inclusion requires three specific things: the vulnerability has an assigned CVE ID, there's confirmed evidence of active exploitation in the wild, and there's clear mitigation guidance available for defenders to act on. This is a meaningfully higher bar than "this could be exploited", it means someone, somewhere, has actually observed real attackers using it.

Anyone, not just CISA itself, can flag a vulnerability for potential inclusion through CISA's KEV nomination form, provided it meets those same three criteria. New entries get added on a rolling basis, sometimes several times a week, as new exploitation activity gets confirmed.

How did KEV come about, and why does it matter that it did?

KEV's origin is directly tied to Stakeholder-Specific Vulnerability Categorization (SSVC), the decision-tree methodology CISA adopted to prioritize its own vulnerability response. The first KEV catalog publication, in November 2021, came directly out of that SSVC-based process. In effect, KEV is what happens when CISA applies its own "is this being actively exploited" decision point at scale, across every vulnerability it tracks, and publishes the result publicly for the entire cybersecurity community to use.

That's part of why KEV carries real weight in prioritization conversations. It's not a vendor's marketing claim or a crowdsourced guess, it's a curated, evidence-based list maintained by the US government's primary cybersecurity agency, built specifically to cut through the noise of "critical" ratings that don't reflect real-world attacker behavior.

What does BOD 26-04 require now, and how is it different from the old rule?

For years, the compliance reference point for KEV was CISA's Binding Operational Directive 22-01, which gave Federal Civilian Executive Branch agencies fixed windows to patch, as short as two weeks for newly cataloged vulnerabilities. That directive has been superseded. BOD 26-04, issued June 10, 2026, replaces it with a risk-based, tiered remediation model. Instead of one deadline applied to every KEV entry equally, urgency now depends on three factors:

• Asset exposure: is the vulnerable asset publicly reachable on the internet

• KEV status: is the specific CVE listed in the KEV catalog

• Exploit automation: can an adversary automate the entire exploitation process without manual effort

The combination of these factors determines how fast a given vulnerability needs to be remediated, with the most severe combination- KEV-listed, internet-facing, and easily automatable- landing in the fastest tier. Reporting on the directive has cited a three-day window at the top end of that scale, though the general principle matters more than the exact number: not every KEV entry demands the same urgency anymore, and agencies need to be able to quickly determine an asset's internet exposure to know which tier actually applies.

Notably, BOD 26-04 formally applies only to federal civilian agencies, but its influence extends further. FedRAMP has set a December 2026 target for adopting aligned rules, which brings authorized cloud service providers into scope. It's increasingly common for contract language and vendor security requirements to reference these federal remediation timelines directly, even for organizations that aren't legally bound by the directive.

Why should non-federal organizations care about KEV at all?

CISA has been consistent in encouraging every organization, not just federal agencies, to monitor and prioritize KEV catalog vulnerabilities, and there's a practical reason for that beyond just following government guidance. KEV inclusion is one of the strongest available signals that a vulnerability isn't a hypothetical risk; it's an active attack pattern happening right now, somewhere. A vulnerability on your network that also happens to be on KEV is meaningfully more dangerous than an equally rated CVE that's never been observed exploited.

KEV-based prioritization vs. severity-only prioritization

FAQ

Does BOD 22-01's 15-day patch deadline still apply to federal agencies?

No. BOD 22-01 has been superseded by BOD 26-04, issued June 10, 2026, which replaces the earlier fixed deadlines with a risk-based, tiered remediation model based on asset exposure, KEV status, and exploit automation potential.

Is every vulnerability on KEV equally urgent to patch?

Not under the current federal directive. BOD 26-04 explicitly ties remediation urgency to whether the vulnerable asset is publicly exposed and whether exploitation can be automated, alongside its KEV status, meaning a KEV-listed vulnerability on an internal, hard-to-reach system may warrant a longer remediation window than the same CVE on an internet-facing server.

Do organizations outside the federal government have to follow BOD 26-04?

Not legally, it applies specifically to Federal Civilian Executive Branch agencies. However, CISA encourages all organizations to adopt the same risk-based approach, and frameworks like FedRAMP are moving to align with it, which is gradually extending its practical reach to cloud service providers and organizations under related contractual obligations.

How is a vulnerability added to the KEV catalog?

It needs an assigned CVE ID, confirmed evidence of active exploitation in the wild, and clear mitigation guidance for defenders. Anyone can nominate a vulnerability for consideration through CISA's KEV nomination form, though final inclusion decisions rest with CISA based on those criteria.

How does KEV relate to CVSS and EPSS?

They measure different things and work best together. CVSS scores potential severity, EPSS predicts exploitation probability, and KEV confirms exploitation has actually already happened. A vulnerability appearing on all three, high severity, high predicted likelihood, and confirmed KEV status, is about as strong a signal as exists that it needs immediate attention.

Conclusion

The KEV catalog answers the one question a severity score can't answer: is this vulnerability being actively exploited right now? And BOD 26-04's shift to risk-based, tiered remediation makes that distinction matter more than ever. Saner CVEM factors known exploitation status into its prioritization alongside exposure and asset criticality, across endpoints, OS, firmware, and third-party software, so remediation effort goes toward what's genuinely under attack, not just what scored highest on a static severity chart.