CISA KEV Explained: How to Prioritise the 1,629 Actively Exploited CVEs That Actually Matter

The CISA Known Exploited Vulnerabilities (KEV) catalogue is the most actionable threat intelligence feed available to enterprise security teams — and it is free. Maintained by the US Cybersecurity and Infrastructure Security Agency, the KEV catalogue lists CVEs confirmed as actively exploited in the wild by real threat actors. As of July 2026, it contains 1,629 entries, of which 327 are linked to ransomware campaigns.

Despite being publicly available, many security teams either do not systematically incorporate the KEV catalogue into their vulnerability management programmes, or they treat it as just another list rather than understanding what makes it uniquely valuable. This guide explains what the KEV catalogue is, why it matters more than CVSS scores for prioritisation, and how to operationalise it in your vulnerability management workflow.

What Makes the CISA KEV Different from CVSS

The Common Vulnerability Scoring System (CVSS) scores vulnerabilities on a theoretical severity scale from 0 to 10, based on factors like attack complexity, privileges required, and potential impact. CVSS is useful for understanding the inherent nature of a vulnerability, but it is a poor prioritisation tool for one critical reason: it does not tell you whether the vulnerability is actually being exploited by attackers.

A vulnerability can have a CVSS score of 5.3 — Medium severity — and yet appear on the CISA KEV list because real threat actors have developed working exploits and are actively using it against production systems right now. Conversely, a CVSS 9.8 Critical vulnerability might have been disclosed three years ago and never weaponised in practice. Patching by CVSS score alone means you may be spending your patch window on theoretical vulnerabilities while ignoring the ones attackers are actually using.

The KEV catalogue cuts through this noise. CISA adds a CVE to the KEV only when there is reliable evidence of active exploitation — either from confirmed incident response cases, threat intelligence, or direct observation. A KEV entry means: attackers have a working exploit, they are using it, and your systems may already be targeted.

The 1,629 Number in Context

There are over 240,000 CVEs in the National Vulnerability Database (NVD) as of mid-2026. The 1,629 CVEs on the CISA KEV list represent less than 1% of all known vulnerabilities — but they represent the ones with confirmed exploitation evidence. Your vulnerability management programme, if it operates at all like most enterprise programmes, is drowning in thousands of findings scored at High or Critical. The KEV catalogue gives you a defensible, intelligence-driven basis for deciding where to focus your remediation effort first.

The 327 ransomware-linked entries deserve particular attention. Ransomware operators are systematic in their exploitation of known vulnerabilities — particularly in internet-facing systems like VPN appliances, remote access tools, and web applications. If any KEV entry with a ransomware flag is present in your environment, it should be treated as a P0 incident-level remediation item regardless of its CVSS score.

How to Operationalise the KEV Catalogue

Step 1 — Automated daily sync. The CISA KEV catalogue is updated continuously and is also available as a JSON feed at cisa.gov. Integrate this feed into your vulnerability management platform so that every new KEV entry automatically elevates the priority of any matching finding in your environment. Manual weekly checks are not sufficient — CISA can add multiple new entries in a single day following a major exploitation event.

Step 2 — Cross-reference with your asset inventory. The KEV entry alone is not enough — you need to know whether you have affected software in your environment. This requires an accurate, current asset inventory with software version data. If your asset inventory is not current, KEV integration is only partially effective.

Step 3 — Separate SLA for KEV findings. Establish a shorter, harder remediation SLA for KEV-confirmed findings. CISA's Binding Operational Directive BOD 22-01 requires US federal agencies to remediate KEV vulnerabilities within 14 days. While this is not binding on private sector organisations, the 14-day standard is a reasonable model for any organisation that takes exploitation risk seriously.

Step 4 — Active exploitation validation. Knowing a KEV vulnerability exists in your environment and knowing it is actually exploitable in your specific configuration are different things. Firewall rules, network segmentation, authentication requirements, and compensating controls may prevent exploitation even when the vulnerable software is present. Active proof-of-concept validation — not just version-based detection — is what provides the definitive answer.

Step 5 — Executive and audit reporting. The KEV catalogue provides an excellent basis for board-level risk reporting because it translates technical findings into a clear business narrative: "We have X vulnerabilities on our systems that attackers are currently exploiting against organisations like ours." This is more effective than CVSS-based reporting for driving remediation investment decisions.

KEV and Compliance Frameworks

Several major compliance frameworks now reference the KEV catalogue explicitly or implicitly. DORA's RTS on TLPT references the TIBER-EU threat intelligence methodology which incorporates active exploitation data consistent with KEV. PCI DSS v4.0 (effective March 2025) requires organisations to use threat intelligence to prioritise vulnerability remediation — the KEV catalogue is a directly applicable source. NIS2 Article 21's requirement to assess the effectiveness of security measures implies that known actively-exploited vulnerabilities in your environment represent a clear control failure.

KEV Prioritisation Matrix