Introduction
Three days. That’s how long federal agencies now have to patch their riskiest vulnerabilities, and for the first time, a high CVSS score alone won’t land a vulnerability in that bucket.
On June 10, 2026, CISA issued Binding Operational Directive (BOD) 26-04, “Prioritizing Security Updates Based on Risk.” It replaces two long-standing directives, BOD 19-02 and BOD 22-01, and it throws out the assumption that’s shaped federal vulnerability management for years, that severity alone tells you how urgently to patch something.
Why the old approach doesn’t hold up anymore
CVSS was built to describe a vulnerability’s technical severity, and for a long time, that severity was assumed to be a close enough stand-in for real world risk. While it’s still a useful leading indicator today, it was never designed to account for the context that actually determines how dangerous a vulnerability is in practice, like whether it’s exposed to the internet or already being exploited in the wild.
A critical CVE on an isolated internal system and the same CVE on an internet facing production server can carry the same base CVSS score, even when the actual risk they pose isn’t close. Treating them the same way can mean security teams spread effort evenly across both, and the vulnerability that actually matters ends up competing for attention with others that pose far less real threat.
That gap has become harder to ignore as threat actors lean more heavily on AI across the attack lifecycle, from discovering vulnerabilities to automating exploitation, which can shrink the window between a vulnerability’s disclosure and a working exploit from months to days or less. Flat, severity based patching timelines struggle to keep pace with that shift, and many security teams are finding it harder to stay ahead of known exploited vulnerabilities as a result.
CISA built BOD 26-04 to push agencies toward prioritizing the vulnerabilities most likely to actually get exploited, rather than working every CVE on the same fixed schedule.
What is BOD 26-04?
Agentic workflows are automated processes where a model plans the sequence at run time and uses tools to act on each decision. The goal is fixed. The path to it is not. Everything else in this article follows from that trade.
The term covers a range. At one end sits a job that calls a model once and branches on the answer. At the other sits a process that runs for twenty iterations and picks its own tools each time.
Workflows and Agents Are Not the Same Thing
BOD 26-04 requires federal civilian agencies to prioritize remediation based on real-world risk instead of static severity scores. The engine behind that shift is SSVC, Stakeholder-Specific Vulnerability Categorization. Instead of a single 0 to 10 score, SSVC walks every vulnerability through a decision tree built on four points:
- Exploitation: Is it being actively exploited, does a proof-of-concept exist, or neither? (None / PoC / Active)
- Automatable: Can an attacker reliably automate the early stages of the kill chain against it? (No / Yes)
- Technical Impact: If exploited, does the attacker gain partial or total control? (Partial / Total)
- Mission & Well-being: How critical is the affected asset to the mission and to public safety? (Low / Medium / High)
The first three are properties of the vulnerability itself. The fourth isn’t, it depends entirely on what that asset actually does in your environment, which is exactly the “mission context” BOD 26-04 requires agencies to fold into the decision. It’s also the step that trips up most programs, since that context usually lives in someone’s head rather than in the tooling.
The decision tree lands each vulnerability in one of four outcomes:
- Act: drop everything and remediate now.
- Attend: expedite ahead of standard timelines, with supervisory attention.
- Track*: stay on the normal cycle, but watch for escalation.
- Track: no action beyond the standard update cycle.
The most urgent outcomes carry remediation windows as short as three days, with mandatory forensic triage for the most severe. Lower priority outcomes get 14 or 60 day windows, or can be deferred to the next scheduled system upgrade.
This isn’t confined to federal agencies, either. FedRAMP has already aligned to the directive through its response notice (0014) and its Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) requirements, extending BOD 26-04’s reach into the vendors that serve those agencies.
The directive is being implemented in a phased rollout, with the specific deadlines coming from Table 1: Remediation Timelines, in Appendix A of the directive. Phase 1 required agencies to update their vulnerability management policies and begin monitoring the KEV catalog immediately, Phase 2 required agencies to align their full remediation processes to the model, and Phase 3 requires full compliance with those remediation timelines by December 7, 2026.
How a real world risk ranking helps close that gap
The four signals BOD 26-04 asks agencies to weigh, exposure, active exploitation, automation potential, and technical impact, are exactly the kind of context that’s historically lived in separate tools and separate teams. Security teams have had to manually stitch together exposure data, KEV status, and impact assessments just to answer the question the directive now requires an answer to for every single finding.
CISA’s own model shows just how much that combination of factors changes the picture. Its Table 1 maps all 16 possible combinations of the four variables into five remediation tiers.
- Three days, with forensic triage. The vulnerability is on the KEV catalog and exploitation grants total control of the system, regardless of exposure or automation potential.
- Three days, without forensic triage. Other high risk combinations, such as a publicly exposed asset with an automatable exploit that grants total control, even if the CVE isn’t yet on the KEV.
- 14 days. The standard timeline for most KEV listed vulnerabilities and several other high risk, non-KEV combinations.
- 60 days. Lower risk combinations, such as a non-exposed asset with an automatable vulnerability that only grants partial control.
- Deferral to the next scheduled system upgrade. None of the four risk criteria apply.
A ranking system built around that same real world risk logic, surfaced directly where vulnerability management teams already work, removes that manual correlation step. Instead of triaging a flat list of CVEs by CVSS score and hoping the highest scores are also the highest risk, teams can see which vulnerabilities actually warrant the fastest response, and act on that directly.
What Orca is doing about it
Meeting BOD 26-04 shouldn’t mean bolting another tool or another manual process onto an already stretched team. We’re excited to announce that the Orca Security Platform now correlates findings across exposure, KEV status, automation potential, and technical impact so they map directly onto CISA’s own five remediation tiers, removing the manual work of cross-referencing those signals finding by finding.
That mapping is live today as a new filter in the Vulnerability Management view, letting teams sort and filter findings by where they land in CISA’s model. The three-day and 14-day findings surface immediately instead of getting buried in a list sorted by CVSS score alone, shortening the time between a new KEV entry and knowing exactly which of your findings it touches and how fast you need to move.
A dedicated widget is coming to dashboards in the near future, giving teams an environment-wide view of how findings break down across CISA’s tiers, and a clearer, more defensible way for security and compliance leaders to explain why a given finding was or wasn’t treated as urgent, which matters just as much in board and audit conversations as it does in the remediation work itself.
Conclusion
BOD 26-04 changes what federal agencies need to prioritize, and it changes what their vulnerability management tools need to show them. Orca’s goal is to make that shift as close to automatic as possible, so teams can spend less time correlating signals by hand and more time fixing what actually matters.
Orca is deep, accurate, and actionable, built for the teams securing what they build. See how the Orca Platform can help your team align with BOD 26-04 and cut through vulnerability noise. Book a demo today.