CISA's Known Exploited Vulnerabilities (KEV) Explained

Security teams today are drowning in vulnerability data. In 2024 alone, 41,000 new CVEs were published, with 61% of them labeled “high” or “critical.” But not every vulnerability is actively exploited in the wild. For defenders, the key question is: which of these pose a real, immediate threat?

To answer that, the Cybersecurity and Infrastructure Security Agency (CISA) created the Known Exploited Vulnerabilities (KEV) catalog, a practical, actionable resource that helps organizations focus on the small subset of vulnerabilities that actually matter most.

What Is the CISA KEV Catalog?

The KEV Catalog is an official list of security flaws that attackers have actively exploited. Maintained by CISA, it helps organizations prioritize patching based on real-world threat activity, not just theoretical risk.

Although developed by a U.S. agency, the KEV Catalog is globally relevant. It highlights CVEs confirmed through threat intelligence, incident response, and observed exploitation. KEV is binary, either a CVE has been exploited and added, or it hasn’t. Unlike CVSS or EPSS, it does not estimate likelihood or severity, but reflects confirmed use in the wild, making it one of the key resources for risk-based exposure management.

Why Does KEV Matter?

Here are three main points that make CISA’s KEV catalog worth considering in vulnerability prioritization.

It Highlights What’s Real, Not Just What’s Possible

Vulnerability scanners often list every CVE that matches their database, even if there is no evidence it has ever been exploited. This results in long lists of theoretical risks. 

The KEV catalog provides a global binary signal. A vulnerability is either confirmed to have been exploited in the wild or it is not. While this does not confirm exploitability in your specific environment, it is still valuable context. 

It Drives Risk-Based Prioritization

A vulnerability listed in the KEV catalog signals an immediate need to patch or mitigate. These entries often align with techniques like initial access or privilege escalation, common steps in malware (like ransomware) and APT campaigns. Many target internet-facing services, VPNs, firewalls, and unpatched endpoints, making them ideal for opportunistic scanning and automated exploitation. 

For teams overwhelmed by volume, the KEV catalog helps cut through the noise and focus on CVEs with confirmed operational impact, enabling faster and more effective remediation.

It’s a Federal Requirement

Under Binding Operational Directive (BOD) 22-01, all U.S. federal civilian executive branch (FCEB) agencies are required to remediate vulnerabilities listed in the KEV catalog within specified timeframes. These timeframes are determined by the date a vulnerability is added to the catalog and its associated risk.

While BOD 22-01 mandates compliance for FCEB agencies, CISA strongly recommends that all organizations, including those in the private sector and state, local, tribal, and territorial (SLTT) governments, prioritize the remediation of KEV-listed vulnerabilities to enhance their security posture.

How the KEV Catalog Works?

The KEV catalog is designed for clarity and action. Each entry provides essential details, what the vulnerability is, where it exists, when it was added, and what needs to be done. Unlike traditional databases updated on a schedule, KEV entries are added dynamically in response to verified exploitation activity. This ensures defenders are always working with current, high-confidence intelligence.

Each KEV entry includes the following ID information.

• CVE ID: The standard identifier for the vulnerability.

• Vendor and Product: The affected software or hardware.

• Vulnerability Name: A short, descriptive title.

• Date Added to Catalog: When CISA officially included it.

• Required Remediation Deadline (for federal agencies).

• Action: Typically “apply updates per vendor instructions.”

Importantly, vulnerabilities are added continuously, based on real-world events, not on a fixed update schedule.

Analyzing a Real KEV Entry Step by Step

Let’s walk through a real-world style example of how a KEV entry might appear and what it tells us.

• CVE ID: CVE-2025-22457

• Vendor: Ivanti

• Product: Connect Secure, Policy Secure, and ZTA Gateways

• Description: Stack-based buffer overflow vulnerability that allows a remote unauthenticated attacker to achieve remote code execution.

• Date Added: April 4, 2025

• Due Date: April 11, 2025

• Required Action: Apply mitigations as set forth in the CISA instructions.

• Why It’s Critical: Known to be actively exploited in ransomware campaigns. Affects widely deployed remote access solutions, making it a high-value target for threat actors seeking initial access into enterprise networks.

How to Interpret a KEV Entry?

This KEV entry illustrates why the catalog matters. CVE-2025-22457 impacts Ivanti’s VPN and gateway solutions, services that sit at the perimeter of enterprise environments and are accessible from the internet. These products are often targeted by threat actors looking to gain initial access with little to no user interaction.

The fact that the vulnerability allows remote code execution without authentication and has been confirmed in active ransomware operations raises its criticality even further. In this case, the KEV listing gives defenders high-confidence intelligence that the vulnerability is not just severe on paper, but is actively being exploited in real attacks. The rapid due date, just seven days after the CVE was added, also reflects the urgency assigned to it under Binding Operational Directive (BOD) 22-01.

For organizations using Ivanti infrastructure, this entry serves as a clear signal to verify exposure, apply vendor mitigations immediately, and validate security control effectiveness through testing or simulation. Even for organizations not directly impacted, the entry reinforces broader trends in attacker behavior, especially the targeting of edge devices and VPN gateways.

What Qualifies a Vulnerability for Inclusion in the KEV Catalog?

CISA uses a combination of intelligence feeds, incident data, public reporting, and interagency collaboration to verify exploitation. A CVE may be added to the KEV catalog if:

• It has been used in the wild by threat actors.
• There is enough confidence in the exploitability of the issue.
• It poses a risk to federal networks or critical infrastructure.

This means a vulnerability might not be included right after disclosure, it’s the exploitation activity that triggers its addition, not its CVSS score or vendor rating.

Where KEV Fits Among Vulnerability Prioritization Metrics?

Each of these metrics plays a distinct role in exposure management. 

CVSS reflects theoretical severity. EPSS estimates the likelihood of future exploitation. LEV looks backward to assess the probability of past exploitation. KEV offers a binary view based on confirmed real-world abuse. Together, they provide a broader perspective from potential to proven risk.

However, all four share a fundamental limitation. They rely on global data and do not account for whether a vulnerability is actually exploitable in your specific IT environment. 

In the final section, we will examine the limitations of KEV in more detail. 

How to Operationalize CISA’s KEV Catalog?

Here’s how security teams can integrate KEV into their workflow:

Integrate with Exposure Management Tools

Modern exposure validation solutions now support integrations that calculate a tailored criticality score based on your organization's unique IT environment. These platforms factor in both confirmed exploitation in the wild and validated exploitability within your specific context. This approach allows you to identify which actively exploited vulnerabilities pose real risk to your systems and generate prioritized remediation plans accordingly.

Cross-Reference with Threat Intelligence

When a CVE is present in both your threat intelligence feeds and the KEV catalog, it can signal a high-priority threat. Correlating these sources may strengthen your visibility, reduce blind spots, and help validate which vulnerabilities are both relevant and active in the threat landscape.

Map to Asset Criticality

Not all KEV-listed vulnerabilities carry the same level of risk in your environment. To prioritize effectively, align each CVE with asset criticality and exposure context, such as whether it affects internet-facing systems or enables lateral movement. This mapping helps ensure remediation efforts target the vulnerabilities that matter most to your operations.

Validate Control Effectiveness

Just patching isn’t enough. Use Breach and Attack Simulation (BAS) tools and automated pentesting solutions to simulate real-world attacks involving KEV-listed CVEs. These technologies help confirm whether your controls can detect and block exploitation attempts in practice, not just in theory. 

They also provide critical evidence to deprioritize CVEs that may have high severity scores but pose low risk in your environment, saving valuable time and potentially avoiding patching within tight SLAs, such as the 25-hour window often required for critical vulnerabilities.

Common Patterns in KEV Entries

The KEV catalog reveals consistent trends in how attackers operate and what they target. These patterns reflect the vulnerabilities that continue to offer the highest return for adversaries and the areas where organizations are most at risk.

Common trends include:

• Public-facing services such as Microsoft Exchange, Apache, and Confluence are frequent targets due to their accessibility and configuration complexity

• Remote access systems like VPNs and firewalls are often exploited to gain initial footholds in enterprise environments

• Privilege escalation vulnerabilities in Windows and Linux remain popular in post-compromise activity

• Older CVEs continue to appear in the catalog, demonstrating that many exploited flaws are not new but simply left unpatched

• Widely used third-party components can lead to mass exploitation when vulnerabilities are discovered

These patterns reinforce the importance of addressing exposed systems quickly and continuously validating whether existing controls are effective against known exploited threats.

Limitations of the KEV Catalog

While the KEV catalog is a valuable resource for identifying actively exploited vulnerabilities, it is not without limitations:

• Not all exploited CVEs are added immediately. There is often a delay between when a vulnerability is observed in the wild and when it appears in the catalog.

• KEV is retrospective, not predictive. It shows what has been exploited but offers no insight into what might be targeted next.

• Some vulnerabilities are used in highly targeted attacks and may never be widely reported or included.

• KEV does not assess whether a vulnerability is exploitable in your specific environment. It is a global binary signal, not an environment-aware risk indicator.

This lack of context can create a false sense of urgency. 

Because of this, many organizations go beyond KEV. 

Exposure management platforms now incorporate additional metrics like CVSS, EPSS to estimate the likelihood of exploitation, along with asset criticality, threat intelligence, and exposure validation to assess context and business impact.

To determine whether their defenses can actually block or detect real-world threats, they use adversarial exposure validation tools and technologies such as BAS and automated penetration testing. These methods test security controls under realistic conditions, helping teams move from assumptions to evidence when prioritizing vulnerabilities.

When combined, these inputs enable smarter and more effective risk-based decision-making.

Is it Logical to Fully Rely on KEV as a Security Compass?

In a world flooded with CVEs, the KEV catalog feels like a lifeline. It offers certainty when everything else is a prediction. But clarity is not the same as context.

KEV tells you where attackers have already struck, it doesn’t tell you whether you’re actually at risk. It’s global, binary, and blind to your environment.

Treating every KEV-listed CVE like a fire drill burns time, budget, and resources. Without validation, you’re just reacting to someone else’s emergency.

Use KEV for what it is, a spotlight on confirmed threats. But don’t stop there. Layer it with threat modeling, exposure validation, and real-world testing to understand which fires could spread to your environment—and which are already contained.

Because in exposure management, guessing is a risk. Proof is power.