What Is the CISA KEV Catalogue and Why Should It Drive Your Patching?

Imagine your vulnerability scanner hands you a report with two thousand findings, four hundred of them marked critical. Your team can realistically fix fifty this week. Which fifty?

For years, most organisations answered that question with a severity score. Sort by CVSS, start at the top, work down. It feels rigorous. It is also one of the main reasons attackers keep getting in through holes that were known about, scored and sitting in a ticket queue.

There is a better starting point, and it is free. The Known Exploited Vulnerabilities catalogue, run by the US Cybersecurity and Infrastructure Security Agency (CISA), lists the vulnerabilities attackers are actually using. This guide explains what the KEV catalogue is, why it beats severity scores for deciding what to patch first and how to build it into your patching process, wherever in the world you operate.

What the KEV Catalogue Is and Who Maintains It

The KEV catalogue is a public list of vulnerabilities that have been exploited in the wild. It is maintained by CISA, the US government agency responsible for protecting federal networks and critical infrastructure, and was launched in November 2021.

It arrived with a legal instrument attached. Binding Operational Directive 22-01 requires US federal civilian agencies to fix every vulnerability in the catalogue by a due date set for each entry. When the directive was issued, the standard deadlines were two weeks for vulnerabilities given a CVE identifier from 2021 onwards and six months for older ones. CISA can set shorter deadlines when the risk demands it.

Outside US federal government, nobody is obliged to follow it. That is exactly why it is so useful. CISA has done the hard work of confirming exploitation, and anyone can benefit.

It is also worth being clear about what KEV is not. It is not a list of American vulnerabilities. The products in it are the same firewalls, VPN gateways, email servers, browsers and operating systems that UK and European organisations run every day. When an attacker finds a reliable way into a popular remote access appliance, they do not check which country the owner is in first.

The Three Tests for Getting In

CISA publishes its criteria. A vulnerability is only added when it passes all three:

1. It has a CVE ID. The flaw has been formally catalogued in the Common Vulnerabilities and Exposures system.
2. There is reliable evidence of active exploitation. Not a theoretical attack or a proof of concept on a blog, but attackers using it against real systems.
3. There is clear remediation guidance. A patch, an update or a documented mitigation exists, so there is something you can actually do.

That third test matters. KEV is not a list of scary things to worry about. It is a list of things you can fix today that attackers are using today.

What Each Entry Tells You

Every entry includes the CVE, the vendor and product, a short description, the date it was added, the action required and the federal due date. There is also a field showing whether the vulnerability is known to have been used in ransomware campaigns, which is a useful signal when you are deciding between two urgent fixes. The whole catalogue can be downloaded as CSV or JSON, so it plugs straight into scanners, ticketing systems and dashboards.

Why a High CVSS Score Is Not the Same as Real Risk

The Common Vulnerability Scoring System (CVSS) rates how severe a vulnerability could be: how easy it is to exploit in principle, whether it needs a user to click something and what an attacker could do once inside. It is a valuable measure of potential impact.

What CVSS does not tell you is whether anyone is actually exploiting the flaw. A vulnerability scored 9.8 in obscure software that nobody attacks may never cause harm. A vulnerability scored 7.5 in a widely used remote access appliance might be the way into hundreds of organisations this month.

When everything critical is treated as urgent, nothing really is. Teams burn effort on findings that pose little real risk, while the handful of flaws attackers are actively using wait their turn behind them. We explored this pattern in why high severity vulnerabilities keep getting ignored and exploited. KEV cuts through it by answering the question severity scores cannot: is this being used against people right now?

It also works in the other direction. Some vulnerabilities in KEV carry modest CVSS scores. On their own they would sit in the middle of a backlog. Combined with another flaw, or sitting on an exposed system, they become the first step of a real attack. KEV pulls them to the top where they belong.

How to Use KEV in Your Patching Process

The good news is that KEV does not require a new tool or a new team. It requires a change in the order you do things. Here is a practical approach that works for organisations of most sizes.

1. Make KEV a Priority Rule, Not a Report

Write it into your vulnerability management policy: any vulnerability in the KEV catalogue that affects your environment is treated as urgent, with a shorter fix window than its severity alone would give it. A sensible benchmark is the federal one: aim for two weeks, with internet-facing systems handled faster still.

2. Automate the Matching

Checking a web page by hand is fine for a week and then it quietly stops happening. Many vulnerability scanners can now tag findings that appear in KEV, and the JSON feed makes it straightforward to build an alert when a new entry matches software you run. The aim is that a new KEV addition affecting you creates a ticket automatically, with an owner.

3. Look Back as Well as Forward

When a vulnerability is added to KEV, attackers have already been using it, sometimes for weeks. Patching closes the door, but it does not tell you whether someone walked through it first. For exposed systems, pair the fix with a check for indicators of compromise and unusual activity. This is where continuous monitoring from a managed detection and response service earns its keep.

4. Track Exceptions Honestly

Sometimes you cannot patch: a legacy system, a supplier who has not released a fix for your version or a service that cannot be taken down. Record the exception, apply a mitigation such as removing internet access or adding monitoring, and set a review date. An exception with no end date is just a vulnerability you have decided to forget.

Combining KEV With Asset Criticality and Exposure

KEV tells you what attackers are using. It cannot tell you which of your systems matter most or which ones they can reach. Real prioritisation combines three questions:

• Is it being exploited? KEV, backed by threat intelligence for your sector.
• Can an attacker reach it? Internet-facing systems, remote access and anything exposed to partners come first.
• What happens if it falls? Systems that run critical services, hold sensitive data or control access to everything else, such as identity platforms, outrank a test server.

Try it yourself with the triage tool below. It shows how the three answers change the urgency of the same vulnerability.

None of this works without an accurate asset inventory. You cannot match KEV against software you do not know you run. The organisations that respond fastest to a new KEV entry are almost always the ones that can answer, within minutes, where a given product and version is deployed. If that question takes your team days, fixing the inventory will do more for your security than any single patch.

Exposure also changes over time. A server that was internal last quarter may have been opened up for a supplier this quarter. Regular continuous threat exposure management keeps your view of what is reachable current, so your KEV priorities stay accurate.

Track It Live on Cybergen Threat Watch

To make this easier, we built Cybergen Threat Watch. It tracks actively exploited vulnerabilities as they are confirmed and presents them in plain English: what is affected, why it matters and what to do about it.

Instead of checking a spreadsheet, you can see at a glance which exploited flaws were added recently and which products they affect. It is free to use and you can sign up for updates. If you only change one habit after reading this article, make it a weekly look at Threat Watch alongside your patch report.

When a critical flaw lands in software that is everywhere, speed matters. Recent examples such as the two critical PHP vulnerabilities show how quickly a newly disclosed weakness can move from announcement to mass exploitation.

How Cybergen Can Help

Turning KEV from a good idea into a working process is mostly about joining up data, people and timelines. We help organisations do exactly that:

• Vulnerability management that ranks findings by exploitation, exposure and business impact, not severity alone
• Threat intelligence that tells you which exploited vulnerabilities and attacker groups matter to your sector
• Continuous threat exposure management to keep your view of what is reachable up to date
• CREST penetration testing to prove which weaknesses can really be chained into an attack
• 24/7 managed detection and response to catch exploitation that happens before a patch lands

If your vulnerability backlog feels unmanageable, talk to us. We will help you find the small number of fixes that remove the most risk, and build the routine that keeps it that way.

Frequently Asked Questions