Skip to main content

CISA's BOD 26-04 Replaces CVSS-Driven Patching for Federal Agencies: What It Signals for Your Board

4 min read
CISO Daily
CISA's BOD 26-04 Replaces CVSS-Driven Patching for Federal Agencies: What It Signals for Your Board

CISA’s Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk”, was issued on 10 June 2026. CISA’s own alerts still point to it: its 2 October notice adding two Zammad flaws to the Known Exploited Vulnerabilities (KEV) catalog cites the directive and encourages all organisations to adopt risk-based vulnerability management (CISA alert, 2 October).

The directive legally binds only US federal civilian agencies. For everyone else it is a benchmark, and a board that asks “how do our patching rules compare?” is asking a fair question.

What the directive changes

According to CISA’s implementation guidance, BOD 26-04 revokes two earlier directives: BOD 19-02 (2019, internet-accessible systems) and BOD 22-01 (2021, known exploited vulnerabilities). The guidance states that agencies no longer need CVSS scores to prioritise fixes (CISA implementation guidance).

Instead, the deadline depends on whether the asset is publicly exposed, whether the flaw is listed in KEV, whether exploitation can be automated, and how much control an attacker gains. BleepingComputer reports a shortest deadline of three days, with a two-week tier for less urgent cases (BleepingComputer, 11 June). CISA’s guidance gives the three-day deadline as an example: a KEV flaw on a publicly exposed asset, with total technical impact, that can be exploited automatically. It also describes a “fix on system upgrade” tier for lower-risk items, and says the timelines are maximums that agencies may shorten. We did not see the full timeline table, which sits in the directive itself.

The part most boards will not expect: check before you patch

The guidance sets an expectation that agencies perform a forensic triage, meaning a quick check for signs that attackers got in before the fix. CISA describes the timings as recommended practice, and says the requirement is that “an adequate forensic triage analysis is performed”. Its suggested sequence runs from scoping in the first two hours, through evidence collection and patching within 24 hours, to an escalation decision at 48 to 72 hours after a KEV addition.

The business point is simple. Patching closes the door, but it does not tell you whether someone is already inside. That is the gap behind recent exploitation of long-known flaws, and it is why a “patched” status in a report is not the same as “safe”.

Supplier obligations

For systems run by third parties, CISA’s guidance says agencies must inventory assets in third-party environments and engage providers directly. It “strongly recommends” that remediation timelines be written into service-level agreements. Where the provider is commercial, the provider must report outstanding vulnerabilities to the agency. The guidance also says agencies must report public exposure information to CISA quarterly.

Dates to know

BleepingComputer reports a 60-day milestone for basing remediation decisions on CVE and KEV data, and a 180-day milestone for following the new timelines. CISA’s guidance page does not mention the 180-day date. By our own calculation, 180 days from 10 June is 7 December 2026, which matches the date the guidance gives for FedRAMP’s adoption of related rules. Treat the 180-day detail as single-source.

What this means for your organisation (our assessment)

Nothing in the directive obliges a private company to adopt it. We see three reasons to take it seriously anyway.

  1. It is a defensible standard. If you suffer a breach through a known exploited flaw, a regulator, insurer or court may ask what you were measuring yourself against. A published government method is easier to defend than an internal rule of “critical within 30 days”.
  2. Severity scores alone are a weak yardstick. CISA’s decision to drop CVSS as a requirement is a signal that exposure and known exploitation matter more than a number.
  3. It separates patching from assurance. Few corporate reports distinguish “fixed” from “fixed and checked for prior compromise”.

Questions for management

  • Do we hold a current list of internet-facing systems, and who owns each one?
  • When a flaw appears in KEV, what is our maximum time to fix on an exposed system, and how often did we meet it last quarter?
  • After patching an exposed system, do we check for earlier compromise, and who signs that off?
  • Do our supplier contracts set remediation timelines and require them to tell us about outstanding flaws?

Sources

All details above come from the three pages linked in the text, which we opened. We did not open the directive text itself.