BOD 26-04: The End of Patch-Everything, and What It Actually Takes to Comply
On June 10, 2026, CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk. It revokes and replaces two directives that have shaped federal vulnerability management for years: BOD 19-02 (Vulnerability Remediation Requirements for Internet-Accessible Systems, April 2019) and BOD 22-01 (Reducing the Significant Risk of Known Exploited Vulnerabilities, November 2021).
If you have built compliance workflows, dashboards, or reporting around BOD 22-01, those artifacts now reference a revoked directive. That alone makes this worth an hour of your attention.
But the more interesting story is not the paperwork. It is that CISA has formally abandoned the flat-deadline model, and in doing so has handed every security team, federal or not, a defensible framework for deciding what to fix first.
What actually changed
BOD 22-01 was conceptually simple. If a CVE landed in the Known Exploited Vulnerabilities catalog, you patched it inside a fixed window: 14 days for CVEs assigned after 2021, six months for older ones. One signal, one clock.
BOD 26-04 replaces that with a four-variable risk model that produces a 16-tier remediation matrix. KEV status is no longer the sole determinant of urgency. It is one input among four.
There is a second, quieter change worth noting. By revoking BOD 19-02, CISA has removed the requirement for FCEB agencies to use CVSS for vulnerability prioritization. Seven years of "sort by CVSS 9.0 and above" is no longer federal policy. The directive instead aligns with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) methodology and with FIRST's CVSS SIG consumer implementation guidance.
The four variables
Every vulnerability instance gets evaluated against four binary questions:
- Is the asset publicly exposed? Reachable from outside the agency network via a routable IP address.
- Is the CVE in the KEV catalog? Confirmed real-world exploitation.
- Is it automatable by an adversary? Can an attacker script every step required to exploit it end to end.
- What is the technical impact? Total control of the affected system, or only partial.
CISA supplies the answers to questions two, three, and four for every CVE through its Vulnrichment program. That is a genuinely useful piece of engineering, because it means three quarters of the decision model arrives as enrichable data rather than analyst judgment.
Question one is yours. That is the whole game, and I will come back to it.
The five timeline tiers
Table 1 in Appendix A maps all sixteen combinations to one of five outcomes:
| Tier | Trigger |
|---|---|
| 3 days + forensic triage | KEV listed and yields total system control, regardless of exposure or automatability |
| 3 days | High-risk combinations such as publicly exposed, automatable, total control, even when the CVE is not yet in KEV |
| 14 days | Most KEV-listed vulnerabilities and several high-risk non-KEV combinations |
| 60 days | Lower-risk combinations, such as non-exposed assets with automatable but partial-control vulnerabilities |
| Fix on system upgrade | No risk criteria met. Deferred to the next scheduled upgrade cycle |
Three days is the most aggressive standing remediation timeline in the history of federal cybersecurity directives. And the forensic triage requirement in that top tier is a real shift in posture: CISA is acknowledging that when something is actively exploited and grants total control, patching alone does not answer the question of whether you were already breached.
The tiers are also dynamic. Pull a system off the public internet and its clock lengthens. CISA adds a CVE to KEV and every instance of it in your estate accelerates immediately.
Before anyone panics about the three-day number: in an initial analysis at one large civilian agency, CISA found roughly 1% of vulnerability instances landed in the three-day tier, while more than 60% qualified for deferral to the next upgrade cycle. The model is built to concentrate effort, not to multiply it.
Why now
Two forces converged.
The first is that traditional vulnerability management is measurably losing ground. The 2026 Verizon DBIR reported that only 26% of KEV-listed vulnerabilities were fully remediated in 2025, down from 38% the prior year, with median time to full resolution climbing to 43 days.
The second is AI. CISA states plainly that AI is accelerating both vulnerability discovery and weaponization, collapsing the gap between disclosure and working exploit. A 43-day median against an adversary operating on an hours-long timeline is not a gap, it is a chasm. "Patch everything eventually" stops being a conservative strategy and becomes an actively dangerous one.
The hard part is variable one
Everything above is policy. Here is the operational reality.
Variables two through four arrive from CISA as data. Variable one requires you to know, continuously and accurately, which of your assets are internet-facing. Not which ones were internet-facing at last quarter's scan. Which ones are internet-facing right now.
An agency that cannot maintain real-time exposure visibility cannot comply with a directive whose timelines shift the moment exposure changes. Periodic scanning plus a spreadsheet of "external" assets will not survive contact with this model.
This is where most programs will fail, and it is not a tooling purchase problem. It is a data correlation problem:
- Your scanner knows the vulnerability.
- Your asset inventory knows the system.
- Your firewall, load balancer, cloud provider, and external attack surface tooling collectively know the exposure.
- Your CMDB knows the owner and the change window.
None of them know all four. Something has to join them.
Operationalizing it in a SIEM
For teams already centralizing scanner output, the practical path is to compute the tier as a derived field at search time rather than trying to buy compliance as a product.
The rough shape, using Tenable data as the example source:
index=tenable sourcetype=tenable:vuln
| eval kev = if(in(cve, <kev_lookup>), 1, 0)
| lookup vulnrichment_ssvc cve OUTPUT automatable, technical_impact
| lookup asset_exposure dest_ip OUTPUT public_exposed
| eval tier = case(
kev==1 AND technical_impact=="total", "3d_forensic",
public_exposed==1 AND automatable=="yes"
AND technical_impact=="total", "3d",
kev==1, "14d",
automatable=="yes" AND technical_impact=="partial", "60d",
1==1, "upgrade_cycle")
| eval due_date = relative_time(first_seen, tier_offset)
Four things make this work in practice:
- KEV as a maintained lookup, refreshed on a schedule, not hardcoded.
- Vulnrichment SSVC data ingested as enrichment, so automatability and technical impact are joined rather than guessed.
- An exposure lookup that is itself a live artifact, fed from external attack surface data and network boundary configuration. This is the one you will spend real time on.
- Recomputation on every run, because the tiers are dynamic. A tier assigned last week is not authoritative today.
If you are running a vendor-provided app for this, watch your resource consumption. Compliance content packs tend to be written for breadth rather than for the shape of your specific index, and on a busy environment the scheduled searches can cost more than they return. Pulling the handful of searches you actually need down to the index and sourcetype level is frequently the better trade.
The reporting layer matters as much as the detection layer. BOD 26-04 makes prioritization a governance question. You need to be able to show why a given vulnerability was worked first, and demonstrate progress against CISA-defined clocks. That means your dashboard needs tier distribution, aging against due date, and tier-transition history, not just an open-findings count.
Milestones
- Immediately: update vulnerability management policies, including ongoing KEV remediation processes.
- Within 60 days (roughly August 2026): update remediation processes to the new tiered model. CISA also publishes machine-level asset tagging data requirements and a standardized data schema in this window.
- Within 180 days (roughly December 2026): meet the full remediation timelines in Table 1. FedRAMP has pointed to December 7, 2026 as the date agencies must begin evaluating and remediating on BOD 26-04 timelines.
If you are not a federal agency
BOD 26-04 binds FCEB agencies only. It does not bind you. But BOD 22-01 did not bind the private sector either, and the KEV catalog became the most widely adopted prioritization signal in the industry anyway. There is no reason to expect a different trajectory here.
If you sit in a federal supply chain, a regulated industry, or critical infrastructure, adopting the four-variable model before it becomes an expectation is straightforwardly a strategic advantage. And if you sit nowhere near any of that, the model is still better than what most organizations are doing, because it is defensible. "We fixed this first because it is exposed, exploited in the wild, automatable, and grants total control" is an argument that survives a board meeting. "It was a 9.8" is not.
Three things to do this week
- Audit against the four variables. Can you enumerate publicly exposed assets today, with confidence? Does your prioritization already consume KEV status? Can you source automatability and technical impact per CVE? Honest answers here tell you how much runway you have.
- Find and update your BOD 22-01 artifacts. Dashboards, saved searches, POA&M templates, SLA definitions, contract language. Anything that cites a revoked directive is now a finding waiting to happen.
- Assess forensic triage readiness. The top tier requires you to determine whether you were already compromised, inside three days, alongside remediation. That is a detection and response capability question, not a vulnerability management one. If those two functions do not currently talk to each other, this is the forcing event.
Need help?
If you need help surfacing these items — from exposure visibility and KEV enrichment to SIEM-based tier reporting — SecTower can help. Get in touch.