CISA's Known Exploited Vulnerabilities (KEV) Catalog has evolved from a federal compliance tool to a practical prioritization resource for any organization managing vulnerability risk. With the addition of CVE-2025-62593 and the enforcement of Binding Operational Directive (BOD) 26-04, the catalog now provides a direct link between threat intelligence and remediation action. This checklist helps you integrate KEV into your existing vulnerability management program, whether you're subject to BOD 26-04 or want to adopt its risk-based approach.
What This Checklist Covers
This checklist guides you through integrating CISA's KEV Catalog into your vulnerability management workflow. You'll establish monitoring processes, define remediation timelines, and align your patch management with active exploitation intelligence. Each item includes the specific output that demonstrates completion.
Prerequisites
Before starting this checklist, ensure you have:
- Access to your vulnerability scanning platform with API or feed integration capabilities
- Documented asset inventory distinguishing internet-facing from internal systems
- Current patch management process with defined SLAs and escalation paths
- Authority to modify remediation timelines or a clear path to the decision-maker who does
Checklist Items
1. Subscribe to the KEV Catalog Feed
Configure automated ingestion of CISA's KEV Catalog JSON feed into your vulnerability management platform or SIEM.
Requirement reference: BOD 26-04 requires agencies to check KEV status for all newly discovered vulnerabilities on publicly exposed assets.
What good looks like: Your vulnerability dashboard automatically flags any CVE that appears in the KEV Catalog within four hours of CISA's publication. You're not manually checking the CISA website.
2. Define "Publicly Exposed Assets" in Your Environment
Document which systems grant external network access and classify them separately in your asset management database.
Requirement reference: BOD 26-04 applies stricter timelines to vulnerabilities on assets "accessible from the public internet."
What good looks like: You can run a query that returns all assets meeting your "publicly exposed" definition. Your criteria address edge cases like VPN endpoints, cloud storage buckets, and third-party SaaS integrations.
3. Establish KEV-Specific Remediation Timelines
Create remediation SLAs that differentiate KEV vulnerabilities from standard CVEs based on asset exposure and exploitability.
Requirement reference: BOD 26-04 requires remediation of KEV vulnerabilities on publicly exposed assets that grant total control within seven days.
What good looks like: Your patch management policy includes a KEV remediation matrix. For example: KEV + publicly exposed + grants total control = 7 days; KEV + internal asset = 14 days; non-KEV critical = 30 days. Your team doesn't debate timelines during incident response.
4. Map "Total Control" to Your Asset Classifications
Define what "total control of the asset post-exploitation" means for each asset type in your environment.
Requirement reference: BOD 26-04 prioritizes vulnerabilities that enable full system compromise.
What good looks like: You've documented that root/SYSTEM access, kernel-level code execution, and authentication bypass on privileged accounts all meet the "total control" threshold. Your analysts can classify a vulnerability's impact without escalating to management.
5. Integrate KEV Status into Vulnerability Scoring
Modify your vulnerability prioritization model to weight KEV presence alongside CVSS scores and asset criticality.
Requirement reference: BOD 26-04 establishes risk-based prioritization that supersedes CVSS-only approaches.
What good looks like: A CVSS 7.5 vulnerability in the KEV Catalog outranks a CVSS 9.2 theoretical vulnerability in your queue. Your scoring algorithm reflects active exploitation as the primary risk factor.
6. Configure Automated KEV Alerts
Set up notifications when a KEV vulnerability appears in your scan results, especially on publicly exposed assets.
What good looks like: Within one business day of CISA adding CVE-2025-62593 to the KEV Catalog, your security team received an alert listing every affected system in your environment. The alert included asset owners, remediation deadlines, and mitigation guidance.
7. Document Your KEV Check Process
Create a procedure for determining whether a system was compromised before you applied the patch.
Requirement reference: BOD 26-04 requires agencies to check for pre-patch compromise indicators on KEV-vulnerable systems.
What good looks like: Your runbook specifies: review authentication logs for the vulnerability's disclosure date through patch application; check for unexpected processes, scheduled tasks, or persistence mechanisms; document findings in your ticketing system. You're not reinventing this process for each KEV.
8. Establish a KEV Nomination Workflow
Define who can submit vulnerabilities to CISA's KEV Nomination Form and under what conditions.
What good looks like: Your threat intelligence team has a documented process: if you observe exploitation attempts in your environment for a CVE not yet in the catalog, you compile evidence and submit through CISA's form. You've assigned this responsibility to a specific role.
9. Align Vendor Patch Cycles with KEV Timelines
Communicate KEV remediation requirements to vendors managing systems on your behalf.
What good looks like: Your vendor contracts or SLAs reference KEV remediation timelines. When a managed service provider patches a KEV vulnerability, they provide evidence of completion and pre-patch compromise checks.
10. Create KEV Metrics for Leadership Reporting
Track KEV remediation performance separately from general vulnerability metrics.
What good looks like: Your monthly security report includes: total KEV vulnerabilities identified, percentage remediated within SLA, mean time to remediate KEV vs. non-KEV critical vulnerabilities. Leadership sees whether you're meeting the seven-day target.
11. Test Your KEV Response on Internal Assets
Run a tabletop exercise simulating a KEV addition that affects critical internal systems.
What good looks like: Your team successfully identified all affected assets, determined whether they grant total control post-exploitation, coordinated emergency patching, and checked for compromise indicators within your documented timeline. You identified process gaps before a real incident.
12. Document Exceptions and Compensating Controls
Establish a formal process for cases where you can't patch a KEV vulnerability within the required timeline.
What good looks like: You have a template that documents: why the patch can't be applied (e.g., vendor hasn't released a fix), what compensating controls you've implemented (e.g., network segmentation, WAF rules), who approved the exception, and when you'll reassess. Your auditor can trace every KEV deviation.
Common Mistakes
Treating KEV as federal-only guidance. The catalog represents CISA's assessment of actively exploited vulnerabilities. If you're not using it, you're ignoring the best public source of exploitation intelligence.
Applying the same timeline to all KEV vulnerabilities. BOD 26-04 differentiates based on asset exposure and exploitability. A KEV vulnerability on an internal development server doesn't carry the same urgency as one on your customer-facing web application.
Skipping the compromise check. If you patch a KEV vulnerability without checking for prior exploitation, you've closed the door but left the intruder inside. BOD 26-04 requires this check because attackers often exploit vulnerabilities before patches are widely deployed.
Relying solely on CVSS scores. A CVSS 10.0 vulnerability that no one is exploiting poses less immediate risk than a CVSS 7.0 in the KEV Catalog. Your prioritization model should reflect this reality.
Next Steps
Start with items 1, 2, and 5. Get the KEV feed integrated, define your publicly exposed assets, and adjust your scoring model. These three changes will shift your program from reactive patching to intelligence-driven remediation.
Then tackle the remediation timeline (item 3) and alerting (item 6). You need clear SLAs and automated notifications before the next KEV addition catches you off guard.
The remaining items build out your documentation, vendor management, and governance. They're essential for audit readiness and long-term program maturity, but they won't stop an active exploit next week. Prioritize accordingly.
