The CISA Known Exploited Vulnerabilities catalog is the most direct signal available to any vulnerability management program: a government-curated, continuously updated list of CVEs with confirmed active exploitation in the wild. It's free, machine-readable, and updated multiple times per week. And most security teams use it in the least effective way possible — they export it monthly, manually cross-reference it against their scanner output, and use the results to update a slide in their quarterly board report. That's not threat-informed patching. That's threat-informed documentation.
Genuinely integrating KEV into your patch prioritization means treating it as a real-time feed that automatically elevates any matching CVE in your environment to the top of your remediation queue — regardless of its CVSS score, regardless of which business unit owns the affected asset, and with a patch deadline measured in hours rather than the standard 30/60/90-day tiers.
What the KEV Actually Contains
The KEV catalog (available at cisa.gov/known-exploited-vulnerabilities-catalog) contains entries with the following fields for each CVE: CVE ID, vendor/project name, product name, vulnerability name (CISA's descriptive label), date added to the catalog, short description, action due date, and required action description. The date added is typically close to the date exploitation was confirmed, not the original CVE publication date — many entries appear months or years after the CVE was first published, which is worth noting.
The machine-readable JSON feed is available at cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json. It contains the same fields and is updated whenever new entries are added. You can poll it programmatically — a daily check is sufficient for most organizations, though a 4-hour polling interval is better for high-sensitivity environments.
Federal agencies operating under BOD 22-01 (Binding Operational Directive) are required to remediate KEV-listed CVEs within 2 weeks for known exploited vulnerabilities and within 6 months for older catalog entries. These timelines are tighter than typical enterprise patch SLAs, which is intentional — CISA designed them based on mean time to exploitation data showing that known-exploited CVEs are typically used in attacks within days to weeks of initial disclosure.
Why Most Teams Get the Integration Wrong
The most common implementation mistake is using KEV as a filter rather than a prioritization signal. A filter approach says: "Show me only KEV vulnerabilities in our environment" — and then works that subset in isolation from the broader vulnerability backlog. This creates two queues with an artificial boundary between them and misses the contextual relationship between KEV findings and surrounding vulnerabilities.
A better model treats KEV as a multiplier on top of your existing risk scores. Any CVE that appears in KEV receives an automatic score boost that places it above everything else in its risk tier, regardless of CVSS base score. A KEV-listed CVE with a CVSS 6.5 score outranks a non-KEV CVE with a CVSS 9.8 — because the KEV score is based on observed exploitation, not theoretical severity. This is the model PatchGuard uses: KEV-listed CVEs are automatically elevated to Critical Risk tier, triggering the tightest deployment SLA in your configured policy.
The second implementation mistake is treating KEV additions as a batch event. If you're checking the catalog weekly or monthly, you're responding to CVE exploitation on a weekly or monthly timeline — which is not competitive with threat actors who typically begin mass exploitation within 24 to 48 hours of a new KEV entry being published. The operational standard should be continuous monitoring with alert on delta: notify the security team immediately when any CVE in your scanner's open findings list appears in a new KEV update.
Building a KEV-Aware Patching Workflow
The minimal viable KEV integration has three components: a daily (or more frequent) pull of the CISA JSON feed, an automatic cross-reference against your open vulnerability inventory, and an alert pipeline that fires when a match is found. Most modern vulnerability management platforms support this natively — the configuration is a matter of enabling the integration and setting the alert threshold, not building custom pipelines.
For teams without a dedicated vulnerability management platform, the cross-reference can be done with a simple script that pulls the KEV JSON, extracts all CVE IDs, and queries your scanner's API for open findings matching those IDs. Qualys, Tenable, Rapid7, and Wiz all expose REST APIs for querying findings by CVE ID. The implementation is roughly 50 lines of Python and a cron job. The harder part is defining the remediation workflow once a match is found — who gets notified, what the SLA is, and how the ticket is tracked to closure.
PatchGuard's KEV integration goes further: rather than just alerting on matches, it automatically creates a high-priority patch action for each KEV-matched CVE in your environment, pre-populates the affected asset list from your inventory, and assigns the action to the on-call engineer via your configured notification channel (PagerDuty, Slack, or ServiceNow). The patch SLA clock starts the moment the KEV match is detected — not the moment someone reads the alert email.
KEV Limitations You Should Know
The catalog is authoritative but not comprehensive. CISA adds CVEs based on confirmed reports of active exploitation, which means there's inherently a lag between when exploitation starts and when it's documented enough for CISA to act on. Early-stage exploitation by targeted threat actors — nation-state APTs running campaigns against specific verticals — may not generate the public reporting that triggers a KEV entry for weeks or months. KEV should be your floor, not your ceiling.
Additionally, KEV scope is primarily US government agency infrastructure, with coverage expanding based on reporting from CISA's government partners, ISACs, and cybersecurity vendors. There's a selection bias toward vulnerabilities affecting commonly-deployed federal systems: Microsoft, Cisco, Fortinet, Apache, and VMware products appear frequently. Niche enterprise tools with smaller federal footprints may see delayed KEV coverage even when exploited broadly in the private sector.
Complementary commercial feeds worth adding on top of KEV: VulnCheck's NVD++ (adds exploit status, PoC availability, and Metasploit module status to every CVE), Greynoise's mass exploitation signals (detects CVEs being scanned or exploited at internet scale), and AlienVault OTX (community threat intelligence with tagged CVE indicators). None of these are free, but they cover the gaps that KEV's reporting lag creates.
Using KEV for Audit and Compliance Evidence
KEV has an underappreciated secondary use: generating compliance evidence that's difficult to argue with. When auditors ask how you prioritize vulnerability remediation, showing that your process automatically elevates CISA-confirmed exploited vulnerabilities above all others is a stronger answer than "we use CVSS scores" — because CVSS is a scoring methodology, while KEV is direct threat intelligence from the US federal government.
For SOC 2 CC7.1 (Timely Remediation), documenting your KEV SLA as part of your vulnerability management policy demonstrates a threat-informed remediation process. The same documentation is useful for NIST SP 800-53 SI-2 and for cyber insurance underwriters who increasingly ask about exploitation-aware patch prioritization in their questionnaires. Showing that you patched all KEV-listed CVEs within 72 hours during the audit period is a materially stronger control narrative than average CVSS remediation time by tier.
The Right Way to Think About KEV
KEV tells you which vulnerabilities the US government has enough evidence to formally declare as actively exploited. That's a high bar. A CVE appearing in KEV is not a theoretical risk — it's a CVE being used in real attacks, right now, against real targets. Any matching CVE in your open findings inventory deserves immediate attention, not a spot in the next monthly patch cycle. Automate the matching, shorten the SLA, and treat KEV additions as the closest thing to a real-time intrusion warning that your patch program can receive.