/how do you remediate known exploited vulnerabilities before the deadline?
Known exploited vulnerabilities (KEVs) are CVEs with confirmed evidence of active exploitation, listed in sources like CISA’s KEV catalog and VulnCheck KEV. Under BOD 22-01, federal agencies must fix them by set due dates, usually within two to three weeks, and many private organizations now use those dates as a benchmark too. Deadlines are rarely missed because teams ignore KEVs. They’re missed because KEV matches are found late, findings are duplicated across tools, ownership is unclear, patches aren’t always possible, and fixes go unverified. To stay on schedule, match every finding against KEV feeds automatically and give KEVs their own SLA above CVSS severity bands. Use asset context and exploitability to sequence the work, and route fixes straight to the teams that own the affected assets. Keep a fallback such as compensating controls for anything you can’t patch in time, and verify every fix before closing it.
Most vulnerabilities are never exploited. Known exploited vulnerabilities are the exception: attackers are already using them. That makes them the clearest signal in vulnerability management, and also the one with the least room for delay.
Most security teams know KEVs matter. The harder part is getting them fixed on time, consistently, across every scanner, asset, and team involved. This post covers what known exploited vulnerabilities are, where KEV deadlines come from, why those deadlines get missed, and how to build a remediation process that meets them.
What Are Known Exploited Vulnerabilities?
Known exploited vulnerabilities (KEVs) are CVEs with confirmed evidence of active exploitation in the wild. They are not theoretical risks or high scores on paper. Threat actors have already used them in real attacks.
The best-known source is CISA’s Known Exploited Vulnerabilities Catalog. A vulnerability is added only when it meets three criteria:
- It has an assigned CVE ID.
- There is reliable evidence that it is being actively exploited.
- There is a clear remediation action, such as a vendor patch or update.
CISA’s catalog is not the only source. VulnCheck KEV tracks a broader set of exploited vulnerabilities and often lists them earlier, which gives teams more lead time. Many programs use both.
KEVs get special treatment because only a small fraction of published CVEs are ever exploited. A KEV match is about as strong a signal for vulnerability prioritization as you will get.
KEV Due Dates and BOD 22-01
CISA’s catalog was created under Binding Operational Directive (BOD) 22-01, issued in November 2021. The directive requires federal civilian agencies to remediate each cataloged vulnerability by a set due date. For newly added vulnerabilities, that window is usually two to three weeks.
BOD 22-01 is not mandatory for private companies. CISA nonetheless urges every organization to use the catalog to drive remediation, and many do. Over time, KEV due dates have become a de facto benchmark well beyond government:
- Internal SLAs for actively exploited vulnerabilities are often modeled on them.
- Auditors and cyber insurers increasingly ask how quickly KEVs are closed.
- Customers and partners use KEV handling as a quick measure of security maturity.
Even if your organization is not bound by the directive, a two-to-three-week window for known exploited vulnerabilities is a reasonable expectation.
Why KEV Deadlines Get Missed
Missed KEV deadlines rarely come from teams ignoring the catalog. They come from process gaps between identifying a KEV and getting it fixed.
KEV matches are found late. If KEV status is checked manually, or cross-referenced against scanner exports in spreadsheets, days can pass before anyone realizes a newly added KEV exists in the environment. With a two-week window, that delay matters.
The same CVE shows up everywhere. One KEV can appear in several scanners, across dozens or hundreds of assets, often recorded differently in each tool. Without a single deduplicated view, teams struggle to answer a basic question: how many instances do we actually have, and where?
Nobody clearly owns the fix. Security finds the issue, but infrastructure, cloud, or development teams have to fix it. When ownership is unclear, tickets bounce between teams while the deadline gets closer.
Patching isn’t always possible. The affected system may be legacy, business-critical, or impossible to take offline on short notice. Without a defined fallback, these KEVs stall.
Fixes aren’t verified. A ticket marked “done” doesn’t guarantee the vulnerability is gone. If no one confirms the fix, a KEV can stay exposed while showing as remediated.
Building a KEV Remediation Process
A dependable KEV process handles each of these gaps before a deadline is at risk.
Match findings against KEV feeds continuously. KEV status should be applied automatically to every finding as it is ingested, not checked on a schedule. That requires security data normalization first, so findings from different tools describe the same vulnerability the same way and can be matched reliably.
Give KEVs their own SLA. Treat known exploited vulnerabilities as a separate tier above CVSS severity bands, with a deadline aligned to (or tighter than) CISA’s due dates. A KEV rated “medium” by CVSS is still being exploited.
Use context to sequence the work. When several KEVs land at once, environmental context decides what goes first. Internet-facing assets, business-critical systems, and confirmed vulnerability exploitability on the specific asset should move to the front of the queue.
Route fixes to owners automatically. Every KEV instance should reach the team that owns the affected asset, with remediation guidance attached. The less time spent on handoffs, the more of the deadline is left for the fix itself.
Have a fallback for KEVs you can’t patch. When patching isn’t possible in time, apply compensating controls, configuration changes, or network isolation to reduce exposure. Document the decision so it holds up in an audit.
Verify and measure. Confirm each fix with a rescan before closing it. Track KEV SLA adherence and mean time to remediate KEVs alongside your other vulnerability management metrics, so you can see where the process slows down.
How Seemplicity Helps Teams Close KEVs Faster
Seemplicity brings findings from across your scanning tools into one place, normalizing and deduplicating them so every KEV instance is counted once and tied to the right asset. Each finding is enriched with CISA KEV, VulnCheck KEV, and EPSS data automatically, so a new KEV in your environment is flagged as soon as it appears.
Seemplicity’s AI Analysts then validate whether a KEV is actually exploitable on the specific asset, which helps teams sequence work with evidence. Fixes are routed to the right owners with context and tracked against SLAs through to verified closure. For KEVs that can’t be patched right away, Response Options give teams alternative mitigation paths that reduce risk while a permanent fix is scheduled.
Making KEV Deadlines the Easy Part
Known exploited vulnerabilities remove most of the guesswork from prioritization: if attackers are using it and you have it, it needs fixing. What determines whether you meet the deadline is execution. That means fast detection, a single deduplicated view, clear ownership, a fallback for unpatchable systems, and verification at the end.
When those pieces are automated, KEV remediation becomes routine work instead of a scramble each time CISA updates the catalog.
Stay updated on Seemplicity blog
Subscribe today to stay informed and get regular updates from Seemplicity.
