CISA has told federal civilian agencies to stop ordering their patch queues by CVSS score. Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, issued on 10 June 2026, replaces severity ratings with four yes/no questions and a sixteen-row lookup table that turns the answers into a fixed deadline in calendar days.
It revokes BOD 19-02 and BOD 22-01 outright. A single note in CISA's implementation guidance carries most of the weight: by revoking BOD 19-02, the Federal Civilian Executive Branch no longer requires CVSS for vulnerability prioritisation.
Nothing here binds you unless you run an FCEB system. That is not the point. These four questions are the ones good vulnerability managers have asked informally for years, and there is now a government document to put in front of an audit committee that wants to know why you left a 9.8 unpatched.
The four questions
Asset Exposure. Is the vulnerable asset publicly exposed? CISA defines that as any agency-owned or agency-managed IT resource reachable by unauthenticated or untrusted entities over a public network, regardless of its physical or logical location. Reachability decides it, not where the box sits on a network diagram. If any one of your discovery methods says the asset is exposed, the answer is yes.
KEV Status. Is the CVE in CISA's Known Exploited Vulnerabilities catalogue? CISA says it aims to update KEV within 24 hours of confirming exploitation, and that a public proof of concept is not a requirement for inclusion.
Exploit Automation. Can an adversary automate every step needed to exploit the vulnerability? CISA's working heuristic: if public proof-of-concept code achieves remote code execution and runs reliably against a vulnerable system, the answer is yes. This is the SSVC decision point of the same name, and it matches the supplemental metric in CVSS v4.
Technical Impact. Does exploitation give partial or total control? CISA's guidance treats it as total if the attacker can install and run arbitrary software, trigger every action the vulnerable component can perform, obtain an administrator or root account, or if CVSS confidentiality and integrity are both High. Credential-disclosure bugs count as total — the guidance names Heartbleed and Citrixbleed as the pattern. Denial of service is partial.
The division of labour matters more than the definitions. CISA publishes three of the four answers itself for a large share of CVE IDs through the Vulnrichment programme, with documented defaults applied where enrichment has not yet landed, which writes SSVC decision points into CVE records as an Authorized Data Publisher. You supply the fourth. Exposure is the only field the directive expects the asset owner to own.
Table 1, in full
This is the whole scheme. Days are calendar days.
| Publicly exposed | In KEV | Automatable | Technical impact | Remediation timeline |
|---|---|---|---|---|
| Yes | Yes | Yes | Total | 3 days & forensic triage |
| Yes | Yes | Yes | Partial | 3 days |
| Yes | Yes | No | Total | 3 days & forensic triage |
| Yes | Yes | No | Partial | 14 days |
| Yes | No | Yes | Total | 3 days |
| Yes | No | Yes | Partial | 14 days |
| Yes | No | No | Total | 14 days |
| Yes | No | No | Partial | 60 days |
| No | Yes | Yes | Total | 3 days & forensic triage |
| No | Yes | Yes | Partial | 14 days |
| No | Yes | No | Total | 14 days |
| No | Yes | No | Partial | 14 days |
| No | No | Yes | Total | 60 days |
| No | No | Yes | Partial | 60 days |
| No | No | No | Total | Fix on system upgrade |
| No | No | No | Partial | Fix on system upgrade |
CERT/CC hosts the same logic as a machine-readable SSVC decision table, published in the CERTCC/SSVC repository as a BOD 26-04 decision file. You can wire that into a pipeline rather than transcribing sixteen rows by hand.
Agencies are on a three-phase clock. Phase I, covering policy updates and KEV monitoring, took effect on issuance; Phase II fell due 60 days later. Phase III is the one that bites: within 180 days, meaning 7 December 2026, agencies must remediate to these timelines and continuously tag every asset reachable from outside their network. FedRAMP has aligned its own mandatory reporting rules to the same December date.
What changes in the queue on Monday morning
Three rows deserve a hard look.
Row five. Publicly exposed, not in KEV, automatable, total control — three days. KEV membership is no longer the trigger for the fastest lane. A fresh internet-facing pre-auth RCE with working exploit code gets a three-day clock the day you find it, with no wait for CISA to confirm exploitation in the wild. Most private-sector SLAs still give that thirty days, because it arrived as a critical alongside forty others.
Row nine. Internal, in KEV, automatable, total control — three days plus forensic triage. Being off the internet buys nothing here. If your policy carries a blanket clause giving internal systems 90 days, this row is the argument for deleting it.
Rows fifteen and sixteen. Internal, not in KEV, not automatable — fix on the next scheduled major upgrade or rebuild, even at total control. CISA states plainly that agencies do not need to prioritise these.
The three-day clock is the headline, but the bottom two rows are the real change. A regulator has put in writing that a total-control vulnerability can wait for the next rebuild. That is the sentence to reach for when someone demands a 100 per cent patch-compliance figure.
Two mechanics are easy to miss. The clock starts at whichever comes first: CISA adding the CVE to KEV, or your own enumeration of the vulnerability on an asset. And the timelines move in both directions as facts change. Pull a box off the internet and Publicly Exposed flips to No, which lengthens the deadline — the directive names this as a valid mitigation. A later KEV addition shortens it again.
Exposure is the field you have to build
Because three answers arrive free, the quality of your prioritisation now rests almost entirely on whether you know what is reachable from the internet. CISA is candid that agencies will not have this cleanly, and publishes a fallback: a publicly routable IP means public; an asset type tagged as network means public; for KEV CVEs, software that is generally internet-facing means public; otherwise internal.
That fallback is coarse, and you should read it as a warning rather than a method. It will mark your management switches as public and miss the forgotten Apache instance NATted through a load balancer.
A second default is worth knowing. Where Automatable and Technical Impact are not yet published for a non-KEV CVE, CISA treats them as no and total respectively until enrichment lands. Unknown impact is assumed to be the worst case. Build the same bias into your own pipeline.
Agencies must tag assets with organisation and sub-organisation, environment (production or development), exposure (public or internal), and asset type (server, application or network device). Four fields. If your CMDB cannot produce them, that gap is your actual project, not the scoring change.
Forensic triage is the expensive part
Three of the sixteen rows demand more than a patch. The implementation guidance sets out six steps: scoping, evidence preservation, patching and stabilisation, containment, triage analysis, and an escalation decision producing a written report. CISA attaches target timings from two hours to 72 hours after a KEV addition, but says those are recommended practice; the binding requirement is that an adequate triage happens.
The ordering is the instructive bit. Collect volatile evidence before you patch, because patching destroys artefacts. Contain in a way that does not tell the intruder you have noticed. CISA's own framing: "Applying a patch generally does not evict a threat actor."
Most organisations have no runbook for this. They have an incident response plan that triggers on an alert, a patching process that triggers on an advisory, and nothing that triggers on the discovery that something sat exploitable and exposed for eleven days.
Running this outside government
- Make internet reachability an authoritative, continuously refreshed field in your asset inventory, sourced from external scanning and cloud control planes rather than from what the network diagram claims.
- Ingest CISA's SSVC decision points from the CVE records published through the cisagov/vulnrichment feed and map them onto your findings by CVE ID.
- Re-sort your existing backlog on the four fields, then compare it with your CVSS-ordered list. The delta between the two is the report to take to your CISO.
- Write the deferral rule down. Internal, not known exploited, not automatable means the next scheduled rebuild, and that should be recorded once as policy rather than relitigated every month.
- Build the evidence-first triage runbook for the top-severity combination before you need it, out-of-band comms included.
- Put concrete remediation timelines into SaaS and cloud contracts. CISA tells agencies to do exactly that, and notes that scanner vendors have so far made no commitments to automate the table.
That last point is the one to press. The four decision points are published, free and machine-readable, and the deadline logic is a lookup against sixteen rows. If your vulnerability management platform still ranks findings by base score and cannot filter on exposed, automatable, total control, the directive has handed you a precise feature request and a federal precedent to staple to it.
