CISA BOD 26-04: risk-based patch deadlines, explained

A Binding Operational Directive is a compulsory instruction from CISA to US federal executive branch agencies, under 44 U.S.C. § 3554. BOD 26-04, "Prioritizing Security Updates Based on Risk", was issued on June 10, 2026. It supersedes and revokes two earlier directives:

• BOD 22-01 (November 3, 2021) created the Known Exploited Vulnerabilities (KEV) catalog and gave agencies two weeks to remediate any KEV-listed CVE assigned from 2021 on, and six months for older ones.
• BOD 19-02 (April 29, 2019) set 15 days for critical and 30 days for high-severity vulnerabilities on internet-facing systems, using CVSS.

The idea behind the new directive is that not every vulnerability, and not every system, deserves the same urgency. CISA also notes that AI may shorten the time between a patch release and exploitation, which is why the shortest deadline is now three days instead of two weeks.

BOD 26-04 decides urgency from four values, each of them yes/no. Two of them, Automatable and Technical Impact, come from CISA's Vulnrichment program, which publishes SSVC decision points into the CVE record.

• Asset exposure. An asset is publicly exposed if unauthenticated or untrusted entities can reach it over a public network, wherever it is physically or logically located. If any method, such as CDM or CISA's Cyber Hygiene scanning, finds it exposed, the value is yes.
• KEV status. Whether the CVE ID is in the KEV catalog.
• Exploit automation. Whether an adversary can automate every step of the exploit. CISA's heuristic: if a public proof of concept achieves remote code execution and runs reliably against a vulnerable system, the answer is yes.
• Technical impact. Total if the attacker gains full control of the software's behavior, for example by installing and running arbitrary software, or by reliably revealing login credentials (CISA cites Heartbleed and Citrixbleed). Partial covers limited control or information exposure; denial of service is partial.

The defaults matter as much as the definitions. When an agency has no exposure data, CISA's Implementation Guidance treats an asset as public if it talks on a publicly routable IP, if its asset type is "network", or, for KEV-listed CVEs, if the affected software is generally public-facing; otherwise as internal. When a CVE outside KEV has no Vulnrichment data yet, CISA treats it as not automatable but with total impact.

The four signals give 16 possible combinations, which Table 1 of the directive maps to five outcomes. All deadlines are calendar days, and they are maximums: agencies may patch faster.

• 3 days and forensic triage. The top tier: KEV-listed vulnerabilities that give total control (in the feed, CISA's exposure assessment also counts; see the next section). The asset is remediated or mitigated within three days and examined for signs of compromise that happened before the patch.
• 3 days. High-risk combinations without the triage requirement, for example a publicly exposed asset with an automatable, total-control flaw that is not in KEV yet.
• 14 days. The band for most other KEV-listed vulnerabilities and several high-risk non-KEV combinations.
• 60 days. Lower-risk combinations, such as an asset that is not exposed with an automatable flaw that only gives partial control.
• Fix on system upgrade. No risk criteria met: remediate the next time the asset gets a scheduled major upgrade or rebuild. CISA's guidance says agencies "do not need to prioritize these vulnerabilities".

Table 1 is published only as an image on the directive page, and CISA will reassess it once per fiscal year. For a KEV entry you do not need to derive the tier: CISA calculates it and publishes it in the catalog.

Every entry in the KEV JSON feed now carries a dueDate computed under BOD 26-04 and a forensicTriage field. We counted the 137 entries CISA added between June 10 and October 21, 2026 (catalog version 2026.10.21):

• 89 (65%) had a 3-day due date with forensic triage.
• 22 (16%) had a 3-day due date without triage.
• 26 (19%) had a 14-day due date.
• None had 60 days or "next upgrade".

So in practice the 3-day deadline is the norm for a new KEV listing, not the exception. Cross-checking the same entries against CISA's Vulnrichment values shows two more things. Forensic triage does not depend on automation: 31 of the 89 triage entries are rated not automatable. And total control alone does not trigger it: 27 KEV entries rated total carry no triage flag, which points to CISA's exposure assessment of the affected software also counting. The safe rule is to read both fields for each CVE rather than infer them. Our CISA KEV tracker shows them for every addition of the last 90 days.

The clock starts at the earlier of two events: CISA adds the CVE to the KEV catalog, or the agency identifies the vulnerability on an asset and records it in the CDM Agency and Federal Dashboards. A team that finds a vulnerable asset on its own, before CISA lists the CVE, is already on the clock.

The timelines are dynamic in both directions:

• Removing an asset from the internet changes its exposure value and can move it to a longer deadline.
• A KEV listing of a CVE already being tracked shortens the deadline.

CISA's guidance says the only known mitigation for a KEV entry is the required action listed in the catalog. If that cannot be done in time, the asset comes off the network: decommissioning, removing the vulnerable product, segmentation, a software-defined perimeter or a proxy. CISA does not grant waivers or exceptions; agencies with special cases contact [email protected] for mitigation options.

BOD 26-04 requires "an adequate forensic triage analysis" for the top tier: a patch closes the door but does not evict an attacker who came in before it. CISA's Implementation Guidance gives six steps, with target times from the KEV addition that it presents as recommended practice, not requirements:

1. 1Scoping, first 2 hours. Activate the response team, scope the systems and services, and set up an out-of-band channel that does not depend on possibly compromised infrastructure.
2. 2Preserve and collect evidence, 2 to 24 hours. Volatile data first (memory, caches, registries, network state), then less volatile data, without altering the system first. Keep an evidence log: item, system, time, collector.
3. 3Critical patching and stabilization, 2 to 24 hours. Patch once evidence is collected, then stabilize the business systems the patch affects.
4. 4Contain and control, 6 to 24 hours. Isolate impacted and suspected systems without tipping off the threat actor, and document every action.
5. 5Triage analysis, 24 to 48 hours. Look for unauthorized access, lateral movement, persistence and data staging or exfiltration; verify indicators of compromise and search for them elsewhere.
6. 6Escalation decision, 48 to 72 hours. Write a triage report (timeline, actions, findings, containment, next steps). No evidence of compromise: report, raise monitoring, complete remediation. Compromise confirmed: report it to CISA and move to full incident response. Suspected: keep triaging and coordinate with CISA.

When CISA has indicators of compromise or specific forensic guidance for a CVE, it adds them to the KEV entry.

The directive's required actions come in three phases, counted from June 10, 2026:

• Immediately. Update vulnerability management policies, monitor KEV and remediate to its due dates, automate KEV status reporting through the CDM Dashboard (or report manually every two weeks), and keep CISA's Cyber Hygiene scanning unblocked.
• Within 60 days (about August 9, 2026). Update processes to cover vulnerabilities in the whole CVE database, not only KEV.
• Within 180 days (about December 7, 2026). Remediate within the Table 1 timelines; tag every externally reachable asset by organization, environment, exposure and asset type; include private RFC 1918 and RFC 4193 addresses in the CDM Dashboard. Agencies not fully automated through CDM report the tags every seven days.

Scope: the directive covers agency assets in any federal information system, including systems run by another entity on an agency's behalf. It does not bind contractors unless their contract says so, and it excludes national security systems and certain Department of War and Intelligence Community systems. For cloud services, agencies work through the FedRAMP PMO, which will require matching rules from providers by December 7, 2026; for other providers, directly with the cloud service provider.

A private company, a European bank or a hospital is not bound by BOD 26-04. It still matters to them for three practical reasons:

• It replaced the number everyone copied. For five years "14 days for KEV" was the reasonable-time benchmark in patch policies, insurance questionnaires and audit findings, although only federal agencies had to meet it. That figure no longer exists; the closest government-issued benchmark is now 3 days for most new KEV entries.
• Contracts and cloud services pass it down. Federal contracts can impose it, and FedRAMP is aligning its own rules for cloud providers.
• Regulators ask for a risk-based process. NIS2 and DORA do not set patch deadlines in days, but they expect vulnerability handling based on risk. A policy that cites the four BOD 26-04 signals, and records them per vulnerability, is easy to defend.

You can use the model without CDM dashboards. A workable version for a private-sector security team:

• Use the KEV due date as your upper bound. Subscribe to the KEV feed and treat its dueDate and forensicTriage fields as the maximum for any asset you run that is affected.
• Score non-KEV CVEs with the same four values. Automatable and Technical Impact are free in the CVE record, in the CISA ADP container from Vulnrichment. Exposure is the one value only you can establish.
• Make exposure evidence, not a guess. Keep an asset inventory that records which systems untrusted users can reach, and update it when a firewall rule or a cloud setting changes. CISA's own default, when in doubt, leans toward exposed.
• Prepare the 3-day lane in advance. Pre-approved emergency changes, rollback plans and a triage runbook that follows the six steps above. Three days is not enough to negotiate a change window.
• Record why each deadline was set. The four values, the source of each, the resulting deadline and the closure check. That record is what an auditor, an insurer or a supervisor will ask for.

The KEV emergency patch window playbook walks through the patch, mitigate or isolate decision once the deadline is known.

Of the four signals, KEV status and the Vulnrichment values come from CISA. Exposure and real exploitability are facts about your own network, and they are the ones teams usually guess under deadline.

Zero Hunt is an autonomous AI red team that runs on an on-premise appliance with private AI. It syncs the CISA KEV feed, including CISA's due dates, and FIRST's EPSS scores, then tests your networks and infrastructure in black-box or gray-box mode: whether a vulnerable service can be reached from where an attacker would stand, and whether the exploit actually works against your configuration. Exploitation steps wait for human approval at the autonomy level you set, and every finding is kept as an Ed25519-signed, hash-chained evidence record you can hand to an auditor. It does not set the BOD 26-04 tier for you; it gives you evidence for the exposure value and tells you which 3-day entries are real in your environment. That continuous loop is what CTEM describes.