CISA's Known Exploited Vulnerabilities (KEV) catalog is a free, public list of vulnerabilities that attackers are known to be exploiting. US federal civilian agencies must fix listed vulnerabilities by set deadlines under Binding Operational Directive 22-01. Everyone else can use the catalog as a shortcut to the vulnerabilities that matter most. Download it as CSV or JSON, match it against your asset inventory and scan results by CVE ID, and fix the matches first, starting with internet-facing systems.
This guide covers what the directive requires, how CISA decides what goes into the catalog, and how to build it into a vulnerability program at a small or mid-sized organization.
What is the KEV catalog?
The KEV catalog is a list of vulnerabilities, maintained by the Cybersecurity and Infrastructure Security Agency (CISA), for which there is reliable evidence of exploitation in the wild. CISA launched it on November 3, 2021, together with Binding Operational Directive (BOD) 22-01, and has been adding entries ever since.
Each entry includes:
- the CVE ID
- the vendor or project, and the product affected
- a short vulnerability name and description
- the date CISA added it
- the required action, usually to apply the vendor's updates
- the due date by which federal agencies must remediate it
The catalog is deliberately narrow. It doesn't try to cover every serious vulnerability, only the ones with evidence that attackers are using them.
What does BOD 22-01 require?
BOD 22-01, "Reducing the Significant Risk of Known Exploited Vulnerabilities", was issued on November 3, 2021. It applies to federal civilian executive branch agencies and covers "all software and hardware found on federal information systems managed on agency premises or hosted by third parties on an agency's behalf."
That last clause matters for the private sector. Contractors and cloud providers that run systems for agencies can fall within scope. In March 2022, FedRAMP issued guidance telling cloud service providers that maintain federal information that they are covered and must implement the directive's actions.
What are the remediation deadlines?
The directive set out these requirements:
| Requirement | Deadline |
|---|---|
| Review and update internal vulnerability management procedures | Within 60 days of issuance |
| Remediate catalog vulnerabilities with CVE IDs assigned before 2021 | Default of six months |
| Remediate all other catalog vulnerabilities | Default of two weeks |
| Report status through the CDM Federal Dashboard or CyberScope | Quarterly at first, more often later (see below) |
For the vulnerabilities in the initial catalog, the six-month window for older CVEs ran out in early May 2022. Newer entries each carry their own due date in the catalog, and the directive says the default timelines "may be adjusted in the case of grave risk to the Federal Enterprise."
On reporting, agencies could start with quarterly CyberScope submissions or use the CDM Federal Dashboard. From October 1, 2022, agencies that haven't moved their reporting to the dashboard will need to update their status through CyberScope every two weeks.
How does a vulnerability get into the KEV catalog?
CISA uses three criteria. All three must be met:
- The vulnerability has an assigned CVE ID. No CVE, no entry. This keeps the catalog easy to match against scanners and advisories.
- There is reliable evidence that it has been actively exploited in the wild. This is the core of the catalog. A published proof-of-concept shows that a vulnerability can be exploited, which isn't the same as evidence that it is being exploited.
- There is clear remediation guidance. Usually that's a vendor update. For products that no longer receive updates, the required action may be to remove or disconnect them.
The third criterion means the catalog can lag behind exploitation. A vulnerability being exploited before a fix exists won't appear until there's something concrete for agencies to do about it.
Why should organizations outside government use it?
CISA's announcements of new catalog entries routinely urge all organizations, not just federal agencies, to prioritize fixing catalog vulnerabilities as part of their vulnerability management. There are good practical reasons to do so.
- It's short. Compared with the many thousands of CVEs published every year, the catalog is a manageable list.
- It's evidence-based. Every entry has passed CISA's exploitation test, which removes much of the guesswork from prioritization.
- It's free and machine-readable. The CSV and JSON files are easy to join to scanner output.
- It comes with a benchmark. The federal due dates give you a defensible reference point when setting your own deadlines.
For a small team with limited patching hours, "fix every KEV match first" is one of the simplest high-value rules you can adopt.
How do you use the KEV catalog, step by step?
You can do all of this with spreadsheets and a short script. Dedicated tooling helps at scale, but it isn't a prerequisite.
1. Download the catalog regularly
The catalog page offers CSV and JSON downloads. Pick whichever your tools handle best, and automate the download so it runs at least weekly, or daily if you can.
2. Match it against your environment
Join the catalog to your scanner results by CVE ID. That catches most matches.
Then do a second pass by vendor and product against your asset inventory. Scanners often miss network appliances, firmware and management interfaces, and those devices show up regularly in the catalog.
3. Triage matches by exposure
Not every match is equally urgent. Put internet-facing systems first, then systems that hold sensitive data or control access (identity, remote access, backups), then everything else.
4. Set your own deadlines
Decide how quickly you'll fix KEV matches, and write it down. The federal two-week default is a sensible starting point. For internet-facing systems, a shorter internal target is often justified.
5. Fix, then verify
Apply the required action, then rescan or check the version to confirm the fix took. Mark the finding closed only after verification.
6. Watch for new additions
Compare each download with the previous one, using the "date added" field, and alert on new entries that match your inventory. New additions are where speed matters most.
7. Track a few simple metrics
Leadership doesn't need a dashboard of hundreds of numbers. Three are enough: open KEV matches, the age of the oldest one, and the share fixed within your internal deadline.
What are the limitations of the KEV catalog?
The catalog is a strong signal, but it shouldn't be your only one.
- Absence isn't safety. A vulnerability that isn't listed may still be exploited. CISA simply hasn't confirmed it, or it doesn't meet all three criteria yet.
- It only covers CVEs. Misconfigurations, exposed cloud storage, default credentials and other weaknesses without a CVE won't appear.
- It's chosen with the federal enterprise in mind. The directive describes the catalog as covering exploited vulnerabilities that carry significant risk to the federal enterprise. Most entries affect widely used products, but the selection isn't tailored to your environment.
- It doesn't rank entries. Every listed vulnerability is important, but you still need exposure and asset context to decide which match to fix first.
Pair the catalog with severity scores, exploit prediction data such as FIRST's EPSS, and your own knowledge of which systems matter.
Frequently asked questions
Is the KEV catalog mandatory for private companies?
Not by law. BOD 22-01 binds federal civilian agencies. It can still apply to you indirectly if you operate systems on an agency's behalf, as FedRAMP's guidance for cloud providers shows, or if a customer contract requires it.
How often does CISA update the catalog?
There's no fixed schedule. CISA adds entries as it confirms exploitation, so checking daily or at least weekly is the safest approach.
What if we can't patch a KEV vulnerability in time?
Reduce exposure while you work on it. Restrict network access, disable the affected feature, or take the system offline if it's end-of-life. Record the exception with an owner and an expiry date so it doesn't turn into a permanent gap.
Should KEV matches jump ahead of critical CVSS findings?
In most cases, yes. A known-exploited vulnerability on an exposed system is a more immediate problem than a critical-rated one nobody is using. Use exposure and asset importance to decide between the two when it's close.
Next steps
- Automate a regular download of the KEV catalog in CSV or JSON.
- Match it against scan results by CVE ID and against your inventory by vendor and product.
- Fix internet-facing matches first, with a written internal deadline.
- Alert on new catalog entries that match your environment.
- Treat the catalog as your top-priority list, not your only list.