CISA KEV Triage: How to Prioritize Known Exploited Vulnerabilities When You Can't Patch Everything

CISA adds a CVE to the KEV catalog only when it meets a specific evidence bar: the vulnerability has a CVE ID assigned, there is credible evidence of active exploitation in the wild, and clear remediation guidance is available. CISA does not add theoretical risks or newly disclosed vulnerabilities without exploitation evidence.

This evidence bar makes KEV meaningfully different from a vulnerability scanner output or a list of high-CVSS CVEs. A vulnerability scanner may flag 500 high-severity findings across your environment. Only a small fraction will ever be exploited in real attacks. KEV entries have already crossed that threshold.

The catalog is not exhaustive. Thousands of CVEs are exploited in the wild without appearing in KEV, particularly those targeting obscure or niche products. KEV represents confirmed exploitation that CISA has verified, it is a floor, not a ceiling, for your patching priorities.

For federal agencies, patching KEV entries within the mandated timeline (typically 14 days for internet-facing assets, 60 days for others) is legally required under BOD 22-01. For private organizations, CISA frames KEV as a strong recommendation. The business case is clear regardless of legal obligation: 60% of ransomware incidents in 2025 exploited a CVE that was already in the KEV catalog at the time of the attack.

A common mistake when triaging KEV entries is sorting by CVSS score and patching top-down. CVSS measures the theoretical maximum severity of a vulnerability under ideal exploit conditions. It does not measure how likely the vulnerability is to be exploited in your environment, how difficult it is to reach, or whether it affects assets that matter to your business.

Two CVEs can both sit in KEV with very different risk profiles. A CVSS 9.8 remote code execution vulnerability in an internet-facing VPN product with a public exploit is an immediate crisis. A CVSS 9.8 vulnerability in a legacy desktop application that requires local access and runs only on a decommissioned host is low priority regardless of score.

Within KEV, CVSS fails as a primary sort because every entry has already passed the exploitation evidence threshold. The question is not whether they are being exploited in the wild. They all are. The question is whether they affect assets you run, whether those assets are reachable from the internet, and whether a compromise would be catastrophic or merely disruptive.

For a detailed explanation of how CVSS, EPSS, and KEV work together, see the CVSS Score vs. Real-World Exploitability guide. For the quickest automated triage output, the Patch Priority Tool applies SSVC-based decision logic to score your inputs in under a minute per CVE.

Three variables determine where a KEV entry sits in your priority queue. Apply them in order, the first variable that produces a clear signal ends the triage for that entry.

Variable 1: Exploitation recency and campaign activity

When was this CVE added to KEV? Is it being used in an active campaign right now, or was it added years ago to document historical exploitation? A CVE added to KEV in the past 30 days during an active ransomware campaign targeting your sector is categorically higher priority than a CVE added in 2022 for a product version you no longer run.

Signals to check: Decryption Digest daily posts and CISA advisories for active campaign citations, EPSS score from first.org/epss (scores above 0.5 indicate high probability of near-term exploitation attempts), and whether the CVE appears in any current threat actor attribution relevant to your sector.

Variable 2: Asset exposure in your environment

Do you run the affected product, and is it reachable from the internet or from untrusted network segments? A KEV entry for software you do not run requires zero action. A KEV entry for an internet-facing application scores highest for exposure. A KEV entry for an internal application accessible only from managed endpoints scores lower.

Check your asset inventory against the affected CPE strings in the CVE record. Your vulnerability scanner should flag this automatically if configured to check KEV status. If not, cross-reference manually using the CVE's affected product list.

Variable 3: Business impact of the affected asset

If the affected asset were compromised, what is the worst-case business impact? Assets that store regulated data, process financial transactions, control OT or ICS systems, or serve as authentication infrastructure have higher business impact than development workstations or test environments.

This variable is why two organizations can look at the same KEV entry and reach different prioritization conclusions. A CVE affecting your production payment processing server is Patch Now. The same CVE affecting an identical server in your QA environment is This Sprint.

Apply the three variables to produce one of four triage outcomes for each KEV entry:

Patch Now (within 24 to 72 hours): CVE added to KEV in the past 30 days or currently cited in an active campaign targeting your sector, asset is internet-facing, and the affected asset has high business impact. This is incident-response-tier urgency. Pull the affected system for emergency patching or apply the CISA-recommended workaround immediately.

This Sprint (within 14 days): Active exploitation evidence, asset is in your environment, but asset is not internet-facing or business impact is moderate. Schedule for the current or next sprint with a named owner and completion date.

Scheduled (30 to 90 days): CVE is in KEV but exploitation is predominantly historical (added more than 6 months ago with no recent campaign citation), asset is in your environment, and exposure or business impact is limited. Add to your standard vulnerability management backlog.

Monitor (no immediate action): Asset is not in your environment, or the affected product version is already patched in your current deployment. Log that you reviewed the entry and the basis for deferral. Revisit if your asset inventory changes.

Document your triage decision for each entry. Auditors and incident responders will ask why a specific KEV entry was not patched in the event of a related breach. A logged triage decision with a rationale is significantly better than silence.

A high-activity period, Patch Tuesday with multiple KEV additions, a major zero-day campaign, or a large vendor security advisory, can produce more Patch Now and This Sprint entries than your team can process in two weeks. When that happens, apply a secondary sort within each tier.

Within Patch Now, sequence by: internet-facing first, then authentication systems, then data stores, then other systems. An internet-facing VPN concentrator gets patched before an internal LDAP server even if both are rated Patch Now.

If still over capacity after sequencing, escalate to your CISO with a written briefing showing the gap: how many Patch Now or This Sprint items exist, your team's current capacity in CVEs per sprint, and the specific systems that will remain unpatched. A CISO who understands the capacity gap can authorize temporary compensating controls, emergency contractor support, or targeted network isolation for the highest-risk systems. A CISO who is not informed cannot make those decisions.

The Patch Priority Tool automates this scoring using SSVC-inspired decision logic. Input the exploitation status, technical impact, exposure, and mission criticality for each CVE to get a priority tier in under a minute per entry without manual variable scoring.

The most effective KEV integration uses automation to surface new additions before your weekly triage rather than relying on manual catalog checks.

Set up a weekly KEV diff. The catalog is available as a machine-readable JSON file at cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json. A simple script that downloads this file weekly, compares it against last week's version, and posts the new additions to a Slack channel or sends an email takes under 30 minutes to build and eliminates the risk of missing a new entry.

Configure your vulnerability scanner to surface KEV status. Tenable Nessus, Qualys VMDR, and Rapid7 InsightVM all support CISA KEV status as a native filter as of 2025. Configure your scanner to flag KEV membership as a separate severity field so KEV entries surface at the top of your queue independent of CVSS score.

For environments without a commercial scanner, the free Greenbone Community Edition (formerly OpenVAS) supports KEV-based filtering. Export scan results and cross-reference against the KEV JSON feed using CVE IDs. A Python script that does this comparison runs in seconds against even large scan outputs.