The CVSS-Only era is coming to an end
On June 10, 2026, CISA (the Cybersecurity and Infrastructure Security Agency) published Binding Operational Directive 26-04, replacing BOD 22-01, the directive that introduced the Known Exploited Vulnerabilities catalog in 2021, with something more ambitious: a structured risk-based prioritization framework for federal vulnerability management.
CVSS isn't being abandoned. FIRST describes EPSS as a complement to CVSS, not a replacement. But BOD 26-04 makes one thing unmistakable: CVSS as the primary driver of remediation decisions is no longer sufficient. Risk context must come first.
For security teams who have been arguing this for years, the signal from Washington is clear: the center of gravity has shifted. The question now is whether your operational model can actually support it.
What BOD 26-04 actually changes
The directive builds on the KEV catalog logic and introduces four decision variables to determine how urgently a vulnerability must be remediated:
- Asset Exposure: Is the vulnerable asset publicly accessible on the internet?
- KEV Status: Is the vulnerability listed in CISA's Known Exploited Vulnerabilities catalog?
- Exploit Automation: Can an adversary automate all steps necessary to exploit the vulnerability?
- Technical Impact: Does successful exploitation give an attacker partial or total control of the system?
These four criteria produce 16 possible combinations, each mapped to a specific remediation timeline. The highest-risk combinations, where exposure, active exploitation, automation potential, and system control intersect, can trigger a 3-day remediation deadline. Lower-risk combinations fall into 14-day or 60-day windows. The lowest-risk scenarios, with no public exposure, no known exploitation, and limited impact, can be deferred to the next scheduled system upgrade cycle.
In the most critical cases, patching alone is not enough: CISA's implementation guidance requires forensic triage to determine whether the system has already been compromised before the patch was applied. Remediation, in these scenarios, is not closing a ticket. It is confirming that exposure has not already turned into compromise.
Practitioners and early field analysis discussed around the directive suggest that only a small fraction of vulnerabilities fall into the most urgent window, while a significant majority may be safely deferred to scheduled upgrade cycles. This is the directive's clearest message: remediate fewer things, but remediate the right ones fast, and with proof.
From severity scoring to operating model
The most important thing about BOD 26-04 is not the timeline matrix. It is what the matrix implies about how vulnerability management must function as a discipline.
Every remediation decision now requires a traceable chain of context: Is this asset exposed? Is this CVE in the KEV? Can it be exploited automatically? What does the attacker gain? That chain must be resolved reliably, consistently, at scale for every vulnerability in scope, not just the ones a team has time to manually investigate. Then comes ownership, SLA assignment, remediation evidence, and in the most critical cases, forensic confirmation that no prior compromise occurred.
"The real shift is not the 3-day deadline. The real shift is that vulnerability remediation is becoming an operating model: every decision must be explainable, traceable, and tied to business and threat context."
And operating models have governance requirements. Someone must own the fix. Someone must accept the SLA, validate the remediation, document exceptions, and justify deferrals.
"Deferrals are not failures when they are risk-based, approved, documented, and time-bound. They become failures when they are invisible."
In that sense, RBVM is not only a scoring problem. It is a governance problem. Prioritization only creates value if it changes behavior downstream all the way from the risk signal to the closed ticket.
Why exploit automation changes the equation
The addition of exploit automation as a first-class criterion is the most forward-looking element of BOD 26-04. It reflects a structural asymmetry that every security leader is now contending with: attackers can scale discovery and exploitation faster than defenders can manually triage, assign, patch, and prove remediation.
CISA frames the directive explicitly against this backdrop. As Chris Butera from CISA has noted, AI enables malicious actors to find and exploit vulnerabilities at a pace that makes weeks-long remediation windows untenable for the most dangerous exposures. Recent research has reinforced the same point: AI-assisted tooling can compress the time between vulnerability disclosure and a working exploit from days to hours.
This is also why BOD 26-04 should be read as a baseline, not a ceiling. As Kevin E. Greene from BeyondTrust noted in response to the directive, the SSVC-inspired framework helps assess the blast of a single CVE on its component but it does not fully capture whether that component sits on a path to privilege escalation or broader lateral compromise. A CVE that cannot reach a privilege plane may be operationally limited even at CVSS 10. One that can, even at CVSS 6, may become business-critical.
Business context and asset criticality are not optional enrichment layers. They are prerequisites for decisions that are genuinely risk-based.
The missing layer: Vulnerability Operations
BOD 26-04 provides a clear framework. What it does not provide is the operational machinery to apply it.
Most organizations face a structural problem that no matrix solves on its own: tool fragmentation. Multiple scanners producing overlapping results. An incomplete or outdated asset inventory. Threat intelligence sitting in a separate platform. KEV enrichment handled manually, or not at all. Remediation tracked in spreadsheets or tickets with no SLA and unclear ownership.
"A risk matrix is only useful if the underlying data is reliable."
If asset exposure data is wrong, if scanner findings are duplicated, if KEV enrichment lags by days, or if vulnerability ownership is unclear the prioritization model collapses before it produces a single actionable decision.
This is the layer BOD 26-04 exposes but does not fill. And it reveals the real gap between understanding the four criteria and applying them continuously across an environment of thousands or hundreds of thousands of findings.
Closing that gap requires an operating model that connects exposure data, threat intelligence, technical impact, remediation ownership, SLA governance, and audit evidence in a single, automated, continuously updated workflow.
In this model, auditability is no longer a by-product of good process. It becomes a security deliverable: teams must be able to explain why a vulnerability was prioritized, why another was deferred, and how every remediation decision was governed including in scenarios where a regulator, an auditor, or a breach investigation asks.
How Hackuity operationalizes the BOD 26-04 Logic
Hackuity's platform was built for exactly this operating model. To operationalize BOD 26-04, organizations need more than four signals they need those signals normalized, deduplicated, contextualized, routed, and governed. The four BOD 26-04 criteria map directly to operational capabilities within the platform:
The important point is not that these signals exist individually. It is that they can be converted into remediation decisions without forcing teams back into manual arbitration. That is where enrichment becomes operations.
At the core is the True Risk Score, which fuses these signals into a single contextual indicator. From there, configurable SSVC-based decision tree logic supports risk-based routing of findings into remediation groups with defined SLAs translating the tiered logic of BOD 26-04's matrix into executable workflows. A vulnerability that is publicly exposed, in the KEV, and likely to be exploited at scale is not just scored higher. It is routed to the right team, with the right deadline, and leaves a traceable record of the decision.
Conclusion: The baseline is moving and execution is the work that remains
BOD 26-04 codifies a multi-signal risk framework as binding policy for federal civilian agencies. For organizations already building toward risk-based vulnerability management, it validates the direction. For those still anchored in CVSS-first programs, it sets a new reference point one that may also influence how regulators, auditors, and sector-specific bodies evaluate remediation maturity going forward. For MSSPs, it raises the bar even further: applying this logic across multiple client environments, each with different risk appetites and SLAs, requires a platform built for it not a spreadsheet.
The baseline is moving, execution is the work that remains.
Want to see how Hackuity operationalizes risk-based vulnerability management across your environment?
VR-1 | Property |
|---|---|
Model type | Post-trained cyber reasoning model |
Primary specialization | Multi-domain enterprise attack-chain discovery |
Starting condition | A scoped foothold and a concrete objective |
Operating surfaces | Cloud, identity, runtime, code, CI/CD, SaaS, and organizational context |
Success signal | Execution-verified completion of the objective |
Primary evaluation | IntrusionBench |
Preliminary result (preview) | More than 2× black-box pass@3 over the strongest evaluated frontier baseline |
Trajectory budget | Two-hour wall-clock limit per trajectory, or 250 agent turns (whichever comes first) |
