On June 10, 2026, CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk." It replaces BOD 19-02 and BOD 22-01, and it does something federal vulnerability policy hasn't done before: it stops requiring CVSS.
Federal Civilian Executive Branch agencies no longer sort their patch queue by severity score alone. Instead, BOD 26-04 asks four binary questions about every vulnerability on every asset:
A vulnerability that clears all four gets three calendar days. Everything else moves through 14-day, 60-day, or next-upgrade tiers, with a compromise-assessment requirement built in before any patch goes on.
It's a real shift, and CISA is explicit about why: AI is compressing the gap between disclosure and weaponization, and a static severity number assigned once at publication can't keep pace with that. The directive is binding only on FCEB agencies, but CISA has said plainly that it expects the model to travel — the same way the KEV catalog did after BOD 22-01.
Here's what the four-variable model still doesn't do. It tells you how exploitable a vulnerability is. It says nothing about what exploiting it would cost.
Two internet-facing devices can score identically on all four BOD 26-04 variables — publicly exposed, KEV-listed, automatable, full technical control — and sit at opposite ends of the consequence spectrum. One is a jump box. The other is a human-machine interface sitting in front of a distributed control system running a continuous process. Same technical risk tier under the directive. Not remotely the same exposure if either one is exploited.
This isn't a flaw in BOD 26-04 — it was never built to answer that question. Federal IT environments are its design center, and for IT, technical impact and financial impact are reasonably correlated: full control of a system usually does correlate with data loss, and data loss is the thing the directive's authors were pricing in when they built the impact criterion. OT breaks that correlation. In an industrial environment, the vulnerability that matters most is rarely the one with the highest severity score or even the cleanest exploit chain — it's the one sitting closest to a process that, if interrupted, produces downtime, safety exposure, or equipment damage measured in millions of dollars. CVSS sorts by severity. BOD 26-04 sorts by exploitability. Neither sorts by expected loss, and expected loss is the number a CISO has to defend to a board or a CFO.
There's a second gap that matters even more for OT teams trying to comply with — or simply learn from — BOD 26-04: the directive assumes remediation capacity that OT environments often don't have on the timeline it specifies. A DCS controller cannot be patched outside a scheduled production outage, and those windows come around once a year or less, planned months in advance. Vendor-dependent firmware updates can require an OEM on-site. Some fielded systems run software that is end-of-life and cannot be patched at all, full stop.
A three-day remediation clock, applied without that operational context, produces a queue OT teams cannot execute against — regardless of how correctly the underlying vulnerability was tiered. This is the same reason a straight CVE severity list has never worked well in OT: it ranks by a number that has no relationship to what a plant can actually do next Tuesday.
This is where a vulnerability-level financial risk quantification approach complements BOD 26-04's model rather than competing with it. The directive's four variables — exposure, KEV status, automation, technical impact — are good exploitability signals. Feed them into a model that also prices the asset behind the vulnerability, and the output changes from "how likely is this to be exploited" to "how much expected loss does fixing this actually remove."
DeNexus's DeRISK™ QVM (Quantified Vulnerability Management) is built around exactly that reordering: it takes a CVE list and ranks it by expected loss reduction instead of severity score, using the same probabilistic risk model that underlies DeRISK CRQ. In DeNexus's own client data, a recurring pattern shows up: only 1–2% of vulnerabilities on a typical OT network drive 90% of the actual financial risk. A remediation queue built on BOD 26-04's exploitability signals alone still has to work through the full list within each tier. A queue that also weights those signals against expected loss reduction lets a team fix a smaller number of things and remove most of the exposure — DeNexus has measured 40–60% fewer remediation tickets for equal or greater risk reduction compared to CVE-only workflows. The same approach also builds in the operational constraint data BOD 26-04 doesn't touch — maintenance windows, vendor lead times, EOL status, safety restrictions — so the sequence a team gets is one they can actually run, not just one that's correctly tiered on paper.
BOD 26-04 answers "what's exploitable, and how urgently." That's a genuine advance over a static severity score, and OT security teams should treat it as a useful signal even outside the federal mandate it creates. But exploitability was never going to be the whole answer for environments where the real question is what a specific asset failing would cost — in downtime, in safety, in regulatory exposure. Federal policy just moved past CVSS. The organizations that get the most out of that shift will be the ones that pair it with a model that translates exploitability into dollars, not the ones that treat either number alone as the final word.
BOD 26-04 tells you what's exploitable. DeRISK™ QVM tells you what it would cost — ranking your vulnerability queue by expected loss reduction, constrained by the maintenance windows and vendor timelines your plant actually operates under. Learn more about the DeRISK Platform or book a demo to see it against your own environment.