This guide shows how to use CISA's Known Exploited Vulnerabilities (KEV) catalog to prevent, detect, and recover from attacks on flaws already exploited in the wild. According to CISA, each catalog entry names the affected product, the required remediation action, and the federal due date in the current catalog page. Treat KEV membership as a binary prioritize-now signal, not just one input among severity scores. Due dates often fall days to weeks after listing, so waiting for a convenient maintenance window leaves a known-exploited opening exposed.
Table of Contents
- How do you turn KEV entries into patching action?
- How do you monitor for KEV exposure?
- How do you recover when a KEV flaw is exploited?
- Where do KEV requirements end?
How do you turn KEV entries into patching action?
Build patching as a repeatable cycle: identify, prioritize, acquire, install, and verify fixes under a documented enterprise strategy. That cycle comes from NIST, whose April 2022 guidance defines enterprise patch management in those terms in the final NIST publication. Align the cycle with continuous vulnerability management.
Maintain a written remediation process, run authenticated scans that can see installed software, rank flaws by exploitability, and fix them on risk-based timelines. In practice, that means KEV items jump the queue. A KEV-listed flaw on an internet-facing server, VPN appliance, email gateway, or endpoint agent gets emergency handling, while a non-exploited flaw with a higher severity score follows the normal schedule.
How do you monitor for KEV exposure?
Start with an accurate inventory of software and versions, then scan internet-accessible systems for missing fixes. Cross-reference scan findings against the free KEV JSON or CSV feed, and consider CISA's free scanning help described on the Cyber Hygiene services page.
Use a short routine your team can repeat weekly: Authenticated scanning matters because unauthenticated checks can miss installed products or patch levels. Track exceptions in writing so a deferred host does not disappear from the next review.
- update the software inventory after installs, upgrades, and removals
- scan authenticated hosts and externally exposed services
- match confirmed versions against current KEV entries
- assign owners and due dates tied to catalog dates
How do you recover when a KEV flaw is exploited?
Assume an exploited device may be fully compromised. Isolate affected systems quickly, preserve evidence for investigation, then rebuild from known-good media on a clean network rather than cleaning a running system in place. Recovery depends on backups made before the incident.
Keep encrypted backups offline, separate from the main network, and test restores regularly so the team knows the data works and how long restoration takes. Exercise an incident-response and communications plan before an event. Define who declares an incident, who can disconnect systems, how customers and staff are notified, and when operations return to normal.
Where do KEV requirements end?
The mandatory due dates in Binding Operational Directive 22-01 apply to federal civilian executive agencies. Private companies, state and local governments, and other groups are not legally bound by that directive, but the exploitation evidence still applies to their identical products.
When patching is infeasible, use documented compensating controls such as network segmentation, restricting access, disabling the vulnerable product or feature, or blocking known attack paths. Those steps reduce exposure but do not eliminate exploitation risk, so keep pursuing the catalog-directed fix and revisit the exception on every feed update.
You Might Also Like
- FBI Ransomware Prevention Guide: Controls, Monitoring, and Recovery
- Cybersecurity — Power Grid Cyberattack Update 2026: Disclosure, Response, and Open Questions
- Cybersecurity — City Government Hack Response Checklist: Passwords, Accounts, and Credit