CISA KEV Is a Prioritization Multiplier — Here's How to Use It Properly

The TL;DR

CISA’s Known Exploited Vulnerabilities (KEV) catalog lists CVEs where exploitation has been confirmed in the wild. Teams love it because it’s binary — your asset is affected, it’s on the list, fix it. But KEV has blind spots: it only lists the highest-profile exploits, updates quarterly, and tells you nothing about when the next exploit will hit a CVE not yet on the list. Treating KEV as a checklist is cheaper than treating it as a priority multiplier — until the thing CISA hasn’t catalogued yet bites you.

The Model Most Teams Use (And Why It’s Wrong)

The common workflow looks like this:

1. Scan finds CVEs affecting our assets
2. Check each against CISA KEV catalog
3. If on KEV → fix within 30 days (or sooner)
4. If not on KEV → triage normally

This works fine until you realize that:

• KEV has ~400 entries (as of mid-2026) out of tens of thousands of CVEs published each year
• KEV is updated quarterly — a CVE can be actively exploited for months before CISA adds it
• KEV only lists one CVE per vulnerability pattern — if a vendor ships two affected versions, CISA might only catalog the more impactful one
• KEV says nothing about where the exploitation is happening (internet-facing vs. internal, which industry)

The binary model (“on KEV = critical, off KEV = whatever”) throws away real signal.

KEV as a Multiplier, Not a Switch

A better model treats KEV as a weight in a scoring system, not a pass/fail gate. Here’s the pattern:

# Pseudocode — KEV boosts the priority score but doesn't dominate it

priority_score = (
    0.25 * cvss_normalized +
    0.20 * epss_score +
    0.20 * kev_score +          # 100 if in KEV, 0 otherwise
    0.20 * asset_criticality +
    0.15 * exploit_maturity +
    0.10 * industry_relevance   # added signal
)

# If in KEV, the score jumps — but an EPSS-0.97 CVE with a
# public PoC for an unpatched internet-facing server can still
# outrank a KEV entry affecting an internal, low-criticality asset.

The KEV term is a step function (100 or 0) because CISA’s catalog is binary. But the composite score is what drives prioritization, and KEV shifts that score by roughly 20 points on a 0-100 scale — significant, but not dominant.

What KEV Tells You (and What It Doesn’t)

The “due date” column is the most actionable data point: CISA calculates it based on when the CVE was added to the catalog, not when the CVE was published. A CVE added on October 1 with a 30-day due date means you have until ~October 31, regardless of whether the CVE was published six months ago.

The Blind Spot: What About CVEs That Will Be on KEV?

The biggest risk isn’t the CVEs CISA has already catalogued — it’s the ones that will be there next quarter. You can approximate this signal using EPSS:

• EPSS scores above 0.90 (90th percentile) with a public PoC or Metasploit module are your “next KEV” candidates
• CVEs with EPSS > 0.50 that affect internet-facing assets are worth patching before KEV adds them
• The lag between first exploitation and KEV inclusion averages ~30-60 days for high-profile targets (government, healthcare, critical infrastructure)

This means: a high-EPSS CVE on an exposed asset is often more urgent than a low-EPSS CVE that’s on KEV.

Example:

CVE-2024-XXXX has a higher CVSS, higher EPSS, public exploitability, and is internet-facing — yet it outranks CVE-2024-YYYY because the latter is on KEV but affects a low-criticality internal asset.

The KEV+EPSS Workflow

Here’s the workflow I use for weekly vulnerability triage:

1. Pull the KEV catalog (CISA updates it quarterly; refresh from CISA’s JSON feed)
2. Match KEV entries against asset inventory — filter to your CPEs
3. Pull EPSS scores for all affected CVEs (bulk query from first.org)
4. Calculate composite scores using the weighted model above
5. Flag KEV entries with low EPSS — these might be low-profile exploits or niche targets. Not necessarily low priority, but worth the context.
6. Flag high-EPSS non-KEV entries — these are your “next KEV” candidates
7. Prioritize by composite score, not by KEV status alone

Automation Script

#!/usr/bin/env python3
"""KEV+EPSS prioritization for weekly triage."""
import json
import urllib.request
from datetime import datetime, date

CISA_KEV_URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
EPSS_BASE = "https://api.first.org/data/v1/epss"

def fetch_kev():
    """Fetch and parse CISA KEV catalog."""
    with urllib.request.urlopen(CISA_KEV_URL) as resp:
        catalog = json.loads(resp.read())
    return {v["cveID"]: v for v in catalog.get("vulnerabilities", [])}

def fetch_epss(cve_ids):
    """Bulk-fetch EPSS scores for CVE IDs."""
    cve_param = ",".join(cve_ids)
    url = f"{EPSS_BASE}?cve={cve_param}"
    with urllib.request.urlopen(url) as resp:
        data = json.loads(resp.read())
    return {d["cve"]: {"epss": d["epss"], "percentile": d["percentile"]}
            for d in data.get("data", [])}

# Usage:
# kev = fetch_kev()
# affected_cves = ["CVE-2024-1234", "CVE-2024-5678"]
# epss = fetch_epss(affected_cves)
# for cve in affected_cves:
#     in_kev = cve in kev
#     epss_data = epss.get(cve, {})
#     print(f"{cve}: KEV={in_kev}, EPSS={epss_data.get('epss', 'N/A')}")

Run this weekly. Output is a prioritized list. Feed it into your ticketing system.

KEV and Industry Context

CISA’s KEV catalog includes a “requiredAction” and “notes” field that often hints at the exploitation context:

• “Ransomware” — the CVE is being exploited by ransomware operators. Your backup infrastructure, RDP gateways, and Exchange servers are the likely targets.
• “0-day” — CISA acquired the CVE via a vulnerability disclosure program or zero-day marketplace. Expect rapid adoption by multiple threat actors.
• “Unpatchable workaround available” — a configuration change can mitigate the vulnerability without a code patch.

The notes field is often brief, but it’s free intelligence. Read it.

The Quarterly Refresh Pattern

CISA updates the KEV catalog quarterly. The cadence matters:

The quarterly KEV refresh is a review trigger, not a scanning trigger. Your weekly workflow should pull the latest EPSS scores regardless of KEV status.

When KEV Dominates

There are scenarios where KEV should be the primary signal:

1. CISA KEV + CISA KEV due date < 7 days — these are expiring fast. Fix or confirm mitigation.
2. CISA KEV + ransomware note + internet-facing asset — ransomware operators iterate quickly.
3. CISA KEV + no patch available — the workaround is your only option. Verify it’s applied.
4. CISA KEV + high-profile industry (your sector) — if a bank is being targeted and your asset is a core banking component, prioritize even if EPSS is modest.

In these cases, KEV becomes the tiebreaker that pushes a medium-priority CVE into the P1 bucket.

The Takeaway

KEV is not a vulnerability management strategy. It’s a signal booster for your existing triage workflow. Treat it as:

• A binary weight (100 or 0) in a composite score
• A due date that creates urgency, not a deadline
• A quality indicator — if CISA added it, the exploit is proven, not theoretical
• A quarterly review trigger, not a weekly scanning trigger

And remember: the CVE that kills you next quarter probably isn’t on KEV yet. EPSS + public exploitability + asset context gets you there first.

Further Reading

• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• EPSS (Exploit Prediction Scoring System): https://www.first.org/epss
• NVD API: https://services.nvd.nist.gov/rest/json/cves/2.0
• CVE Details: https://www.cvedetails.com/