SSVC just got teeth. Half the decision was never in the CVE.
Aviral Verma and Mike Hindman
Securin Team
June 12, 2026
CISA turned a triage methodology into a compliance clock. Three of its four criteria describe the vulnerability. The fourth describes your environment, and no CVE feed on earth can answer it.
TL;DR CISA's BOD 26-04 makes SSVC-based prioritization mandatory and ties remediation deadlines to four criteria. Three are properties of a CVE. The fourth, asset exposure, is a property of your environment, and it sets the clock.
No. | TL;DR |
|---|---|
1 | The market automated the easy three. Exploitation, Automatable, and Technical Impact derive from a CVE record; CISA's own Vulnrichment still covers under half of all CVEs. |
2 | No feed can answer the fourth. Asset exposure requires knowing your attack surface; CISA's own KEV entry for our specimen tells agencies to evaluate each asset's internet exposure to set the deadline. |
3 | We modeled all four when SSVC launched. Every CVE in Securin already carries the directive's inputs as structured fields; SSVC gives the deadline, the Risk Index gives the order. |
4 | The matrix scores one CVE at a time; attackers chain. Two non-KEV vulnerabilities, an exposed IBM HTTP Server edge and a Windows Kerberos interior bug, each defer alone but join into one edge-to-domain compromise. |
Four questions now set the clock
On June 10, 2026, CISA issued Binding Operational Directive 26-04, superseding BOD 19-02 and BOD 22-01 and replacing uniform KEV deadlines with a risk matrix. Four variables now determine how fast a federal agency must remediate a vulnerability:
• Asset Exposure: is the vulnerable asset publicly reachable?
• KEV Status: is the CVE on CISA's Known Exploited Vulnerabilities catalog?
• Exploit Automation: can an adversary automate every step of exploitation?
• Technical Impact: does exploitation give the attacker partial or total control?
Hit all four and the clock reads three days, plus a mandatory forensic triage to determine whether you were already compromised. Miss criteria and the deadline relaxes to 14 days, 60 days, or deferral to the next system upgrade. Agencies have until August 9 to update their processes and until December 7 to operate on these timelines.
Three criteria live in a CVE record. The fourth lives in your attack surface.
This is SSVC. It is also not SSVC.
The directive is built on the Stakeholder-Specific Vulnerability Categorization (SSVC), but CISA made two surgical changes. The Exploitation decision point, which recognized three states (none, public proof of concept, active), collapses to a binary: on the KEV or not. PoC evidence now matters only indirectly, as a heuristic for the Automatable decision.
Second, and more interesting, CISA dropped SSVC's Mission Prevalence and Public Well-Being decision points, the nodes that made SSVC stakeholder-specific in the first place, and replaced them with something measurable: asset exposure. The fuzzy organizational-context question became a concrete environmental fact. Is this asset reachable from the internet, yes or no.
That swap is the entire story of this directive. And the directive does not treat exposure as a one-time tag. Agencies must continuously identify and tag every externally reachable asset, attest their public IPs and domains quarterly, and report machine-level data on a fixed cadence. Exposure is now a living input with a reporting obligation attached.
The race to automate the CVE half
Three of the directive's four decision points can be derived from a CVE record, and the market knows it. Exploitation can be read from exploit intelligence, Automatable and Technical Impact from CVSS vectors, and enrichment programs and commercial feeds have been racing to automate exactly that. CISA's own Vulnrichment program assigns SSVC decision values at scale, yet it still covers under half of all published CVEs. Close that coverage gap entirely and the result is still, structurally, half the matrix.
It is good work. It is also, structurally, half the matrix. Exploitation, Automatable, and Technical Impact are properties of a CVE. Asset exposure is a property of you. No vulnerability intelligence feed, however broad, can tell an agency which of its assets sit on routable IPs, which ones drifted into exposure last Tuesday, or which deadline therefore applies. A CVE feed can label the vulnerability. It cannot assign the timeline. Under BOD 26-04, the timeline is the whole point.
We did not start building this last week
When CISA put SSVC at the center of its enrichment strategy, we made every attribute the methodology asks about a first-class field in the platform. Because those attributes were modeled when SSVC launched, agencies adopting BOD 26-04 today are not waiting on a data backfill. Every CVE record already carries the directive's inputs as structured, queryable fields: exploitation evidence our threat research often surfaces before the CVE lands on the KEV, exploit maturity and weaponization, and impact attributes that map to the partial-versus-total decision.
And because Securin is a full exposure management platform, not a feed, the fourth criterion is native: attack surface discovery continuously identifies which of your assets are publicly exposed, which is exactly the continuous tagging obligation the directive imposes.
SSVC buckets. Risk Index ranks.
SSVC, as operationalized in BOD 26-04, sorts vulnerabilities into a handful of timeline buckets using a few binary questions. That is a feature for a federal mandate, which needs to be auditable and simple. But a 3-day bucket containing 40 vulnerabilities still leaves a team asking: which one first?
Securin's Risk Index is computed from the same signals the SSVC tree consumes, exploitation evidence, automation potential, technical impact, plus the ones it ignores: threat actor association, ransomware linkage, trending exploitation, and predictive weaponization. On the specimen CVE it moved 0 to 4.9 to 6.26 to 8.54 to 9.16 over 72 hours, each step annotated as evidence accrued, reaching Critical before EPSS crossed its own threshold. Every BOD 26-04 decision is derivable from the data already underneath the Risk Index. The reverse is not true. SSVC tells you the deadline. The Risk Index tells you the order, and frequently tells you before the KEV does, because exploitation evidence does not wait for catalog updates.
One CVE, side by side
The cleanest way to see the gap is one CVE, side by side. Our specimen: CVE-2026-10520, an OS command injection in Ivanti Sentry, an internet-facing gateway. CVSS 10.0 with changed scope. Disclosed Tuesday, June 9. The directive landed Wednesday. CISA added it to the KEV Thursday, June 11, with a Sunday, June 14 deadline, and the required-action text names BOD 26-04 outright. The 3-day clock is running as this publishes. One column stops at the CVE. One ends with a deadline and a worklist.
That difference is not a data coverage gap. It is an architecture difference, and no amount of CVE enrichment closes it.
FROM THE CISA KEV ENTRY FOR THIS EXACT CVE |
CISA’s required-action text for CVE-2026-10520 instructs agencies to ensure compliance with BOD 26-04 and to evaluate each asset’s internet exposure when setting the patching deadline. The catalog entry itself says the timeline depends on asset exposure. The one decision a CVE feed cannot make is the one CISA put in writing. |
The question the matrix cannot ask: what about chains?
BOD 26-04, like SSVC and every scoring system before it, evaluates one CVE at a time. Attackers do not.
BOD 26-04 scores each CVE in isolation. Adversaries exploit them in sequence. An internal, partial-control vulnerability draws a relaxed tier on its own, but paired with an exposed, automatable foothold it becomes the lateral-movement step that turns a breach into a domain compromise. SSVC's own guidance acknowledges this, noting that automatability should be judged on the chain when exploitation requires one; the directive's per-CVE reading quietly drops it.
Here is that abstraction grounded in two real records, and this time neither one is on anyone's must-patch list. CVE-2026-8855, a memory-corruption flaw in IBM HTTP Server (CVSS 9.8), and CVE-2025-53779, a Windows Kerberos elevation-of-privilege bug (CVSS 7.2), are both public and analyzed, yet neither is KEV-listed. Run each through the directive's binary gate on its own and it lacks the active-exploitation signal that trips the short clock, so each routes to a deferred timeline.
Their ATT&CK mappings, both already structured fields in the platform, tell a different story. CVE-2026-8855 sits at the edge: Exploit Public-Facing Application (T1190) leading straight into code execution on an internet-reachable server, with an endpoint denial-of-service capability held in reserve. CVE-2025-53779 owns the interior, escalating privilege through Kerberos (T1068) and moving laterally on stolen authentication material (T1550). Lay the two technique sets end to end and they form one uninterrupted path, from the public edge to domain-wide movement.
Per-CVE decisions do not compose. Risk does. This is where exposure management has to go next: scoring the attack path, not the line item. An asset carrying two defer-class vulnerabilities that compose into one act-now path should inherit the shorter clock. That analysis requires knowing the asset, its exposure, and the full set of vulnerabilities on it simultaneously, which is, again, something no CVE feed can see and something a platform must.
BOD 26-04 is a genuine step forward. It forces the question every security team should have been asking: exposed, exploited, automatable, how bad. The next directive, or the next breach, will force the follow-up: and what do they add up to?
We are building for that question now.
Three days is a deadline. Order is intelligence. Every criterion in the directive, answered per asset, continuously. Plus the order to fix them in.
Share this post on:
