A KEV due date is the remediation deadline CISA attaches to a vulnerability in its Known Exploited Vulnerabilities catalog, and it binds federal civilian executive branch agencies, not private organizations. Under BOD 22-01 the default was two weeks for most entries and six months for CVEs assigned before 2021; BOD 26-04, issued June 10, 2026, revoked BOD 22-01 and replaced those fixed windows with timelines that depend on exposure, exploitation and impact. For everyone else, the useful lesson is the structure, not the numbers: a deadline should follow from documented risk inputs, carry its basis, have an owner and allow exceptions that expire.
What KEV due dates are and whom they bind
BOD 22-01, issued November 3, 2021, created the catalog and told agencies to “Remediate each vulnerability according to the timelines set forth in the CISA-managed vulnerability catalog.” The directive stated the standard timeframes directly: the catalog would carry “the requirement to remediate within 6 months for vulnerabilities with a Common Vulnerabilities and Exposures (CVE) ID assigned prior to 2021 and within two weeks for all other vulnerabilities.” It added that “These default timelines may be adjusted in the case of grave risk to the Federal Enterprise.”
The audience was narrow by design. CISA describes a binding operational directive as “a compulsory direction to federal, executive branch, departments and agencies for purposes of safeguarding federal information and information systems,” and excludes national security systems and certain defense and intelligence systems.
That regime has changed. BOD 26-04 states that it “supersedes and hereby revokes” BOD 19-02 and BOD 22-01. It applies to what it calls “Federal Civilian Executive Branch” agencies, and its timelines depend on four variables: whether the asset is publicly exposed, whether the vulnerability is in KEV, whether an adversary can automate exploitation, and whether exploitation yields partial or total control. The clock starts at whichever comes first: CISA adding the vulnerability to KEV, or the agency identifying it on an asset.
Why private organizations still use them as a reference
No private company is obligated by either directive. CISA’s catalog page still says that “Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework,” and BOD 22-01 itself noted that “CISA recommends organizations use the KEV Catalog in conjunction with a vulnerability scoring framework that evaluate exploitation status.”
KEV is useful because it is a public, dated record of confirmed exploitation, and a federal deadline gives auditors an external benchmark. The risk is copying the deadline without the reasoning behind it. BOD 26-04 is itself a move away from one window for every KEV entry: a KEV-listed vulnerability on an internal asset with partial impact is treated differently from the same entry on an internet-facing system. A private policy that hard-codes the retired two-week rule is already out of date.
Severity-based SLAs and their limits
The most common private policy maps CVSS severity bands to deadlines. It is easy to automate, and it inherits every weakness of severity as a ranking: a Critical on an isolated lab host gets the same clock as a Critical on a public login page, and a Medium that is actively exploited waits behind both. As Severity is not priority explains, a base score describes the vulnerability, not your exposure to it.
Severity-only SLAs also produce a predictable failure: teams meet the deadline on paper by accepting risk or closing findings without evidence, because the deadline was set without regard to what the fix actually involves.
A workable deadline policy
NIST SP 800-40 Rev. 4 frames deadlines as part of maintenance plans: “A maintenance plan defines the actions to be taken when a scenario occurs for a maintenance group, including the timeframes for beginning and ending each action, along with any other pertinent information.” CIS Controls v8.1, Safeguard 7.2 asks organizations to “Establish and maintain a risk-based remediation strategy documented in a remediation process, with monthly, or more frequent, reviews.”
Inputs. Four signals should determine a finding’s deadline tier: confirmed exploitation (KEV membership), an exploitation forecast for what is not yet confirmed, exposure (is the affected service reachable, and from where), and business impact of the asset. They map closely onto the variables BOD 26-04 uses.
Tiers as policy, not fixed numbers. Define a small number of tiers, each described by the conditions that put a finding there, and let each organization set the time values in its own policy document, approved by whoever owns operational risk. The day counts depend on patch cadence, change windows and staffing; the conditions should not.
Exceptions with expiry. Some deadlines will legitimately be missed: no patch exists, the fix requires an outage, the system is being retired. NIST says “Organizations should closely track and monitor all exceptions to maintenance plans,” and “All exceptions to maintenance plans should be reviewed regularly to determine if the maintenance plan can be implemented now.” An exception is a risk accepted decision with a reason, an approver and an expiry, and it should survive the next scan, as described in A rescan should not erase a risk decision. When the expiry passes, the finding needs a new decision, not silent reinstatement of an old deadline.
What to measure, and what not to
Measure whether the policy holds:
- On-time rate by tier: the share of findings resolved by their deadline. NIST’s notional metrics table reports the percentage of assets patched by the maintenance plans’ deadlines, broken out by asset importance.
- Overdue age: how long past their deadline open findings are.
- Exception count and expiry: how many findings are under an active exception, how many exceptions have expired without a decision, and how many have no expiry at all.
Do not lead with raw counts. NIST is direct: “Overly simplistic metrics, such as counting the number of vulnerabilities that the entire organization had and what percentage of them were patched, are not actionable.” A falling total can mean better remediation or a narrower scan.
How deadlines should appear next to the finding
On the finding itself, show four things together:
- Deadline: the date, and whether it is met, at risk or overdue.
- Basis: which tier and why, such as “KEV-listed, internet-facing,” with the date the triggering signal appeared.
- Owner: the team or person accountable, and how they were assigned.
- Exception: if one exists, its reason, approver and expiry.
When the basis changes, recalculate the deadline and record the change. When a fix is applied, the finding is resolved only once a rescan supports it.
In practice
- Check whether your policy or tooling still describes KEV deadlines as a fixed two-week window, and update it to reflect that BOD 22-01 was revoked.
- Write your tiers as conditions (exploitation, exposure, impact) and keep the time values in one approved, reviewable place.
- Pick ten overdue findings and confirm each shows its deadline basis and an owner who knows about it.
- List every active exception and flag any without an expiry or an approver.
Sectie’s Exposure & Vulnerability Management product shows each finding’s deadline, its basis and its owner, and keeps approved exceptions with their expiry next to it.
