Path & Payload

CISA’s New Directive Takes Aim at the CVSS Priority Queue

Consider two vulnerabilities. The first scores 9.8 on the CVSS scale — technically critical, but sitting on an internal system, never touched by a public exploit, with no evidence of active use in the wild. The second scores 7.2 — medium-high, the kind of thing that might not make the top of your queue. Except it's being actively weaponized right now, on an internet-facing asset, by attackers who can automate the exploit and chain it into full system control. As Cisco Talos researcher Thorsten Rosendahl noted in May 2026, these are very different problems.

So which one do you patch first?

If you’re using CVSS as your primary triage signal, you’re in trouble. CVSS was designed to measure technical severity — how bad exploitation could be — not how likely it is, not whether your assets are exposed, not whether attackers are already moving on it. But many organizations started treating it as a de facto priority queue, partly because CISA had long tied federal remediation timelines to CVSS severity categories.

Yesterday, CISA formalized what practitioners have argued for years: severity isn't risk, and treating it as such has real consequences. Binding Operational Directive 26-04: Prioritizing Security Updates Based on Risk formally replaces CVSS-based triage with a framework built around the signals CVSS doesn’t take into account.

Where We've Been

If you read the earlier breakdown of how attackers learned to game CVSS, this directive feels like institutional confirmation. The problem was never that CVSS scores were too high or too low, but rather that the score measures the wrong thing for triage. A numerical severity rating calculated at the time of disclosure — before anyone knows who's exploiting it, how, or against what — tells you almost nothing about the actual risk to your environment right now.

The results of that mismatch are documented. According to Verizon's 2026 Data Breach Investigations Report, only 26% of vulnerabilities on CISA's Known Exploited Vulnerabilities (KEV) catalog were fully remediated by organizations in 2025 — down from 38% the prior year. The median time for full resolution rose to 43 days. Defenders were falling behind on the vulns that actually mattered, while the full patch queue kept growing. BOD 26-04 is CISA's formal response to that failure. It doesn’t eliminate severity scoring, but it makes contextual risk — exposure, exploitation, automation and impact — the basis for federal patch urgency.

The Framework Shift: SSVC Replaces CVSS-Score Triage

The most notable thing about BOD 26-04 is the scoring methodology. The directive formally moves federal vulnerability triage from CVSS to Stakeholder-Specific Vulnerability Categorization (SSVC) — a framework developed at Carnegie Mellon's Software Engineering Institute and adopted by CISA through its Vulnrichment program. Where CVSS produces a numerical severity score independent of context, SSVC produces a triage decision based on an organization's specific exposure and the real-world behavior of a given vulnerability.

Under BOD 26-04, that decision rests on four variables:

Those variables map directly to remediation timelines. A vulnerability meeting all four criteria must be remediated within three days, with a mandatory forensic triage to assess whether the system has already been compromised. Vulnerabilities meeting fewer criteria get longer windows — or in many cases, can legitimately wait for the next scheduled upgrade cycle.

As the runZero research team noted in their day-one analysis, SSVC “excels at guiding remediation decisions based on organizational context — moving teams past abstract numerical risk scores” to guide engineering resources toward flaws that directly affect business continuity and operational stability. The shift is significant because the triage framework is now asking, “What does this mean for your environment, right now?”

The Patch-Doesn't-Mean-Evict Problem

BOD 26-04's implementation guidance adds a requirement that changes agencies' approach to remediation. Before patching high-priority vulnerabilities, agencies must perform forensic triage to determine whether the affected system was already compromised. This is necessary because patching an actively exploited vulnerability doesn't evict a threat actor who's already inside. If the attacker is already in, the door is now merely locked behind them.

BOD 26-04 emphasizes that remediation and incident response are not the same thing, and confusing them is how compromises go undetected long after the patch was applied.

The forensic triage workflow CISA prescribes is structured around the “who, what, where, and when” of any suspicious pre-patch activity — and it feeds into a formal escalation path that can pivot from triage to full incident response. This is a different operational posture than most vulnerability management programs currently support.

The Scope Limitation in BOD 26-04

BOD 26-04 is a perimeter-first framework, and deliberately so. The directive concentrates on publicly exposed assets and doesn't impose the same urgency for vulnerabilities deeper inside the network — and CISA was explicit about the reasoning behind it.

According to CISA's "Patch Smarter, Not Harder" blog post, threat actors don't typically compromise core networks through product vulnerabilities. They get in through exploitable configurations and valid credentials — a technique known as living off the land (LOTL). CISA's position is that LOTL is better addressed through configuration hardening, network segmentation, and phishing-resistant MFA than through a patching timeline, and that's a reasonable scope decision for a directive focused on vulnerability remediation.

What this means practically is that BOD 26-04 addresses the door attackers are most likely to walk through first. What happens after they're inside — lateral movement, credential abuse, persistence — is a separate problem that requires a separate set of controls. Defenders should treat this directive as one layer of a larger program, not a complete vulnerability management strategy. For agencies and organizations where LOTL-style post-breach activity is a primary concern, the work beyond BOD 26-04 is just as important as complying with it.

This is an incremental improvement over CVSS-first triage — a significant one, but defenders still need to ask what their program looks like in the areas the directive doesn’t reach.

SSVC Coverage Is Incomplete

Implementing BOD 26-04 harder than it looks on paper. The directive mandates SSVC-based prioritization. But CISA's Vulnrichment program — the mechanism through which CISA publishes SSVC assessments for CVEs — currently covers only 45.8% of known CVEs, leaving agencies responsible for manually assessing automatability and technical impact for more than half of all vulnerabilities they encounter.

Manual SSVC assessment is far from trivial. The “automatable” criterion in particular requires evaluating whether a specific exploitation path can be scripted and executed at scale — a judgment that requires current threat intelligence, technical familiarity with the vulnerability, and knowledge of your own asset topology. For agencies with resource-constrained security teams, the directive's three-day intent can create compliance theater: vulnerabilities logged as in-progress without genuine triage completed.

Third-party tools can help fill the data gap, but they don't fully solve the compliance problem. VulnCheck, for example, automated SSVC decision generation following CISA's Vulnrichment launch in 2024 and reports 90% CVE coverage — but agencies are required to use CISA's assessments for compliance purposes, so broader third-party coverage doesn't automatically close the gap in the official record.

Where tools like VulnCheck offer a more immediate advantage is speed. Exploitation indicators frequently appear in third-party databases days, months, or sometimes years before a vulnerability makes it onto CISA's official KEV list. For teams working against a three-day remediation window, that lead time makes the difference between proactive triage and reactive scrambling.

Any organization trying to adopt the BOD 26-04 framework for their own vulnerability program will hit the same data gap.

Beyond SSVC: Additional Signals Worth Watching

BOD 26-04 establishes SSVC as the triage backbone, but practitioners have been developing a richer signal stack for some time. Two are especially valuable.

EPSS (Exploit Prediction Scoring System) is a dynamic probability score — updated daily — indicating how likely a given CVE is to be exploited in the next 30 days, based on real-world signals. Where CVSS is static and theoretical, EPSS is probabilistic and current. Cisco Talos' Thorsten Rosendahl frames the two as complementary rather than competing: CVSS tells you how bad exploitation would be, while EPSS tells you how likely it is to happen soon. High CVSS plus high EPSS is the “drop everything” tier, whereas high CVSS plus low EPSS is something that can ride the normal cycle.

Global CVE (GCVE) is another approach — a decentralized one — to vulnerability identification and enrichment that Rosendahl flags as relevant for practitioners outside the U.S. federal visibility surface. Because GCVE isn't a single centralized list, enrichment data, such as affected products, exploit indicators, and references, doesn't wait in one queue. This means actionable context can arrive faster than the traditional NVD pipeline, and exploitation signals from sources beyond U.S. federal visibility get surfaced against the same identifiers.

CISA has also indicated it will review BOD 26-04 on a rolling basis and update implementation guidance as the threat landscape evolves. NIST, for its part, recently proposed a third metric — Likely Exploited Vulnerabilities (LEV) — as an estimate of whether a vulnerability has already been used in attacks. The signal stack is still being built.

What This Means Outside Federal Agencies

BOD 26-04 is legally binding only for Federal Civilian Executive Branch agencies. But the framework it encodes — and the implicit critique of CVSS-only prioritization that it represents — matters for anyone running a vulnerability management program.

Cloud service providers with FedRAMP ambitions should be paying attention. CISA has signaled that agencies will be reviewing contractor agreements to ensure compliance support, and FedRAMP requirements are likely to reflect BOD 26-04's priorities in the near term. Organizations that haven't yet operationalized SSVC-based triage will probably have less runway than they think.

For everyone else, the four-criteria framework is a practical self-assessment tool available right now, no mandate required. Run your open vulnerability inventory against these questions:

That last question is the one most likely to expose a gap in current practice. The forensic-before-patching discipline is the most operationally significant shift in BOD 26-04, and it applies regardless of your sector or regulatory environment.

The Bottom Line

CVSS was a useful tool for a simpler threat environment. It gave defenders a shared vocabulary for severity and a starting point for prioritization. But severity isn't risk, and the gap between them is where attackers have been operating for years.

BOD 26-04 is an official acknowledgment of that gap. SSVC isn't a perfect replacement — the coverage problem alone means implementation will require additional data sources and manual judgment for the foreseeable future. And the directive's perimeter focus leaves real exposure in post-breach environments where LOTL techniques are the primary threat.

But the direction is right. The question SSVC asks — what does this vulnerability mean for your specific environment, against the current threat landscape? — is the question that was always missing from CVSS-first triage.

Sources

#Perspectives