Skip to main content
Change Risk Intel

CISA BOD 26-04: Risk-Based Patch Deadlines for CABs

The Change Risk Intel Desk · 11 min read

Why this matters right now

For four years, federal patch planning ran on one number: the 14-day clock that BOD 22-01 attached to every entry in the Known Exploited Vulnerabilities catalog. Change advisory boards built their emergency-change paths around it. On June 10, 2026, CISA replaced that model. Binding Operational Directive 26-04 — “Prioritizing Security Updates Based on Risk” — supersedes and revokes both BOD 22-01 and the older internet-facing directive BOD 19-02, and sorts each vulnerability into one of four remediation tiers.

This is a governance change disguised as a patch policy. A single flat deadline is easy for a CAB to schedule against. A four-variable model that can move the same CVE from a 60-day window to a 3-day emergency the moment CISA adds it to the KEV catalog is not. Federal agencies are directly bound, but the ripple reaches every contractor, SaaS vendor, and managed-service provider that processes federal data — and, historically, whatever CISA mandates becomes the reference model private-sector auditors point to next.

The four variables that set the clock

BOD 26-04 determines urgency from four yes/no questions, quoted directly from the directive:

  • Asset Exposure: “Is the vulnerable asset publicly exposed?” CISA defines publicly exposed as any agency-owned or agency-managed IT resource “accessible to unauthenticated or untrusted entities via public networks, such as the internet, regardless of its physical or logical location.”
  • KEV Status: “Is the vulnerability, as identified by a common vulnerabilities and exposures identifier (CVE ID), on CISA’s Known Exploited Vulnerabilities Catalog?”
  • Exploit Automation: “Is an adversary able to automate all the steps necessary to exploit the vulnerability?”
  • Technical Impact: “Does an adversary gain partial control or total control of the vulnerable asset after exploitation of the vulnerability?”

Crucially, agencies only answer one of those four themselves. Per the directive, CISA publishes the answers to KEV Status, Exploit Automation, and Technical Impact for every CVE through its Vulnrichment program, leaving agencies to determine only Asset Exposure. That is a deliberate design choice: it standardizes the risk scoring so two agencies looking at the same CVE reach the same tier. It also means your remediation deadline is now partly set by a data feed you do not control, and it can change after a change ticket is already approved.

The four tiers, and where the mass actually lands

Table 1 of the directive spells out all 16 combinations of the four variables and maps each to a timeline. The tiers, in calendar days:

  • 3 days + forensic triage — the vulnerability is in the KEV and grants total control (whether or not exploitation is automatable, if publicly exposed; automatable if not exposed). Remediate and prove you were not already breached.
  • 3 days — publicly exposed, automatable, partial or total control, but the KEV/impact mix falls just short of triage.
  • 14 days — the large middle band: KEV entries with partial control, or exposed non-KEV flaws with meaningful impact.
  • 60 days — non-exposed automatable flaws and exposed non-KEV partial-control flaws.
  • Fix on system upgrade — non-exposed, non-KEV, non-automatable flaws that “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild.”

We pulled apart all 16 rows of Table 1 to see how the directive’s own logic distributes across those tiers.

Bar chart of BOD 26-04 Table 1 showing how its 16 condition rows split across remediation tiers: three rows require 3-day plus forensic triage, two rows 3-day, six rows 14-day, three rows 60-day, and two rows fix-on-upgrade.

Read carefully: these are condition combinations, not real-world vulnerability counts. But the shape is instructive. Only five of the 16 rows (31%) demand action inside three days, and three of those require the added forensic-triage step. The single largest bucket is the 14-day tier. In practice, most live vulnerabilities on internal, non-exposed systems fall into the 60-day or fix-on-upgrade tiers — a public analysis of one large civilian agency estimated only around 1% of its vulnerabilities landed in the 3-day tier while roughly 60% could be deferred to the next scheduled upgrade, per reporting on the directive’s rollout. For a CAB, that is the real headline: the directive is loud about three-day emergencies but quietly gives you more room on the long tail than the old flat 14-day rule did.

The clock is calendar days, and it can start without you

Two operational details will break naive CAB scheduling if you miss them.

First, every timeline in Table 1 is measured in calendar days, not business days. As IANS Research notes, “the days for remediation are calendar days; they do not take weekends or holidays into account in the timeline,” per its analysis of the new requirements. A three-day KEV item that surfaces on a Friday afternoon is due Monday. Your emergency-change path has to run over a weekend without a Tuesday CAB quorum.

Second, the clock does not wait for your discovery process. The directive states the timeline begins when “CISA adds the vulnerability to the KEV Catalog” or when the agency enumerates it on an asset and updates its CDM dashboard — “whichever event occurs first.” A CVE you have not yet noticed can already be past day one because CISA added it that morning. That is why the exposure-tagging requirement matters: BOD 26-04 also directs agencies to continuously identify and tag every publicly reachable asset, reporting reachability at least every seven days if not automatically feeding CISA’s monitoring.

Forensic triage: the requirement most CABs will underscope

The harshest tier is not just “patch in three days.” It is “patch in three days and carry out a forensic triage of the asset to assess whether the system is compromised,” per the directive. The directive is deliberately terse about what forensic triage entails, pointing to a separate Implementation Guidance document. IANS reads the requirement, which links to NIST SP 800-86, as most likely meaning “indicator-of-compromise (IoC) sweeps in logs and other telemetry,” and notes it is “only required in situations where the vulnerability is being actively exploited (i.e., it is in the KEV).”

For change management, this is the tier that needs a rehearsed runbook, not an ad-hoc scramble. A three-day KEV-plus-total-control item means your emergency change and an incident-response mini-investigation run in parallel, on the same clock. If your CAB treats those as sequential — patch first, investigate later — you will miss the intent of the directive even when you hit the patch deadline.

Did CISA really kill CVSS?

Much of the vendor commentary has framed BOD 26-04 as “the death of CVSS.” That framing overstates what the directive text actually says. The directive does not tell agencies to stop using CVSS; the only mention describes technical impact as “similar to the Common Vulnerability Scoring System (CVSS) base score’s concept of ‘severity.’” What changed is the basis for the mandate: federal remediation deadlines are no longer keyed to a CVSS threshold but to the four-variable model, which is “tightly aligned with the Stakeholder-Specific Vulnerability Categorization (SSVC) from Carnegie Mellon University,” per IANS. Analysts calling it the end of CVSS-as-policy — such as SecurityWeek’s post-mortem on severity-driven patching — are describing the policy shift, not a directive-level ban. If a vendor tells you CVSS is now forbidden, that is their spin, not CISA’s text.

What to do about it

Change managers and CAB chairs should treat the next four months as a rebuild window. The directive gives agencies 60 days from issuance to update their vulnerability-management processes and 180 days to be running the full Table 1 timelines — roughly August 9 and December 7, 2026 by the calendar, though CISA states these only as day counts, not fixed dates.

  1. Re-tier your change SLAs to match Table 1. Replace any single “critical patch = 14 days” rule with the four-variable lookup. Bake the 3-day, 14-day, 60-day, and fix-on-upgrade windows into your change categories so approvers see the deadline the moment a ticket is created.
  2. Wire the KEV feed into ticket creation. Because the clock can start when CISA adds a CVE, subscribe to the KEV catalog and auto-flag any open change or asset it touches. Our live KEV tracker and the guide on how to read a CISA KEV entry both help teams triage additions the day they land.
  3. Build a weekend-capable emergency-change path. Calendar days mean your three-day process must function without a full CAB quorum. Pre-authorize a standing emergency-change authority and a documented rollback plan so a Friday KEV addition does not stall.
  4. Pair patching with a triage runbook. For the top tier, define exactly which log sources you sweep for IoCs and who owns the compromise assessment, so remediation and investigation run together inside the three days.
  5. Make deferral decisions defensible. The 60-day and fix-on-upgrade tiers are generous, but only if you can show your work. Keep an audit-ready record of the four-variable determination behind every deferral — regulators and, per Tenable’s guidance on BOD 26-04 risk reporting, agency leadership will expect you to defend it.

Contractors and SaaS vendors in federal supply chains should not wait to be asked. Map your own change process to Table 1 now; it is far cheaper than retrofitting it during a contract review. For the broader compliance backdrop, our compliance pillar and the DORA operational-resilience checklist cover adjacent obligations that share the same audit-trail logic.

The tooling angle, honestly

Every major vulnerability-management vendor has rushed out a BOD 26-04 module, and each has a real gap worth naming. Tenable’s reporting layer maps cleanly to the four variables but leans on you to feed accurate exposure data — its determination is only as good as your asset inventory. Qualys published an early explainer of the 3-day SLA and its platform automates tier assignment, but its native change-workflow integration is thin, so the ticket hand-off to your ITSM tool is still manual for many teams. Neither replaces the CAB judgment the directive now demands: a tool can tell you a CVE is a 3-day item, but only your board can authorize the emergency change and sign off that a deferral is defensible.

Bottom line

  • BOD 26-04 (June 10, 2026) revokes BOD 22-01 and BOD 19-02 and replaces the flat 14-day KEV clock with 3-day, 14-day, 60-day, and fix-on-upgrade tiers.
  • Four variables set the tier — exposure, KEV status, exploit automation, technical impact — and CISA supplies three of the four via Vulnrichment.
  • Deadlines are calendar days and can start when CISA updates the KEV, so emergency-change paths must work on weekends and without a full CAB.
  • The top tier adds a forensic-triage duty; patching and compromise assessment run on the same three-day clock.
  • Update your processes by roughly August 9 and run full Table 1 timelines by roughly December 7, 2026.

Frequently asked questions

Published July 28, 2026.