US Edition Austin, TX UTC 00:00:00

CISA BOD 26-04 explained: the new KEV remediation timelines

BOD 26-04 replaced BOD 22-01 on June 10, 2026. All 16 remediation timelines, forensic triage steps, KEV due dates and the December 7, 2026 deadline.

BOD 26-04 is the binding operational directive CISA issued on June 10, 2026 to replace BOD 22-01 and BOD 19-02. It changes how fast US federal civilian agencies must fix vulnerabilities: instead of a default two-week deadline for most entries in the Known Exploited Vulnerabilities (KEV) catalog, four yes-or-no questions now produce a deadline of 3, 14 or 60 calendar days, or "fix on system upgrade", and the same rules now cover vulnerabilities that are not in KEV. Agencies must meet those timelines within 180 days of issuance, which falls on December 7, 2026.

The rules below are taken from the directive text and CISA's implementation guidance (updated August 25, 2026), as of October 2026.

What BOD 26-04 replaced

Two older directives were revoked on the day BOD 26-04 was published:

  • BOD 22-01 (November 3, 2021) created the KEV catalog and required agencies to remediate listed vulnerabilities within two weeks, or within six months for CVE IDs assigned before 2021, unless CISA set a different date.
  • BOD 19-02 (April 29, 2019) required critical vulnerabilities on internet-accessible systems to be fixed within 15 calendar days of detection and high vulnerabilities within 30 days, based on CISA Cyber Hygiene scans.

The KEV catalog itself stays, and CISA's criteria for adding an entry are unchanged: an assigned CVE ID, reliable evidence of active exploitation, a clear remediation such as a vendor update, and significant risk to federal systems. What changed is how a KEV listing turns into a deadline, and the fact that vulnerabilities outside KEV now get deadlines too.

The four decision points

Every vulnerable asset is assessed on four variables, each with a binary answer:

  1. Publicly exposed. Yes if the asset can be reached by unauthenticated or untrusted parties over a public network such as the internet, wherever it physically sits. If any of the overlapping discovery methods finds the asset exposed, the answer is yes.
  2. In the KEV. Yes if the CVE ID has an entry in the KEV catalog.
  3. Automatable. Yes if an adversary can automate every step needed to exploit the flaw. CISA's rule of thumb: a public proof of concept that reliably achieves remote code execution makes a vulnerability automatable.
  4. Technical impact. Total control if exploitation gives the attacker full control over the vulnerable software, including flaws that reliably reveal login credentials (CISA names Heartbleed and Citrixbleed as examples). Partial control covers everything else; the directive explicitly counts denial of service as partial control.

CISA publishes KEV status, Automatable and Technical Impact for CVE records as an Authorized Data Publisher through its Vulnrichment program, using definitions from the SSVC decision model. Exposure is the one value each organization must determine from its own asset inventory. If no metadata exists yet for a CVE that is not in KEV, CISA treats it as not automatable with total impact until data is published.

BOD 26-04 remediation timelines: all 16 combinations

Table 1 of the directive lists every combination of the four answers. Grouped by deadline, it reads as follows.

3 calendar days plus forensic triage

  • Publicly exposed, in KEV, automatable, total control.
  • Publicly exposed, in KEV, not automatable, total control.
  • Not exposed, in KEV, automatable, total control.

3 calendar days

  • Publicly exposed, in KEV, automatable, partial control.
  • Publicly exposed, not in KEV, automatable, total control.

14 calendar days

  • Publicly exposed, in KEV, not automatable, partial control.
  • Publicly exposed, not in KEV, automatable, partial control.
  • Publicly exposed, not in KEV, not automatable, total control.
  • Not exposed, in KEV, automatable, partial control.
  • Not exposed, in KEV, not automatable, total control.
  • Not exposed, in KEV, not automatable, partial control.

60 calendar days

  • Publicly exposed, not in KEV, not automatable, partial control.
  • Not exposed, not in KEV, automatable, total control.
  • Not exposed, not in KEV, automatable, partial control.

Fix on system upgrade

  • Not exposed, not in KEV, not automatable, with either total or partial control.

Three patterns stand out. No KEV entry ever gets more than 14 days. A vulnerability that is not yet in KEV can still carry a 3-day deadline if it sits on an exposed asset, is automatable and gives total control. And "fix on system upgrade" means the flaw can wait for the asset's next scheduled major upgrade or rebuild, unless the facts change.

When the clock starts and why deadlines move

The timeline begins at whichever happens first: CISA adds the CVE to the KEV catalog, or the agency identifies the vulnerability on an asset and records it in the Continuous Diagnostics and Mitigation (CDM) dashboard under BOD 23-01. Days are calendar days, and remediation can mean patching, decommissioning the system or another action that eliminates the vulnerability.

Deadlines are dynamic. Taking a system off the internet changes "publicly exposed" from yes to no and pushes the deadline back. CISA adding the CVE to KEV shortens it.

What "forensic triage" requires

For the three highest-risk combinations, agencies must remediate within three days and also check whether the asset was already compromised. The implementation guidance sets out six steps, with recommended target times counted from the KEV addition:

  1. Scoping, within the first two hours.
  2. Preserving and collecting evidence, starting with volatile data such as memory, within 2 to 24 hours.
  3. Critical patching and stabilization, within 2 to 24 hours, once the evidence has been collected.
  4. Containment and control, within 6 to 24 hours.
  5. Triage analysis for unauthorized access, persistence, lateral movement and data exfiltration, within 24 to 48 hours.
  6. An escalation decision backed by a written triage report, within 48 to 72 hours.

CISA says these targets are recommended practice; the binding requirement is that an adequate triage is performed. A confirmed compromise is reported to CISA through its incident reporting system and can escalate into full incident response.

How to read the KEV "dueDate" field now

The KEV catalog still shows a due date for each entry. Under BOD 26-04, CISA calculates it from Table 1 using the exposure evidence it has. If CISA determines the vulnerable product sits on a publicly exposed asset and the flaw is automatable with total impact, the due date reflects three days. Agencies make the final exposure call asset by asset, so the same CVE can carry different deadlines on different systems.

Key dates for agencies and cloud providers

  • Immediately (June 10, 2026): update vulnerability management policies, monitor KEV additions and report KEV status through CDM, with bi-weekly manual reports where reporting is not automated.
  • Within 60 days: update processes so remediation is driven by the CVE database and the KEV catalog.
  • Within 180 days (December 7, 2026): meet the Table 1 timelines and tag every externally reachable asset by agency, environment, exposure and asset type.

FedRAMP said in public notice NTC-0014 that its Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules become mandatory for certified cloud services on December 7, 2026, with a grace period under a corrective action plan through March 7, 2027. According to FedRAMP, providers that follow those rules meet the expectations of BOD 26-04.

Does BOD 26-04 apply to private companies?

No. Binding operational directives apply to Federal Civilian Executive Branch systems. They exclude national security systems and certain Department of War and intelligence community systems, and they reach contractors only when a procurement contract says so. Agencies stay responsible for their systems hosted by FedRAMP and other cloud providers.

The data behind the directive is public, though, which makes the model easy to reuse. Teams outside government that want to follow it can:

  • keep an inventory that records which assets are reachable from the internet;
  • pull KEV status, Automatable and Technical Impact from CVE records instead of relying on a CVSS base score alone;
  • subscribe to KEV catalog updates and treat a KEV entry on an exposed asset as an emergency change;
  • define what a forensic triage looks like for their own incident response team before they need one.

The implementation guidance points out that by revoking BOD 19-02, federal agencies are no longer required to use CVSS for prioritization, and it cites the CVSS v4.0 user guide, which says base scores measure severity and should not be used alone to assess risk. New KEV additions and their deadlines are covered daily in Kernelwire's vulnerabilities section, and confirmed intrusions in our breaches coverage.

Frequently asked questions

What is the BOD 26-04 deadline for a KEV vulnerability?

It depends on exposure, automatability and technical impact: 3 calendar days for the riskiest combinations, with forensic triage added when the attacker gains total control, and 14 days for the rest. No KEV entry gets more than 14 days.

Did BOD 26-04 replace BOD 22-01?

Yes. CISA revoked BOD 22-01 and BOD 19-02 on June 10, 2026, the day BOD 26-04 was issued. The KEV catalog and its inclusion criteria continue unchanged.

When must federal agencies comply with BOD 26-04?

Policy updates were due immediately and process updates within 60 days. The Table 1 remediation timelines apply within 180 days of issuance, which is December 7, 2026.

Does BOD 26-04 apply to private companies or contractors?

Not directly. It binds federal civilian agencies, and contractors only when their contract requires it, but FedRAMP-certified cloud providers must follow FedRAMP rules aligned with it from December 7, 2026.

Where can I check whether a CVE is automatable?

CISA publishes Automatable and Technical Impact values, along with KEV status, in CVE records through its Vulnrichment program. The same data is available in the cisagov/vulnrichment repository on GitHub.