CISA's newest directive gives US federal agencies about three days to fix the most dangerous flaws. Binding Operational Directive 26-04 came out on 10 June 2026. It replaces the fixed deadlines in the old BOD 22-01 for fixing Known Exploited Vulnerabilities with a system based on risk. The riskiest flaws get about three calendar days, plus a check for signs of a break-in.
Four things decide how urgent a flaw is: whether the system is exposed to the internet, whether the flaw is on the KEV list, whether attackers can automate it, and how much damage it does. September's batches of KEV flaws are already being sorted under the new rules.
Here's what changed. Under BOD 22-01, federal civilian agencies treated anything on the KEV list as roughly equally urgent. BOD 26-04, titled "Prioritizing Security Updates Based on Risk," keeps the KEV list at the centre but adds context. Is the system open to the internet? Is the flaw on the KEV list? Can an attacker automate it? Does a successful attack give total control, or only partial? The answers put each fix into a deadline band. The bands include three days, fourteen days, sixty days, and, for the lowest-risk cases, fixing it at the next major upgrade.
The top band needs careful wording. Some combinations, especially a KEV flaw that gives total control, and the worst mixes of internet exposure and automation, must be fixed within three calendar days. For some of those, agencies also have to check whether the system was already broken into. CISA's guide to the directive spells out what a proper check looks like. Patch it or work around it, check for an earlier break-in, and write it down. That's the job.
When the clock starts matters. Reporting on BOD 26-04 says it can start when CISA adds a flaw to the KEV list or when the agency finds the flaw on one of its systems, whichever comes first. Deadlines can also change. Take a service off the open internet and its band can move. That's why keeping an accurate list of your systems and what's exposed isn't busywork. It's how you avoid getting stuck in the three-day band by accident.
September's KEV batches are the first real test. When CISA added groups of exploited flaws in September 2026, federal teams, and anyone copying their approach, had to run each one through the BOD 26-04 questions. They couldn't just assume one due date out of habit from BOD 22-01. Explainers from Zafran, Shattered.io and security company blogs have been translating the new table for people doing the work.
You don't need attack steps, payloads or a lab copy of a flaw to do any of this. Flaw names and CVE numbers are enough to decide what to fix first. Vendors' fixed versions and settings changes are enough to fix it. If an auditor wants proof, show them version numbers, KEV entries, exposure flags and change tickets, not a crash demo.
Here are the numbers. BOD 26-04 came out on 10 June 2026. It replaces BOD 22-01's fixed KEV deadlines, and it also scraps the older BOD 19-02. The top band gets about three calendar days, plus a break-in check for certain cases. The four questions are exposure, KEV, automation and impact. The lower bands are 14 days, 60 days, and fix at upgrade.
Who has to follow it, and who should copy it? The directive only binds Federal Civilian Executive Branch agencies. Everyone else still answers to insurers, boards and customers, and they'll treat a three-day fix for the worst internet-facing KEV flaws as the grown-up standard. Copy the way it ranks risk. Just don't pretend CISA's enforcing it on you if it isn't.
Here's a practical routine. Check what's new on the KEV list every day, or close to it. Keep a list of your systems that can say whether each one faces the internet without a week of meetings. Mark whether flaws can be automated and how bad they are, using CISA's definitions or an SSVC-style process your security chief has signed off. When a September batch lands, sort the tickets by band before you sort them by CVSS score. Explainers stress that CVSS scores aren't what BOD 26-04's risk model runs on.
Checking for a break-in doesn't need to be a show. The three-days-plus-check cases exist because patching a system someone's already broken into, without looking, just paints over the problem. A check means looking for signs of a break-in that suit that kind of system, following CISA's guidance. It doesn't mean running an attack to "prove" the flaw works. If you do find a break-in, you're dealing with an incident now, not just a patch job.
We've also got how-to guides on this. One shows how to check your systems against the KEV feed. Another walks through checking the feed first, using a Chromium example. Those guides cover the checklist. The directive is about why the deadlines changed, and what "three days on the worst" really means.
Here's where teams go wrong. Some treat every KEV flaw as a three-day job. That brings back the one-size-fits-all approach of BOD 22-01 and burns people out. Others relax about flaws that aren't on the KEV list, even when the system is exposed, attackers can automate it and it gives total control. The table can still demand short deadlines for some of those. Some ignore old systems because they're ugly. And deadlines that can change only help if someone updates the exposure flags when a system goes on or off the internet.
Ask your vendors and security providers the right questions. Can their tools label exposure, KEV status, whether attacks can be automated and how bad the damage is, in a way that matches BOD 26-04's bands? A pretty CVSS dashboard isn't a BOD 26-04 dashboard. September's batches will catch out teams whose ticket systems still say "critical = 15 days" for everything.
For federal program managers, the order of steps in the directive matters. CISA's BOD 26-04 text has agencies update their policies first. Then they update their processes so they can take in full CVE and KEV data. Then they fix flaws on the table's deadlines. There are also sign-off and basic security duties that sit alongside the table. Read the steps in CISA's directive itself, not on a slide that squashes them together.
If you're outside the US, three calendar days is the American federal civilian standard for the worst cases. Your regulator might set something different. The idea worth borrowing is fixing flaws by risk, based on real attacks and exposure, not just how scary a severity score looks. Australian and allied security teams that follow the KEV list already know it well. BOD 26-04 is a smarter way to rank what's on it.
So CISA's BOD 26-04, from 10 June 2026, swaps BOD 22-01's fixed KEV deadlines for deadlines based on risk. They're set by exposure, KEV status, whether attacks can be automated, and impact. The top band is about three calendar days, with a break-in check for certain cases. September's KEV batches run under the new rules. Patch the worst first, and check for break-ins when the directive says to.
For more, read about the seven flaws CISA added to the KEV list, the Chromium flaw that hit the KEV list and how to read the KEV list before you patch.






The paper
Comments
No notes on this story yet.
Sign in to comment