CISA BOD 26-04: Why the 72-Hour Patching Window May Be Too Long

TL;DR

• CISA BOD 26-04, “Prioritizing Security Updates Based on Risk,” requires Federal Civilian Executive Branch agencies to prioritize vulnerability remediation according to actual risk rather than relying on a single severity score or KEV deadline.
• Four variables determine remediation urgency: whether the affected asset is publicly exposed, whether the vulnerability appears in CISA’s Known Exploited Vulnerabilities (KEV) Catalog, whether exploitation can be automated, and the level of control an attacker could obtain.
• The highest-risk vulnerability combinations must be remediated or mitigated within three calendar days. Some of these combinations also require forensic triage within the same period to determine whether exploitation has already occurred.
• Not every vulnerability has a 72-hour deadline. Depending on the combination of risk factors, BOD 26-04 provides remediation timelines of 3, 14, or 60 calendar days, while the lowest-risk cases may wait until the next scheduled major upgrade or rebuild.
• BOD 26-04 supersedes BOD 19-02 and BOD 22-01. The new approach combines asset exposure, known exploitation, exploit automation, and technical impact to determine urgency instead of primarily relying on CVSS severity or KEV deadlines.
• BOD 26-04 is directly binding on FCEB agencies, while federal contractors may become subject to its requirements through applicable contracts or contract modifications. Other organizations can adopt the framework voluntarily.
• Three days should be treated as a maximum deadline rather than an operational target for the highest-risk vulnerabilities. Action1’s 2026 Software Vulnerability Ratings Report found that 28.3% of vulnerabilities with publicly available exploits were attacked within 24 hours of disclosure.
• Patching alone may not be sufficient after exploitation begins. Closing a vulnerability doesn’t establish whether an attacker compromised the system before remediation, which is why BOD 26-04 requires forensic triage for certain high-risk combinations.
• Organizations seeking sub-24-hour remediation need rapid vulnerability identification, prioritization and automated patch deployment. Preconfigured policies and phased update rings can reduce the time between disclosure, testing, deployment and verification.
• Action1 can support a BOD 26-04-aligned workflow by identifying vulnerabilities and affected endpoints, incorporating CVSS and KEV information, automating phased patch deployment through update rings, handling offline endpoints, and providing reporting for remediation verification.

Under the new Binding Operational Directive (BOD 26-04), agencies must prioritize security updates using four risk variables. Vulnerabilities that hit the highest-risk combination must be remediated or mitigated within three calendar days, but agencies must also complete forensic triage within that same period to assess whether the affected systems have been compromised.

If that deadline already puts your team under pressure, real-world exploitation data turns that pressure up even further. Our experts at Action1 recently released the Action1 2026 Software Vulnerability Ratings Report, which highlighted some sobering facts. One such example is that 28.3% of vulnerabilities with publicly available exploits were used in attacks within 24 hours of disclosure. It’s not 72 hours, or 48 hours, but just 24 hours! That single number changes the conversation.

That’s why organizations can’t keep improving their patching strategies at the old pace and call it progress, not if they want to avoid the moment employees turn to their screens and find a ransom note with instructions for contacting the attackers and paying up. Not if they want to avoid watching years of hard work disappear overnight. Not if they want to discover weeks later that a breach had already happened and nobody caught it in time. Once that avalanche starts, the consequences can include regulatory penalties, court cases, reputational damage, and sometimes, business shutdown.

Enough with the bad news. Things aren’t hopeless. Patch management platforms exist specifically to untangle this knot, but before we get into how, let’s first break down what the directive actually requires.

What is CISA BOD 26-04?

CISA BOD 26-04 is a binding federal directive that assigns vulnerability remediation urgency using four variables: asset exposure, KEV status, exploit automation, and technical impact.

Officially titled “Prioritizing Security Updates Based on Risk,” it was issued on June 10, 2026, and requires Federal Civilian Executive Branch agencies to prioritize remediation according to actual risk instead of treating every known exploited vulnerability the same way.

It supersedes and revokes two older directives, BOD 19-02 and BOD 22-01, and consolidates their requirements into a single, clearer framework. The old model was simple: “It’s in the KEV Catalog, patch it by the deadline.” BOD 26-04 asks a more useful question instead: How dangerous is this specific vulnerability, on this specific asset, right now? That means agencies now have to weigh asset exposure, KEV status, exploit automation, and technical impact together, instead of leaning on vulnerability volume or a single severity score to decide what gets fixed first.

Who Must Comply, and Who Should Pay Attention?

That’s one of the most important questions for all of us, so it’s worth being precise about who’s actually required to comply, since this point often gets misread.

We’ll divide organizations into three groups: mandatory scope, contractually conditional scope, and voluntary or indirect relevance.

Mandatory Scope

BOD 26-04 is binding on Federal Civilian Executive Branch agencies and applies to agency assets in any federal information system, as defined under Circular A-130. That includes information systems used or operated by an agency, or by another entity on its behalf, that collect, process, store, transmit, disseminate, or otherwise maintain agency information.

The directive doesn’t apply to statutorily defined national security systems or certain systems operated by the Department of War or the Intelligence Community. Within its defined scope, however, the requirement is mandatory in the fullest, least ambiguous sense of the word.

Contractually Conditional Scope

This one confuses a lot of people, but here’s the truth. Federal contractors aren’t automatically bound by BOD 26-04. But the directive still requires FCEB agencies to review every relevant procurement contract, in consultation with the Contracting Officer, to determine what modifications are needed for compliance. So, whether a contractor ends up obliged to apply BOD 26-04 depends on what their specific contract says, including any modifications the agency makes to bring the directive into that contract, not on the directive alone.

Example 1, Obligated: Say your company hosts an application on an agency’s behalf, or your system touches agency data directly. If your contract includes a clause requiring you to follow applicable federal security directives, or the agency modifies the contract to incorporate BOD 26-04, the new requirements become part of your contractual obligations, and exactly what you have to follow comes down to the contract’s exact language.

Example 2, Not obligated: Say you’re a vendor supplying office furniture, or providing a service that never touches an agency’s information systems. In those cases, your contract likely has no cybersecurity flow-down language attached to it at all, so BOD 26-04 doesn’t affect you. What this shows is that the same federal government and the same directive can produce completely different outcomes, all based on what’s actually written into your contract.

Example 3, Also conditional, through infrastructure, not contract: If your company provides a FedRAMP-certified cloud service offering that hosts a federal information system, the agency must work through the FedRAMP PMO to ensure compliance with the directive. If the offering isn’t FedRAMP-certified, the agency works directly with your company instead, making sure the supporting infrastructure meets the same requirements and that any deviations get documented and communicated back. Either way, the agency stays responsible for keeping an inventory of the hosted systems, staying on top of status updates, and ensuring compliance through collaborative continuous monitoring.

Voluntary or Indirect Relevance

Everyone else falls into a different category:

• State and local government
• Educational institutions
• Critical infrastructure operators
• Private-sector security teams that choose to follow CISA guidance

None of these groups are legally bound by BOD 26-04. But CISA directives have a track record of shaping how the rest of the security world thinks about “good enough,” and this one’s likely to follow that same pattern. If you’re not an FCEB agency and your contract doesn’t incorporate the directive’s requirements, you don’t have to comply.

You might still want to, because it’s a genuinely solid framework, and because auditors, insurers, and customers may view CISA’s guidance as a useful cybersecurity benchmark. More importantly, one of the greatest benefits of adopting risk-based vulnerability prioritization and remediation is that it helps you address the vulnerabilities posing the greatest risk as quickly as possible, reducing your chances of falling victim to cyberattacks.

The Four Risk Criteria Behind BOD 26-04

The directive is clear enough. One severity score isn’t enough anymore. CISA now asks four separate questions about every vulnerability on every asset, not to complicate your remediation workflow, but to help you think strategically in a way that gives you the greatest odds of avoiding an attack that could cost you a fortune or your entire business.

Back to the main topic, let’s see what the four questions actually are.

Is the Affected Asset Publicly Exposed?

If a system with a remotely exploitable vulnerability sits on the public internet, an attacker doesn’t need to phish an employee or compromise another machine first. They can find the exposed asset on their own and go straight for it. Automated internet-wide scanning makes that fast, and Action1’s 2026 Software Vulnerability Ratings Report found that 28.3% of vulnerabilities with publicly available exploits were attacked within 24 hours of disclosure.

That’s how quickly a vulnerability with a public exploit can go from “this vulnerability exists” to “this vulnerability just got exploited.” When the affected asset is also publicly exposed, attackers have one less barrier to overcome, and that’s exactly why CISA treats asset exposure as one of the four variables that determine how urgently you need to act.

Is the Vulnerability Known to be Exploited?

If it’s in CISA’s Known Exploited Vulnerabilities (KEV) catalog, that means CISA has evidence the vulnerability has been exploited in the wild. Every software flaw listed there needs your attention, because there’s enough evidence that it poses a real risk to your network security, not just a hypothetical one.

Can Exploitation be Automated?

Finding a vulnerability and developing a working exploit takes a skilled hacker time and effort. That at least limits how quickly the attack can scale. But the moment every step required to exploit it can be automated, cybercriminals no longer need someone to repeat the process manually against each target. They can use a script to scan for and attempt to exploit exposed systems like yours at scale. That’s the scary gap between “someone might eventually get to you” and “an automated tool may already be looking for systems like yours.”

AI isn’t making things easier for defenders either. CISA warns that attackers’ use of AI may further narrow the time between patch release and possible exploitation. That’s one of the main reasons BOD 26-04 came into the picture. It’s a step in the right direction toward dealing with that problem.

What Level of Control Can the Attacker Obtain?

CISA weighs how much control a successful exploit can give an attacker because a vulnerability that grants total control carries greater urgency than one that grants only partial control, especially when the other risk variables also point to high risk. To connect the dots, we’ve created the table below so you can better understand what separates vulnerabilities, not just on paper but in reality.

A vulnerability that checks all four boxes at once, publicly exposed, listed in the KEV Catalog, automatable, and capable of giving an attacker total control, clearly falls into one of CISA’s most urgent categories. That combination triggers a deadline of three calendar days for remediation or mitigation, along with forensic triage. However, it isn’t the only combination that carries a three-day deadline, and not every three-day combination requires forensic triage.

So, when we say “three calendar days might still be too slow” later in this article, we’re talking specifically about the vulnerabilities in the combinations assigned that deadline. They’re the real elephant in the room. Those are the headline cases, not the whole directive.

How the Four Risk Variables Determine the Remediation Deadline

What actually decides your deadline is how all four answers stack up together for a given vulnerability on a given asset. Mix and match those four yes-or-no answers, and CISA maps the result straight to a timeline. Here’s how that plays out.

What Changed from BOD 19-02 and BOD 22-01?

The changes introduced by BOD 26-04 are more significant than they might appear at first glance. Here’s what we mean:

Looking at the table, you might start thinking that the old approach was never purely severity-based, since agencies already weighed CVSS scores under BOD 19-02 and KEV status under BOD 22-01. And you’d be right. But BOD 26-04 does a lot more than that. It’s the difference between “this CVE has a CVSS score of 9.8, patch it” and “this CVE has a CVSS score of 9.8, the affected asset is exposed to the internet, the vulnerability is listed in the KEV Catalog, exploitation can be automated, and successful exploitation grants total control, so you’ve got three days, not fifteen.

Why 72 Hours May Still Be Too Long

As already mentioned in the article, 28.3% of vulnerabilities with publicly available exploits were attacked within 24 hours of disclosure. So, a 72-hour window can leave you exposed for up to two full days beyond that. But that doesn’t mean you’re next. It just means you have to automate patch deployments and do your best to keep remediation for your most urgent vulnerabilities inside that 24-hour mark. The faster you patch, the better. Going past that window is a risk not worth taking.

• Exploitation can start before your remediation workflow: Disclosure, detection, ticketing, assignment, only then does remediation begin. Every step costs time you don’t have. Hackers just need the vulnerability to exist and be reachable, and increasingly, they’re pairing that speed with AI. In controlled research, Claude Mythos Preview has already shown what that combination can do, autonomously finding and, in many cases, exploiting zero-days, including an OpenBSD bug that sat undetected for 27 years.

• Your internet-facing assets may already be under attack: Some newly disclosed vulnerabilities get weaponized almost immediately. Even a single internet-facing endpoint running a vulnerable OS or third-party app can be the start of a full-blown security incident.
• A patch doesn’t prove your system is clean: Deploying a patch closes the vulnerability, but it can’t tell you whether someone already got in through it. That’s exactly why some three-day combinations also require forensic triage. The agency has to check the affected system for signs of compromise within those same three calendar days. “Patched” and “safe” aren’t the same thing.
• Treat the deadline as your ceiling, not your target: Three calendar days is CISA’s maximum for the most urgent combinations, not a benchmark to aim for. Set your own internal clock well inside that window, with faster identification, faster containment, faster remediation, and faster forensic triage. That gives your team enough room to deal with failures or unexpected issues before the deadline expires.

How Action1 Can Help You Turn a 72-Hour Deadline into Sub-24-Hour Remediation?

Action1 is a cloud-native endpoint management platform that turns patch management into a fully autonomous process. Once agents are installed across your endpoints, they identify known vulnerabilities and missing updates across Windows, macOS, Linux, and supported third-party applications, then show you exactly which systems are affected.

But finding a flaw is only useful if you know how dangerous it actually is. Action1 doesn’t lean on a single vulnerability feed the way a lot of platforms do. It pulls data from VulnCheck NVD++, NIST NVD, CISA’s KEV Catalog, Microsoft’s own MSRC data, and vendor release notes, then scores each vulnerability from 1 to 10 based on CVE data, CVSS severity, CISA KEV status, and known usage in ransomware campaigns. That’s your initial prioritization done in minutes.

Once you know what needs attention first, the next question is obvious. How does that turn into remediation inside 24 hours instead of using the full three-calendar-day window? Through a feature called update rings. It enables phased, autonomous rollouts in which updates advance from an inner testing ring to wider ones based on the thresholds you define. You decide how many rings you need, what thresholds an update must meet before moving on, and when endpoints should reboot. Once the rollout starts, only updates that meet those “success criteria” advance automatically to the next ring. The rest don’t.

That stability check itself has a dial on it too. The validation period between rings isn’t fixed. Action1 defaults to a cautious 7-day soak, but you can dial it down to hours or even minutes for an urgent patch deployment. Just know the tradeoff. A shorter window still runs the same checks. It just gives problems less time to surface before the update reaches more endpoints.

The same workflow holds at any scale. Whether you’re managing 10 endpoints or 100,000+, across hybrid, on-premises, or fully remote environments, the automated sequence remains the same.

Another advantage of Action1 is that every patch comes from a secure, privately maintained software repository, so each update rolled out to your endpoints has already been vetted, not pulled from a community-maintained catalog. Additionally, the platform uses P2P distribution for faster deployments and minimal bandwidth consumption, downloading a given update once and sharing it across the rest of the endpoints on the same local network, instead of each one pulling it down separately.

To avoid gaps in coverage, offline endpoints are handled just as reliably. If a device misses a deployment because it’s offline, Action1 automatically installs the updates once it reconnects within the configured retry window.

Last but not least, none of this is worth anything if you can’t prove it happened. Action1 comes with 100+ built-in, customizable reports covering patching, vulnerabilities, software and hardware inventory, and security configuration. Those reports use real-time data from connected endpoints and cached data for anything currently offline. After every successful deployment, you can generate audit-ready documentation in minutes, so when an audit comes around, the evidence is already there.

That’s the toolkit. Here’s what it actually looks like once the clock starts ticking:

• Before hour 0: Action1 is deployed across all your endpoints, you’ve configured your emergency patching policy, update rings are set, success metrics are defined, reboots are planned, and you’ve established an offline endpoint catch-up window.
• Hours 0 to 2: Action1 has already identified the vulnerability, mapped it to the affected endpoints, and surfaced the CVSS score, KEV status, exploit automation, and technical impact data CISA already publishes for that CVE. Your team’s only remaining input is confirming public exposure for the asset. From there, your team selects the vulnerability and launches the preconfigured emergency patching workflow.
• Hours 2 to 4: Deployment starts in the testing ring, which contains only a small number of your systems.

• Hours 4 to 8: If the update meets your predefined success metrics and deployment counts, it progresses to the next ring of endpoints, also known as the pilot ring. Action1 continues to track success and failure rates throughout.

• Hours 8 to 20: The update gets deployed across the rest of the rings you’ve created, with the goal of reaching every available affected endpoint across your environment. All of that happens automatically. Your team can monitor the process closely, but it isn’t required to approve each stage. If the patch is stable, it just gets deployed to more and more endpoints using P2P patch distribution, which additionally accelerates the process.
• Hours 20 to 24: Your team verifies the deployment results, reviews any failed installations, resolves the cause, and reruns the update where appropriate. Systems that still can’t be patched get a documented mitigation instead, with every unresolved case tracked and assigned for follow-up until the vulnerability is remediated. All of this runs off Action1’s real-time reporting, which also keeps offline endpoints queued to receive the update automatically once they reconnect within the configured retry window.

By hour 24, every reachable affected endpoint targeted by this workflow should be remediated or subject to a documented mitigation, every unresolved device should be visible and owned, and your team should know exactly what still needs to happen. That is how Action1 helps turn the three-calendar-day deadline into a safety buffer instead of a deployment plan.

P.S. Keep in mind that this is one way to configure it, not the only way. If your priority shifts toward testing accuracy over speed, minimizing disruption risk, or giving a patch more time to prove itself stable, you can widen those validation windows the same way you can narrow them. Action1 lets you build as many automations as you need, for different departments, different maintenance windows, different risk tolerances, so this 24-hour sequence is a starting point you shape around what actually matters to your environment, not a fixed script.

Frequently Asked Questions about CISA BOD 26-04

What is CISA BOD 26-04?

CISA BOD 26-04 is a binding directive, issued June 10, 2026, requiring Federal Civilian Executive Branch agencies to prioritize vulnerability remediation using a four-variable risk model: asset exposure, KEV status, exploit automation, and technical impact, instead of treating every vulnerability the same way.

Does BOD 26-04 Require All Vulnerabilities to be Patched in 72 Hours?

No. The three-calendar-day window applies only to the directive’s most urgent combinations of asset exposure, KEV status, exploit automation, and technical impact. Other combinations receive longer timelines, and the lowest-priority cases can be deferred until the system’s next scheduled major upgrade or rebuild. Some, but not all, three-day combinations also require forensic triage.

What are the Four BOD 26-04 Risk Criteria?

The four BOD 26-04 risk criteria are:

• Asset exposure (is it reachable from the public internet)
• KEV status (is it in CISA’s KEV Catalog)
• Exploit automation (can an adversary automate all the steps necessary to exploit it)
• Technical impact (how much control could a successful attack grant).

Does BOD 26-04 Apply to Private Companies?

No, it’s directly binding only on Federal Civilian Executive Branch agencies. Contractors and cloud providers may still acquire obligations through their governing contracts or through work supporting an in-scope federal information system. State and local governments, educational institutions, critical infrastructure operators, and other private-sector organizations aren’t otherwise required to comply, though they may choose to use it as voluntary guidance.

Why Does BOD 26-04 Require Forensic Triage for Some Three-Day Cases?

Because patching closes a vulnerability, but it doesn’t confirm whether an attacker already exploited it. Forensic triage checks whether a system was compromised before the fix was deployed, which a patch alone can’t tell you.

About Action1

Action1 is an autonomous endpoint management platform that is cloud-native, infinitely scalable, highly secure, and configurable in 5 minutes—it just works and is always free for the first 200 endpoints, with no functional limits. By pioneering autonomous OS and third-party patching – AEM’s foundational use case – through peer-to-peer patch distribution and real-time vulnerability assessment without needing a VPN, it eliminates costly, time-consuming routine labor, preempts ransomware and security risks, and protects the digital employee experience. Trusted by thousands of enterprises managing millions of endpoints globally, Action1 is certified for SOC 2 and ISO 27001.

The company is founder-led by industry veterans Alex Vovk and Mike Walters, American entrepreneurs who founded Netwrix, which has grown into a multi-billion-dollar industry-leading cybersecurity company.