What the document says
CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, on 10 June 2026, superseding BOD 22-01 from November 2021. BOD 22-01 had applied a single pair of remediation deadlines to every vulnerability CISA added to its Known Exploited Vulnerabilities catalogue: two weeks for most entries, six months for ones with a CVE assigned before 2021, adjustable only in cases of grave risk to the federal enterprise. BOD 26-04 replaces that flat clock with a tiered model, assigning urgency based on four factors: whether the vulnerable asset is publicly exposed, whether the vulnerability appears in the KEV catalogue, whether an adversary can automate every step needed to exploit it, and the technical impact an exploit would achieve.
The new directive also adds a requirement absent from BOD 22-01: for the highest-urgency vulnerabilities, agencies must assess whether a system has already been compromised, not simply apply the patch and consider the matter closed. Agencies must update their vulnerability management processes within 60 days of the directive and identify and tag their internet-facing assets, then remediate according to the risk-tiered timelines that follow, reporting either automatically through CISA's dashboard or on a biweekly manual basis.
Confidence and limits
The provisions summarised here come directly from CISA's own directive pages for both BOD 26-04 and the BOD 22-01 text it replaces. This entry does not evaluate how consistently agencies have applied the new risk-tiering criteria in practice, nor does it attempt to reproduce the directive's detailed remediation-timeline table.
Why it mattered
BOD 22-01's flat two-week deadline treated a critical, internet-facing, actively exploited vulnerability the same as a low-impact one buried on an isolated internal system, so long as both appeared in the KEV catalogue. That uniformity was simple to apply but did not reflect actual risk, and it gave agencies no structured way to argue for reprioritising limited patching capacity toward the vulnerabilities attackers could exploit fastest and most destructively. The compromise-assessment requirement addresses a separate, related gap: patching a vulnerability does not remove an attacker who already used it to get in, a distinction BOD 22-01 did not address.
Defensive takeaway
Build your own asset exposure and exploit-automation assessment into your patch prioritisation process rather than relying solely on catalogue membership, and treat patching a known-exploited vulnerability as the start of a compromise check, not the end of the incident.
- Can you identify, right now, which of your internet-facing assets carry a KEV-catalogue vulnerability with a known automated exploit?
- Does your patching workflow include a step to check for existing compromise before marking a critical vulnerability closed?
- If you are not a federal civilian agency, have you adapted BOD 26-04's four risk factors into your own internal prioritisation process?
The shift from a flat clock to a risk-tiered model is a bet that agencies can assess exposure and exploitability reliably at scale; whether that judgment holds up will depend on execution CISA's own directive pages do not yet show.