Are you patching everything that scans red, or are you focusing on what attackers actually exploit? The difference determines whether your security budget protects your organization or just makes vendors richer.
Scope: What This Guide Covers
This guide explains how to integrate CISA's Known Exploited Vulnerabilities (KEV) Catalog into your vulnerability management program. It's designed for security engineers and vulnerability management teams who need to make daily triage decisions with limited resources. You'll learn how to operationalize the catalog beyond federal compliance, map it to your existing frameworks, and avoid common implementation mistakes.
If you're managing vulnerability remediation at any organization, not just federal agencies, this guide shows you how to use the KEV Catalog as a risk prioritization filter grounded in real-world threat intelligence rather than theoretical CVSS scores.
Key Concepts and Definitions
Known Exploited Vulnerabilities (KEV) Catalog: CISA's authoritative list of CVEs with confirmed evidence of active exploitation. Each entry includes the CVE ID, vendor/product, vulnerability name, date added, and required action with a due date.
Binding Operational Directive (BOD) 26-04: The federal directive titled "Prioritizing Security Updates Based on Risk" that requires Federal Civilian Executive Branch agencies to remediate KEV-listed vulnerabilities on publicly exposed assets that grant total control post-exploitation. It shifts federal vulnerability management from "patch everything fast" to "patch what matters faster."
High-Risk Vulnerabilities: Under BOD 26-04, these are KEV-listed CVEs on internet-facing systems where successful exploitation grants complete asset control. Your definition should mirror this: known exploitation, public exposure, and critical impact.
Risk-Based Vulnerability Management: A prioritization approach that weighs exploitability evidence, asset exposure, and business impact rather than relying solely on severity scores. The KEV Catalog provides the exploitability signal you can't get from CVSS alone.
Requirements Breakdown
For Federal Agencies (BOD 26-04 Mandates)
Federal Civilian Executive Branch agencies must:
- Monitor the KEV Catalog for additions.
- Identify affected publicly exposed assets.
- Prioritize remediation of KEV vulnerabilities that grant total control of the asset post-exploitation.
- Check for compromise indicators before patching (basic forensic validation).
- Defer action on lower-risk vulnerabilities when resource constraints exist.
For Non-Federal Organizations (Recommended Adoption)
CISA encourages all organizations to adopt similar practices. Here's how to translate federal requirements into practical controls:
Asset Inventory: You can't prioritize KEV remediation without knowing what's internet-facing. Map your external attack surface first, web applications, VPNs, remote access systems, cloud services with public endpoints.
Exposure Classification: Tag assets by exposure level (public internet, partner extranet, internal only). KEV vulnerabilities on internal-only systems still matter, but they're lower priority than the same CVE on your customer portal.
Control Impact Assessment: Does exploiting this vulnerability grant total control? Can an attacker execute code, elevate privileges to admin, or bypass authentication entirely? If yes, it's high-risk regardless of CVSS score.
Compromise Detection: Before you patch a KEV vulnerability, check logs for exploitation indicators. You're not just closing the door; you're checking if someone already walked through it.
Implementation Guidance
Integrating KEV Into Your Workflow
Step 1: Automate KEV Monitoring
CISA publishes the KEV Catalog in JSON and CSV formats. Pull it daily via API or RSS feed. Compare new additions against your asset inventory and vulnerability scan results. Don't rely on manual checks; you'll miss time-sensitive additions.
Step 2: Create a KEV-Specific SLA
Your standard patch SLA (30 days for critical, 90 for high) doesn't work for actively exploited vulnerabilities. Set a separate timeline:
- KEV vulnerabilities on public-facing systems: 7-14 days maximum.
- KEV vulnerabilities on internal systems: 30 days.
- Non-KEV critical vulnerabilities: existing SLA.
These timelines assume you've verified the vulnerability exists in your environment. False positives don't get the expedited track.
Step 3: Map KEV to Your Risk Register
Each KEV addition is threat intelligence. When CISA adds CVE-2023-4346 (KNX Protocol authentication bypass) or CVE-2026-46817 (Oracle E-Business Suite privilege escalation), ask: "Do we run this? Is it exposed? What's the blast radius?"
Document the answer in your risk register. If you don't have the vulnerable product, note it and move on. If you do, it's now a tracked risk item until remediated.
Step 4: Align With Existing Frameworks
The KEV Catalog complements your existing controls:
- NIST Cybersecurity Framework (CSF) 2.0: Maps to Identify (ID.RA), Protect (PR.IP), Detect (DE.CM), and Respond (RS.MI) functions.
- ISO/IEC 27001: Supports A.12.6.1 (Management of technical vulnerabilities) and A.16.1.4 (Assessment and decision on information security events).
- CIS Critical Security Controls: Directly supports CIS Control 7 (Continuous Vulnerability Management).
- NIST SP 800-53: Aligns with SI-2 (Flaw Remediation) and RA-5 (Vulnerability Monitoring and Scanning).
Don't create a parallel KEV program. Embed it into your existing vulnerability management control.
Operationalizing Threat Intelligence
The KEV Catalog tells you what attackers are exploiting right now. Use it to validate your threat model assumptions:
- Are you seeing exploitation attempts in your logs for KEV-listed CVEs?
- Do your IDS/IPS rules cover KEV vulnerabilities?
- Are your security awareness scenarios based on actual attack patterns (like the authentication bypasses CISA keeps adding)?
If your threat intelligence feed contradicts the KEV Catalog, trust the KEV Catalog. It's evidence-based, not vendor-driven.
Common Pitfalls
Pitfall 1: Treating KEV as the Only Priority
The KEV Catalog isn't exhaustive, it's a floor, not a ceiling. Zero-day vulnerabilities won't appear until there's public evidence of exploitation. You still need defense-in-depth.
Pitfall 2: Ignoring Internal KEV Vulnerabilities
BOD 26-04 focuses on publicly exposed assets, but attackers use lateral movement. A KEV vulnerability on your internal file server matters if an attacker gets past your perimeter.
Pitfall 3: Skipping Compromise Checks
Patching a KEV vulnerability without checking for prior exploitation is like locking your door after the burglar left. Review authentication logs, command history, and network traffic before you patch.
Pitfall 4: Waiting for Your Scanner to Detect It
Vulnerability scanners lag behind the KEV Catalog. CISA adds a CVE based on exploitation evidence; your scanner vendor adds a signature weeks later. Use the KEV feed to hunt proactively.
Pitfall 5: No Compensating Controls
You can't always patch immediately. If a KEV vulnerability affects a production system you can't take offline, implement compensating controls: restrict network access, enable additional logging, deploy virtual patching via WAF or IPS.
Quick Reference Table
| Action | Timeline | Applies To | Validation Step |
|---|---|---|---|
| Monitor KEV additions | Daily | All organizations | Automated feed integration |
| Assess exposure | Within 24 hours of KEV addition | Assets running vulnerable software | Asset inventory cross-reference |
| Check for compromise | Before patching | Systems with KEV vulnerabilities | Log review, IOC scanning |
| Remediate (public-facing, total control) | 7-14 days | Internet-exposed critical systems | Vulnerability rescan |
| Remediate (internal systems) | 30 days | Internal systems with KEV CVEs | Vulnerability rescan |
| Document exception | If remediation delayed | Systems requiring compensating controls | Risk acceptance with mitigation plan |
| Report to leadership | Monthly | KEV remediation metrics | Dashboard showing open KEV count by age |
Essential Resources
- KEV Catalog: CISA KEV Catalog
- KEV Nomination Form: Submit newly discovered exploited vulnerabilities
- BOD 26-04 Full Text: Review complete federal requirements
- KEV JSON Feed: Automate daily monitoring
The KEV Catalog gives you what vulnerability scanners can't: proof that attackers are actively using a vulnerability right now. Your job is to act on that intelligence before they use it against you.
