The KEV Catalog: CISA's List of Actively Exploited Bugs

Most vulnerability signals are predictions. A CVSS score predicts how much damage a flaw could do. An EPSS score predicts how likely it is to be used. The KEV catalog is different, because it records something that has already happened: this vulnerability is being exploited by real attackers, right now.

The Known Exploited Vulnerabilities catalog is maintained by CISA, the US Cybersecurity and Infrastructure Security Agency. It is a free, public list of CVEs backed by evidence of active exploitation. When a flaw appears on KEV, the question of whether anyone will bother to attack it is settled. That certainty is what makes the catalog the single strongest input to a patch queue.

What the catalog actually is

KEV is a plain data feed. Each entry names a CVE, the affected vendor and product, a short description of the flaw, the date it was added, and a required remediation date. The whole catalog is downloadable as JSON or CSV, so it can drop straight into a scanner, a ticketing system, or a detection pipeline.

The catalog began in November 2021 under Binding Operational Directive 22-01. Before it existed, defenders had severity ratings and a sea of proof-of-concept chatter, with no authoritative answer to the one question that matters most: which of these thousands of flaws are attackers actually using. KEV is that answer, curated by a national authority and published in the open.

How a CVE gets added

CISA applies three criteria, and a vulnerability has to meet all of them before it joins the list.

Criterion	What it requires
Assigned CVE ID	The vulnerability has a formal identifier in the CVE program
Active exploitation	Reliable evidence shows the flaw is being exploited in the wild
Clear remediation	A vendor patch, update, or defined mitigation exists to act on

The middle criterion is the strict one. Active exploitation means observed use against real targets, confirmed through trusted reporting, incident response findings, or CISA's own partners. Publishing a proof-of-concept does not qualify. Scanning activity or a researcher's exploit demonstration does not qualify. Someone has to be using the flaw against real systems.

The third criterion keeps the catalog actionable. CISA lists a vulnerability only when defenders have a concrete step to take, so every entry comes with a path to closure rather than an open-ended warning.

The federal deadlines

The part of KEV that gives it teeth is the remediation due date. Under BOD 22-01, US federal civilian executive branch agencies are required to fix every KEV entry that applies to their systems by the date CISA sets. The directive is binding, and the deadlines are public.

Due dates are typically short, often a couple of weeks from the date a CVE is added, and sometimes shorter for flaws under heavy attack. The exact window is published per entry, so anyone can see how much urgency CISA has assigned. Agencies report their remediation progress, which turns the catalog into a compliance instrument as well as an intelligence feed.

Private organisations are not bound by the directive, but the deadlines are still useful. They encode CISA's read on how quickly each flaw needs to be closed, which is free prioritisation guidance that any security team can borrow.

Why KEV is the strongest patch-now signal

Vulnerability programmes drown in numbers. A large estate can carry thousands of open findings, most rated high or critical, most of which will never be touched by an attacker. Sorting that backlog by severity alone means burning the week on theoretical risk.

KEV cuts through it. If a CVE is listed, exploitation is confirmed and the flaw belongs at the front of the queue regardless of its CVSS band. This is why the catalog sits at the top of a sensible three-signal model:

• KEV confirms exploitation is happening. Promote anything listed to the top.
• EPSS estimates the probability of exploitation soon, for flaws not yet on KEV. See EPSS Explained.
• CVSS measures how much damage a successful exploit does. See CVSS Explained.

The catalog is small relative to the full CVE universe, which is the point. It represents the concentrated set of flaws where waiting has a known cost, so closing every KEV entry that touches your estate is one of the highest-return moves in vulnerability management.

How to use KEV in practice

1. Ingest the feed automatically. Pull the JSON or CSV on a schedule and match it against your asset inventory. Manual checks fall behind fast.
2. Promote every match to the top of the queue. A KEV hit outranks a higher CVSS score that is not being exploited. Treat listing as the override rule.
3. Adopt the due dates even if you are not federal. CISA's deadline per entry is a ready-made service level for remediation.
4. Feed it to detection, not only patching. If you cannot patch a KEV flaw immediately, hunt for signs of the exploitation it describes and apply the listed mitigation in the meantime.
5. Report against it. The share of KEV entries in your environment that are closed on time is a clean, defensible metric for leadership.

KEV is the calmest signal in vulnerability management because it removes the guesswork. It does not estimate, forecast, or rate. It reports what is already being exploited, attaches a deadline, and publishes both for free. Wire it into your patch and detection workflows, treat a listing as a promotion to the top of the queue, and the catalog becomes the backbone of a defensible response to the flaws that carry real cost.

What a KEV entry contains

Each row in the catalog is a compact, structured record, and knowing the fields helps you wire it into a workflow rather than treating it as a headline list.

Every entry carries the CVE identifier, which is the join key that ties the KEV record to your scanner findings, your ticketing system, and the underlying CVE and CVSS data. Alongside it sits the affected vendor and product, so you can match the entry against your asset inventory without chasing the CVE description. A short vulnerability name and description summarise the flaw in plain terms.

The dates are where the operational weight lives. The date added tells you when CISA confirmed exploitation and started the clock. The required action date, the remediation due date, tells you when federal agencies must have the flaw fixed, and it is the field most useful to everyone else as a ready-made service level. Many entries also carry a required action field describing what to do, whether that is applying a vendor update or following a specific mitigation when no patch exists. More recent entries include a note on whether the vulnerability is known to be used in ransomware campaigns, which is a further prioritisation cue for anyone deciding what to close first.

A worked example of prioritising with KEV

Consider a security team on a Monday facing a scanner report with several thousand open findings. Sorting by CVSS puts a few hundred critical-rated flaws at the top, far more than the team can patch this week. This is the exact situation where severity-only prioritisation stalls, because most of those criticals will never be attacked and the team has no way to tell which ones will.

Now bring KEV into the sort. The team pulls the catalog feed and matches it against the same findings. Out of the thousands of open issues, a much smaller set, say a couple of dozen, match KEV entries. These are the flaws where exploitation is a confirmed fact rather than a theoretical possibility. Some of them are rated critical, and some are only rated medium, which is the important part. A medium-severity flaw that attackers are actively using is a bigger operational problem than a critical-severity flaw no one has ever exploited.

The team promotes every KEV match to the front of the queue regardless of its CVSS band, and adopts the required action date for each as the internal deadline. For the KEV entries they cannot patch immediately, they apply the listed mitigation and turn on detection for the exploitation behaviour. Only after the KEV set is handled do they return to the broader critical list, now sorted with EPSS to estimate which of the remaining flaws are most likely to be attacked next.

That sequence turns an unmanageable backlog into a defensible plan. The week's effort goes first to flaws with a known cost of waiting, and leadership can see a clean metric: the share of KEV entries in the environment closed on or before their due dates.

Detection signals and operational tells

KEV is a feed, so the signals worth watching are about how you consume it and how confirmed-exploited flaws behave in your environment.

• New KEV additions that match your inventory. The most important signal is a fresh entry landing on the catalog for a product you run. Automated matching against your asset list on every catalog update is what catches this in hours rather than weeks.
• A short gap between CVE publication and KEV listing. When a flaw reaches KEV soon after disclosure, exploitation followed disclosure quickly, which is a marker of a flaw under active, widespread attack. These deserve the most urgent handling.
• Ransomware-flagged entries. KEV notes where a vulnerability is known to feature in ransomware activity. A match on one of these in your environment is a direct line to a high-consequence outcome.
• KEV entries you cannot fully remediate. Any listed flaw you have not closed by its due date is a standing exposure worth tracking as a named risk, with a compensating mitigation and active detection in place until it is patched.
• Exploitation indicators for listed flaws. For KEV entries you have not yet closed, hunting for the specific exploitation behaviour the entry describes turns the catalog into a detection input, not only a patch input.

KEV compared with the other vulnerability signals

KEV, CVSS, and EPSS answer three different questions, and using them together is what turns raw vulnerability data into a queue. Confusing them is the most common mistake teams make.

Signal	Question it answers	Nature	Role in the queue
KEV	Is it being exploited now	Confirmed fact	Top promotion rule, overrides the rest
EPSS	How likely is exploitation soon	Probability estimate	Ranks flaws not yet on KEV
CVSS	How much damage if exploited	Severity rating	Measures impact, breaks ties

The clean mental model is a sequence. KEV first: anything listed goes to the top, because waiting has a known cost. EPSS next: among the flaws not on KEV, it estimates which are most likely to be attacked, so you can act before they are exploited. CVSS last: it tells you how bad a successful exploit would be, which is essential for understanding impact and useful for breaking ties, and weak as a standalone sort because most critical flaws are never attacked. See CVSS Explained and EPSS Explained for how each is built.

Common misconceptions

"If it is not on KEV, it is safe to defer." KEV only captures exploitation that has been confirmed and reported. Quiet campaigns and brand-new attacks always run ahead of any list. KEV is a floor for urgency, and EPSS and severity still matter for everything it has not yet flagged.

"KEV is only relevant to federal agencies." The binding deadlines apply to US federal civilian agencies, but the catalog is free and public, and its confirmation of active exploitation is valuable to any organisation in any sector. The due dates are usable as a ready-made service level regardless of who you are.

"A high CVSS score is more urgent than a KEV listing." This inverts the right order. A KEV listing means exploitation is confirmed, which outranks a severity score that only estimates potential impact. A medium-CVSS flaw on KEV should be patched ahead of a critical-CVSS flaw that has never been exploited.

"KEV tells me I have been compromised." A KEV entry means a flaw is being exploited somewhere in the world, not that your specific systems have been attacked. It is a signal to patch and to hunt for exploitation, and it does not by itself indicate a breach in your environment.

"Once I patch a KEV entry I can forget it." Patching closes the exposure, and the record still matters for reporting and for confirming the fix held. For flaws you patch late or mitigate rather than patch, the entry stays a tracked item until it is genuinely closed.

How KEV came about

Before KEV existed, defenders had two broad classes of vulnerability signal and a gap between them. Severity ratings from CVSS told them how damaging a flaw could be in theory, and a noisy stream of proof-of-concept releases and researcher chatter hinted at what might be exploitable. Neither answered the question that most determines risk: which of these thousands of flaws are attackers actually using right now. Teams sorted their backlogs by severity, burned effort on flaws that would never be touched, and sometimes missed lower-rated flaws that were under active attack.

CISA created the Known Exploited Vulnerabilities catalog in November 2021 under Binding Operational Directive 22-01 to close that gap. The directive did two things at once. It established the catalog as an authoritative, curated list of flaws with confirmed active exploitation, and it made remediation of those flaws mandatory for federal civilian agencies within set deadlines. That combination of a trusted evidence source and a binding clock is what gave the catalog its force.

The catalog has grown steadily since, and its influence has spread well beyond the federal agencies it binds. Vulnerability scanners, patch-management tools, and threat-intelligence platforms now ingest the KEV feed and surface listings as a priority flag, so the catalog has become a shared reference point across the industry. Later refinements, such as flagging entries tied to ransomware activity, have made it more useful for prioritisation without changing its core purpose: to state, with evidence, which flaws carry a known cost of delay.

Wiring KEV into a workflow

The value of KEV shows up only when it is automated, because a catalog you check by hand every few weeks will always trail the additions that matter. A workable pipeline has a few moving parts.

First, pull the feed on a schedule and store it. The JSON or CSV is small and changes often, so fetching it daily or more frequently keeps your copy current. Second, match it against a live asset inventory. The match is on vendor and product, joined through the CVE identifier to your scanner findings, which is why keeping an accurate inventory of what you actually run is the unglamorous foundation the whole thing rests on. A KEV entry for a product you do not have is noise, and a KEV entry for a product you forgot you run is exactly the exposure you need to find.

Third, route matches automatically into your ticketing system with the required action date carried through as the deadline, so a confirmed-exploited flaw becomes a tracked task the moment it is added rather than whenever someone next looks. Fourth, feed the same matches to your detection team, so flaws you cannot patch immediately get exploitation hunting and the listed mitigation in the interim.

Finally, report on it. The percentage of KEV entries in your environment closed on or before their due dates is a clean, defensible metric that leadership can understand at a glance, and it maps directly to the risk of the flaws where waiting has a known cost.

Frequently asked questions

Is the KEV catalog free to use? Yes. It is public and downloadable as JSON or CSV at no cost, so any organisation can ingest it and match it against their inventory regardless of sector or size. The binding deadlines apply only to US federal civilian agencies, and the data is free for everyone.

How often is KEV updated? CISA adds entries on an ongoing basis as new exploitation is confirmed, so the catalog changes frequently rather than on a fixed schedule. This is why automated ingestion on each update beats periodic manual checks, which fall behind quickly.

What is the difference between KEV and a CVSS score? KEV confirms that a flaw is being exploited in the wild, which is a fact about the real world. CVSS rates how much damage a successful exploit would cause, which is an assessment of potential impact. KEV answers whether to worry now, CVSS answers how bad it would be, and they are strongest used together.

Does a KEV listing mean I have been hacked? No. It means the flaw is being exploited somewhere, so it is a strong signal to patch quickly and to look for exploitation in your environment. It is not evidence that your specific systems have been compromised.

What are the three criteria for adding a CVE to KEV? The vulnerability must have an assigned CVE ID, there must be reliable evidence it is being actively exploited in the wild, and there must be a clear remediation action such as a vendor patch or a defined mitigation. All three are required, and a published proof-of-concept alone does not meet the exploitation bar.

Should a private company follow the federal remediation deadlines? It is a sensible default. The due dates encode CISA's read on how urgently each confirmed-exploited flaw needs closing, which is free prioritisation guidance. Many private organisations adopt the KEV due dates directly as internal remediation service levels.

How is KEV different from the CVE program and the NVD? The CVE program assigns the identifier and the core record for a flaw, and the NVD adds severity scoring and enrichment on top of CVE records. KEV is a separate, curated list that flags which of those CVEs are confirmed to be actively exploited. See The CVE System Explained for how the identifiers themselves are created.

Related guides

• CVSS Explained
• EPSS Explained
• The CVE System Explained
• Vulnerability Management Lifecycle
• Zero-Day Vulnerabilities