What Is CISA KEV? Why Known Exploited Vulnerabilities Matter

Your vulnerability scanner reports hundreds of vulnerabilities. Which ones actually matter most?

That is one of the biggest challenges in vulnerability management. A typical scan can produce a long list of issues, each with a CVSS score, but severity alone does not tell you which vulnerability an attacker is most likely to use against your organisation.

One of the most useful questions you can ask is:

Are attackers actually exploiting this vulnerability?

This is where the CISA Known Exploited Vulnerabilities (KEV) Catalog becomes particularly valuable.

A vulnerability appearing in the KEV Catalog is not simply a vulnerability that could be exploited. It is one for which there is evidence of exploitation in the wild. That makes KEV an important input when deciding which vulnerabilities to fix first.

What is CISA KEV?

CISA, the US Cybersecurity and Infrastructure Security Agency, maintains the Known Exploited Vulnerabilities Catalog.

CISA describes the catalog as its authoritative source of vulnerabilities known to have been exploited in the wild. It is intended to help organisations prioritise vulnerability remediation based on real-world threat activity.

This is an important distinction because not every vulnerability is being actively exploited.

Consider three common pieces of vulnerability information:

CVE:

A vulnerability has been identified and assigned a unique identifier.

CVSS:

Provides a standardised assessment of the vulnerability's technical severity.

CISA KEV:

There is evidence that the vulnerability is being exploited in the wild.

These answer different questions.

A CVE tells you what the vulnerability is.

CVSS helps tell you how technically serious it is.

KEV tells you whether attackers are known to be exploiting it.

Why does "known exploited" change the risk?

Imagine your vulnerability scanner identifies two vulnerabilities:

Vulnerability A: CVSS 9.8, no known exploitation
Vulnerability B: CVSS 7.5, confirmed exploitation

It would be tempting to immediately work on the 9.8 vulnerability because it has the higher score.

But that may not be the right decision.

If vulnerability B is actively being exploited and affects an internet-facing system in your environment, it could represent a much more immediate threat.

This is why effective vulnerability management needs to look beyond CVSS.

The question isn't simply:

How bad could this vulnerability be?

It is also:

How likely is someone to exploit it, and are they already doing so?

Known exploitation provides particularly important evidence when making that decision.

KEV doesn't mean "patch everything immediately"

There is an important caveat.

A vulnerability being listed in KEV does not automatically mean you need to drop everything and patch it immediately.

Context still matters.

Suppose CISA adds a vulnerability affecting a particular VPN appliance.

If your organisation does not use that product, the vulnerability is not relevant to your environment.

Even if you do use it, consider the difference between:

An isolated, obsolete system with no network connectivity.

and:

An internet-facing VPN appliance providing remote access to your entire organisation.

Both may contain the same vulnerability. Their risk is very different.

A sensible prioritisation process therefore considers:

KEV status + exposure + asset importance + exploitability + business impact

rather than simply:

KEV = panic

KEV is threat intelligence. It does not replace understanding your own environment.

CVSS vs EPSS vs KEV

These different measures work particularly well together.

This is why CVSS isn't a risk score.

CVSS is useful, but it is only one part of the decision.

EPSS provides a probability-based assessment of the likelihood that a vulnerability will be exploited.

KEV provides something even more concrete: evidence that exploitation has already occurred in the wild.

Your own asset and business information then provides the final piece of the puzzle.

You can read more about this approach in our article CVSS Isn't a Risk Score: How to Actually Prioritise Vulnerabilities.

A practical example

Imagine your vulnerability management platform produces the following report:

Which one should you investigate first?

At first glance, vulnerability A looks like the obvious choice because it has the highest CVSS score.

But vulnerability C deserves serious attention.

It has:

• Known exploitation
• A relatively high technical severity
• A relatively high exploitation probability
• An internet-facing attack surface
• A potentially important role in the organisation's security boundary

Vulnerability B also deserves attention because of its high EPSS score and internet exposure.

The point isn't that there is always one universally correct answer.

The point is that CVSS alone cannot provide the answer.

Once you combine severity, exploitation likelihood, known exploitation and asset context, your prioritisation decisions become much more meaningful.

What does KEV mean for an SME?

Small and medium-sized businesses do not need a dedicated threat-intelligence team to make use of KEV.

A sensible vulnerability-management process can incorporate it quite easily.

1. Maintain an accurate asset inventory

You need to know what hardware, software, cloud services and internet-facing systems you actually operate.

You cannot assess whether a vulnerability matters if you don't know whether the affected technology exists in your environment.

2. Run regular vulnerability scans

Regular scanning helps identify vulnerabilities affecting your actual systems rather than trying to respond to every vulnerability published globally.

3. Identify the vulnerabilities affecting your assets

For each finding, record the relevant CVE where one exists.

4. Check those CVEs against KEV

If a vulnerability affecting your environment appears in the CISA catalog, its priority should generally increase, particularly when the affected system is exposed or business-critical.

5. Consider EPSS and CVSS

Use CVSS to understand technical severity and EPSS to understand the estimated likelihood of exploitation.

6. Prioritise remediation

Bring together:

• CVSS
• EPSS
• KEV status
• Internet exposure
• Asset criticality
• Business impact
• Existing security controls

Then decide what needs attention first.

7. Apply patches or mitigations

Remediate the vulnerability wherever possible.

8. Verify remediation

Don't assume a patch has fixed the problem. Rescan or otherwise verify that the vulnerable software has actually been updated or the vulnerable condition removed.

9. Monitor for new intelligence

The threat landscape changes continuously. A vulnerability that was previously considered a lower priority may become much more urgent if evidence of exploitation emerges.

CISA specifically encourages organisations outside the US federal government, including private-sector organisations, to use the KEV Catalog as an input to their vulnerability-management practices.

What if you can't patch?

Real-world vulnerability management isn't always as simple as:

Vulnerability found → patch installed.

Sometimes a patch cannot be applied immediately.

You might be dealing with:

• Legacy applications
• Vendor dependencies
• Unsupported software
• Operational requirements
• Change-control windows
• Availability concerns
• Systems where applying the update requires significant testing

That doesn't mean the vulnerability should simply be ignored.

Instead, consider compensating controls.

Depending on the situation, these could include:

• Removing internet exposure
• Restricting access to trusted networks
• Network segmentation
• Disabling vulnerable functionality
• Applying a vendor-provided mitigation
• Increasing monitoring
• Temporarily isolating the system

The important distinction is:

A mitigation isn't the same as remediation.

If the underlying vulnerability still exists, there should be a plan to address it properly.

A temporary workaround should not quietly become a permanent solution.

Don't just patch. Look for signs of compromise.

There is another important consideration when dealing with a vulnerability that is known to be actively exploited.

Don't automatically think:

"We'll patch it and move on."

Instead ask:

Could someone already have exploited this vulnerability against us?

If attackers are known to be exploiting a vulnerability, there is a possibility that your organisation was targeted before you applied the patch.

The appropriate investigation will depend on the vulnerability and the affected system, but could include reviewing:

• Authentication logs
• Endpoint telemetry
• Firewall logs
• Web server logs
• EDR alerts
• Unexpected accounts
• Unusual processes
• Persistence mechanisms
• Unusual outbound connections

You may find nothing.

That's good.

But it is better to make that an informed conclusion than to assume that patching automatically means the incident is over.

How does KEV relate to penetration testing?

There is an important distinction between vulnerability intelligence and attack-path analysis.

A vulnerability scanner might tell you:

CVE-XXXX-XXXX is present.

KEV might tell you:

Attackers are actually exploiting this vulnerability.

A penetration test can then help answer a different question:

What could an attacker actually achieve if this vulnerability were exploited in our environment?

For example, a penetration test might establish whether exploiting an internet-facing vulnerability could provide access to:

• Internal systems
• Administrative interfaces
• Sensitive data
• User accounts
• Privileged credentials
• Other network segments

That context can be extremely valuable when deciding how urgently a vulnerability needs to be addressed.

How KEV should fit into vulnerability management

KEV works best as part of a broader vulnerability-management process rather than as a standalone scoring system.

A practical process looks something like this:

Discover assets

↓

Identify vulnerabilities

↓

Assess CVSS

↓

Check EPSS

↓

Check CISA KEV

↓

Consider exposure and business impact

↓

Prioritise

↓

Remediate

↓

Verify

↓

Monitor for new intelligence

This approach is considerably more useful than simply sorting a vulnerability report by CVSS score and starting at the top.

The important takeaway

The CISA KEV Catalog gives organisations something that a vulnerability score cannot provide on its own: evidence of real-world exploitation.

That doesn't mean every KEV vulnerability is automatically your highest priority. You still need to consider whether the affected technology exists in your environment, how exposed it is, how important the asset is and what the potential business impact would be.

But when a vulnerability affecting a critical or internet-facing system is both severe and known to be exploited, it deserves your attention.

The key question is no longer simply:

"How severe is this vulnerability?"

It becomes:

"Are attackers using it, and are we exposed?"

That is a much better starting point for deciding what to fix first.