For just under five years, one rule governed exploited vulnerabilities across the US federal estate: get onto the KEV list, get a fixed deadline. On 10 June 2026 CISA scrapped it. BOD 26-04, “Prioritizing Security Updates Based on Risk”, revokes the two directives that had governed federal patching since 2019 and replaces them with four questions per flaw, and deadlines that run from three days, with or without forensic triage, to the next scheduled system upgrade.
CISA has no writ in Europe, and the directive binds nobody outside the US federal civilian government. Expect it in an audit questionnaire all the same: the agency's ideas seldom stay home, and auditors and customers tend to adopt them long before regulators do.
What BOD 26-04 actually changes
Two directives disappear at once. BOD 19-02 (2019) set remediation deadlines for internet-accessible systems; BOD 22-01 (2021) created the KEV catalogue of flaws with confirmed exploitation and attached the flat rule to it: 14 days for any CVE that entered the list (six months for pre-2021 ones), wherever the asset sat and whatever the flaw allowed.
In their place sits a matrix. Four binary questions per vulnerability, 16 possible combinations, five response tiers.
The four questions
- Is the vulnerable asset publicly exposed, reachable from outside the network on a routable IP address? This is the only variable each organisation must answer from its own inventory.
- Is the CVE listed in the KEV catalogue, meaning exploitation has been confirmed in the wild?
- Can an attacker automate every step needed to exploit the flaw?
- Does the flaw hand over total control of the asset if exploitation succeeds?
Three of the four answers are published for you: exploitation is confirmed by the KEV itself, while automation and impact come from Vulnrichment, CISA's enrichment programme built on SSVC, for the CVEs it covers. The question that stays on your desk is the first one, and answering it at all times takes a living inventory of the attack surface, not a quarterly scan.
The five response tiers
At the top sits the three-day tier with mandatory forensic triage, reserved for KEV-listed flaws that yield total control of the system. Below it sits a second three-day tier, without triage, for certain high-risk combinations that have not yet reached the KEV, then a 14-day tier as the standard accelerated window. The 60-day tier covers lower-risk combinations, and where none of the four criteria applies, the fix waits for the next scheduled upgrade.
None of these windows is fixed for good: a CVE entering the KEV shortens the deadline overnight, and taking the asset off the internet stretches it. As for how much work the top tier really implies, CISA's own pilot offers an answer. Reviewing one large civilian organisation, the agency found, per Tenable's review of the directive, that a mere 1% of vulnerability detections landed in the three-day tiers, while more than 60% could wait for the next upgrade. The effort concentrates on a small slice of the asset base.
Who checked whether anyone got in first? That is the question the top tier now forces. If an actively exploited flaw sat open on an exposed asset for days, applying the patch closes the door without telling you whether an intruder is already behind it, and answering that is digital forensics work, not patch management.
“It is a Washington directive; my organisation is not bound by it”
All true, and worth conceding at the outset. The obligations fall on US federal civilian agencies alone: immediate policy updates, revised processes within 60 days, full matrix deadlines within 180 days, by around December 2026.
The operational objection cuts deeper. Three days to patch a critical platform sounds unworkable to a team already running at capacity, and anyone who looks after a vCenter or a production ERP knows an urgent patch competes with change windows, regression testing and dependencies that no foreign directive can wish away.
Why it will reach your risk committee anyway
Precedent is the strongest argument here. BOD 22-01's scope also stopped at the US federal government, yet its KEV catalogue ended up as one of the most widely cited prioritisation references in the industry: insurers, auditors and control frameworks lean on it, and it is one of the three references we compared in KEV, EPSS and SSVC: how to prioritise exploitable vulnerabilities. CISA's models travel, with or without jurisdiction.
The speed figures leave the flat deadline little to stand on. Intrusion followed within 48 hours of disclosure in 88% of the cases where a publicly disclosed vulnerability was exploited in the first half of 2026, according to the CrowdStrike 2026 Threat Hunting Report, as covered by Infosecurity Magazine. Zero-day exploitation, meanwhile, grew 42% between 2024 and 2025.
August supplied the case study. QUIRSO, a German security firm, traced exploitation of CVE-2026-59310, a directory traversal flaw in VMware vCenter, to 361 victim IP addresses across 47 countries, and The Hacker News puts the first contacts with attacker infrastructure at five days after Broadcom shipped the patch. We analysed that flaw alongside its two siblings in the three critical vCenter and ESXi flaws in VMSA-2026-0006; the directive turns the lesson into policy, because for an exposed asset under active exploitation a full week is already too long.
Defenders, meanwhile, are moving in the opposite direction. Only 26% of KEV-listed vulnerabilities were fully remediated in 2025, down from 38% the year before, with a median resolution time of 43 days; the figures come from the Verizon 2026 Data Breach Investigations Report, the study CISA itself cites in justifying the directive.
The first public test has already happened. Full matrix compliance is not due until December, but new KEV entries already carry deadlines under the new directive: on 18 August CISA added four flaws to the KEV, one in the Windows IKE service, one in SharePoint, the vCenter flaw above and one in macOS, all scoring between 9.1 and 9.8 on CVSS, and Security Affairs places the agencies' deadline on the 21st. Three calendar days. We had already covered one of the four on this blog: the macOS flaw that hands out root without a password.
NIS2 already asks for vulnerability handling and disclosure in its Article 21; DORA already requires financial entities to manage flaws within their ICT risk framework. What neither hands you is a method, and that is precisely what this matrix is: four objective criteria, public data sources and graduated deadlines, published, free and defensible in front of an auditor, ready to be adapted to your own environment.
Putting the four questions to work on your estate
Copying the exact deadlines misses the point; the criteria are what an auditor will find defensible. Start with the one variable CISA leaves on your side of the table: exposure. An attack surface management programme that keeps the list of internet-reachable assets current turns that first question into a data point and saves an argument at every committee meeting.
Everything else is already published for you: confirmed exploitation lives in the KEV, automation and impact in Vulnrichment, and EPSS fills the gap while a CVE is still outside the catalogue.
Once those sources are in place, define your own tiers. Whether the top window is three days or five matters less than three things: a written rule, deadlines derived from the risk of each asset, and a top tier that includes checking for compromise as well as applying the patch. At Hard2bit we have spent years arguing for that order in our clients' vulnerability management programmes: first know what is exposed, then decide which flaws justify the urgency, and only then talk about tooling.
The evidence trail is the unglamorous piece that holds the rest together when someone questions it, whether that is an auditor today or a post-incident review tomorrow. It should capture every prioritisation decision, the date the CVE entered the KEV, the date the patch was deployed and, at the top tier, the outcome of the forensic triage. With that record in place, a NIS2 or DORA audit stops requiring archaeology.
What staying on a flat deadline costs you
A flat SLA is a tax on your team's best hours. Treat an internal flaw with partial impact the same as a KEV entry granting total control of an exposed asset, and those hours go to flaws that can wait while the urgent one queues. The DBIR numbers show capacity is no longer keeping up: the remediated share of the KEV fell from one year to the next, with the queue growing faster than teams can clear it. When capacity cannot cover everything, allocating it badly is what costs you.
Governance raises the stakes further. Under NIS2, management bodies answer for approving and overseeing risk management measures, as we examined in NIS2 and the board: the accountability directors cannot delegate. A board that signs off one flat patching deadline for everything will struggle to argue diligence when the forensic report shows the exploited flaw spent weeks in the queue, behind dozens of others nobody was exploiting.
The metric worth changing at your next committee meeting
What BOD 26-04 offers a European committee is a better metric. Stop asking how many vulnerabilities are open, a figure that never stops growing, and start asking how many meet the four conditions today, and how quickly they get closed.
None of this makes execution easier: patching a production vCenter inside three days will still hurt, and no matrix changes that. But with CrowdStrike counting nearly nine in ten intrusions against freshly disclosed flaws inside 48 hours, urgency has become a scarce resource, and the matrix spends it where the evidence points. You will also have it in writing why that asset jumped the queue while the other two hundred could wait.
This article analyses a third-country directive and figures from public reports available at the time of publication (August 2026). BOD 26-04 imposes no obligations on organisations outside the US federal civilian scope; references to NIS2 and DORA are indicative and do not constitute legal advice. Check deadlines and requirements against official sources before adapting your patching policy.
