8 minute read

What is BOD 26-04? CISA's risk-based patch deadlines, explained

BOD 26-04 is the CISA directive that sets how fast US federal agencies must fix each vulnerability. It replaced CVSS-based deadlines with four questions about the asset and the exploit, and the deadlines move when the answers change.

Key takeaways

  • CISA issued BOD 26-04 on 10 June 2026. It binds US federal civilian agencies and revokes BOD 19-02 and BOD 22-01.
  • Four questions set each deadline: is the asset publicly exposed, is the CVE in KEV, can an attacker automate the exploit, and does it give partial or total control.
  • Deadlines are 3, 14, or 60 days, or the next system upgrade. The worst cases also need a forensic triage to check whether the system is already compromised.
  • A deadline can change after it starts. Taking an asset off the internet moves it back, and a new KEV listing moves it forward.

What is BOD 26-04?

Binding Operational Directive (BOD) 26-04, "Prioritizing Security Updates Based on Risk," is a directive from CISA, the US Cybersecurity and Infrastructure Security Agency. CISA issued it on 10 June 2026. It tells federal civilian agencies how fast to fix each vulnerability on their systems, based on the risk to that asset.

CISA's stated reason is speed: attackers' use of AI "may further narrow the time defenders have to react." The directive gives the shortest deadlines to the highest-risk combinations and lets agencies defer low-risk vulnerabilities.

Who BOD 26-04 applies to

BOD 26-04 binds Federal Civilian Executive Branch (FCEB) agencies. It does not cover national security systems. Contractors are covered only where their contract says so. Cloud services sold to agencies follow it through FedRAMP, which made its vulnerability rules mandatory for cloud services from 7 December 2026.

What BOD 26-04 replaced: BOD 19-02 and BOD 22-01

Before June 2026, two directives set federal patch deadlines. BOD 19-02 (2019) gave internet-facing systems 15 days for critical and 30 days for high vulnerabilities, based on CVSS severity. BOD 22-01 (2021) created the KEV catalog and gave each entry a fixed due date.

BOD 26-04 revoked both. CISA says that federal agencies are no longer required to use CVSS to prioritize vulnerabilities. The KEV catalog continues with the same entry criteria, and CISA now calculates each KEV due date from the BOD 26-04 table.

The four BOD 26-04 decision points

Decision pointQuestionValuesWho answers it
Publicly exposedCan someone outside the agency network reach the vulnerable asset?Yes or noThe agency, asset by asset
In the KEV catalogHave attackers exploited the vulnerability, or tried to?Yes or noCISA
Automatable by an adversaryCan an attacker automate every step of the exploit?Yes or noCISA, through its Vulnrichment program
Technical impactDoes exploitation give partial or total control of the asset?Partial or totalCISA, through its Vulnrichment program

CISA publishes three of the four answers for each CVE. When CISA has no data for a CVE that is not in KEV, agencies treat it as not automatable with total impact. The fourth answer, exposure, is about the agency's own assets, so only the agency can give it.

The decision points come from SSVC (Stakeholder-Specific Vulnerability Categorization), and CISA publishes the decision table in machine-readable form in the CERT/CC SSVC repository on GitHub.

BOD 26-04 remediation timelines

Find the row for the asset and whether the CVE is in KEV, then the column for the exploit. Deadlines are in calendar days. They are maximums, and agencies can set shorter ones.

AssetAutomatable, total controlAutomatable, partial controlNot automatable, total controlNot automatable, partial control
Exposed, in KEV3 days and forensic triage3 days3 days and forensic triage14 days
Exposed, not in KEV3 days14 days14 days60 days
Internal, in KEV3 days and forensic triage14 days14 days14 days
Internal, not in KEV60 days60 daysNext system upgradeNext system upgrade

The clock starts when CISA adds the vulnerability to KEV or when the agency finds it on an asset, whichever comes first.

What forensic triage means under BOD 26-04

For the three worst combinations, the agency must fix the vulnerability and also check whether attackers already used it to get into the system. CISA's implementation guidance suggests six steps in about 72 hours: scope the affected assets, preserve evidence, patch, contain, analyze the evidence, and decide whether to escalate. A confirmed compromise goes to CISA as an incident report.

BOD 26-04 deadlines change when the facts change

A BOD 26-04 deadline can move after the clock starts. If the agency takes the asset off the internet, the deadline moves back. If CISA adds the CVE to KEV, the deadline moves forward. A vulnerability deferred to the next upgrade gets 14 days as soon as CISA adds it to KEV.

Every deferral rests on facts like these. For how to catch them when they change, read how to re-prioritize vulnerabilities when the risk changes.

BOD 26-04 compliance dates

  • From 10 June 2026. Update vulnerability management policies, monitor the KEV catalog, and report KEV status through the CDM dashboard, or by hand every two weeks.
  • Within 60 days. Update processes to fix vulnerabilities on an ongoing basis from the CVE database and the KEV catalog.
  • Within 180 days, by 7 December 2026. Meet the remediation deadlines, and tag every asset that can be reached from outside the agency network.

CISA does not give waivers or exceptions for directive actions.

What BOD 26-04 means if you are not a federal agency

Most companies are not bound by BOD 26-04, but the model is public and free to use. The three questions CISA answers come with each CVE. The hard one is exposure: you need an up-to-date answer, for each asset, to whether it can be reached from the internet. A program that ranks by CVSS never needed that answer.

The model also only covers CVEs. Bugs in your own code never get a KEV entry, but three of the four questions still work for them. For how to apply them, read what the CISA KEV catalog is, and why your own code is never in it.

aisy investigates every ticket to learn how your company works, including which systems face the internet and who owns them. When a finding arrives, the answers BOD 26-04 asks for are already there.

Frequently asked questions

BOD 26-04, "Prioritizing Security Updates Based on Risk," is a CISA Binding Operational Directive issued on 10 June 2026. It sets the deadline for each vulnerability fix in US federal civilian agencies from four questions: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether an attacker can automate the exploit, and whether exploitation gives partial or total control.

Agencies have 3, 14, or 60 calendar days, or can fix the vulnerability at the next scheduled system upgrade. The worst cases, a KEV vulnerability with total control that is also exposed or automatable, get 3 days and a forensic triage to check whether the system is already compromised. The deadlines are maximums.

Some actions were effective immediately on 10 June 2026, such as monitoring the KEV catalog and updating vulnerability management policies. Agencies had 60 days to update their processes, and must meet the remediation deadlines and tag every externally reachable asset within 180 days, by 7 December 2026.

Not directly. It binds US federal civilian agencies. Contractors are covered only where their contract says so, and cloud services sold to agencies follow it through FedRAMP. Any company can use the same four questions, because CISA publishes the decision table.

No. BOD 26-04 revoked BOD 19-02, which set deadlines from CVSS severity, and CISA says federal agencies are no longer required to use CVSS to prioritize vulnerabilities. Technical impact, one of the four questions, is close to the CVSS idea of severity.

It revoked two directives: BOD 19-02 (2019), which set CVSS-based deadlines for internet-facing systems, and BOD 22-01 (2021), which created the KEV catalog and its fixed due dates. The KEV catalog continues, and CISA now calculates KEV due dates from the BOD 26-04 table.

Shlomie Liberow, founder of aisy

Vulnerability management that learns.

Bring a recurring problem from your security backlog. We’ll look at what your team already knows, what it keeps re-checking, and how to get ahead of it.

Shlomie Liberow · Founder, aisy · shlomie@aisy.ai