On 10 June 2026 CISA issued Binding Operational Directive 26-04, whose background section states that it "supersedes and hereby revokes BOD 19-02: Vulnerability Remediation Requirements for Internet-Accessible Systems (April 29, 2019), and BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities (Nov. 3, 2021)."
If your remediation SLA, retest window or customer contract cites a KEV deadline, it now cites a revoked directive. This post recomputes what changed from CISA's published catalog, then works through what breaks in a testing programme and what to rewrite.
What BOD 26-04 revoked, and why the 15-day KEV deadline is a stale citation
Two numbers circulate in vulnerability-management documentation, and both trace to directives that no longer exist.
The 15-day number came from BOD 19-02. That directive required that "Critical vulnerabilities must be remediated within 15 calendar days of initial detection" and high vulnerabilities within 30 calendar days, on internet-accessible systems flagged by CISA's Cyber Hygiene scanning. Its page now reads: "This Directive has been revoked. It is superseded by BOD 26-04."
The 14-day number came from BOD 22-01. That directive created the KEV catalog and set default timelines of "within 6 months for vulnerabilities with a Common Vulnerabilities and Exposures (CVE) ID assigned prior to 2021 and within two weeks for all other vulnerabilities." Its page carries the same revocation banner.
A third casualty gets almost no attention. BOD 19-02 made CVSS severity the federal prioritization currency, and CISA's implementation guidance says so plainly: "By revoking BOD 19-02, the FCEB no longer requires CVSS use for vulnerability prioritization." If your policy sorts work into Critical, High, Medium and Low and attaches a clock to each bucket, the federal reference model it was copied from no longer works that way.
BOD 26-04 binds federal civilian executive branch agencies. Its scope section says that, unless directed by the governing procurement contract, it does not apply to contractors, though agencies "must review all contracts to determine what modifications are necessary to comply with the required actions of this Directive." That clause is why this matters commercially even if you never sell to government: the language propagates through procurement.
CISA's stated reason for compressing timelines is worth noting for anyone writing an AI risk register. The background text says threat actors exploit unpatched vulnerabilities and that "their use of AI may further narrow the time defenders have to react between patch release and possible exploitation."
The four variables that now set your clock, including the deferral tier
BOD 26-04 replaces severity labels with a decision table informed by the Stakeholder-Specific Vulnerability Categorization model. Four variables decide the deadline: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether exploitation is automatable by an adversary, and whether technical impact is partial or total control. CISA supplies the last three through the KEV catalog and its Vulnrichment programme; the agency supplies exposure. Publicly exposed means any agency-owned or agency-managed IT resource "accessible to unauthenticated or untrusted entities via public networks, such as the internet, regardless of its physical or logical location", and total control means the exploit gives the adversary total control over the software's behaviour, "including if the exploit reliably reveals log-in credentials."
Those four inputs produce sixteen combinations. This is Table 1 of the directive in full.
Row | Publicly exposed | In KEV | Automatable | Technical impact | Remediation timeline |
|---|---|---|---|---|---|
1 | Yes | Yes | Yes | Total | 3 days and forensic triage |
2 | Yes | Yes | Yes | Partial | 3 days |
3 | Yes | Yes | No | Total | 3 days and forensic triage |
4 | Yes | Yes | No | Partial | 14 days |
5 | Yes | No | Yes | Total | 3 days |
6 | Yes | No | Yes | Partial | 14 days |
7 | Yes | No | No | Total | 14 days |
8 | Yes | No | No | Partial | 60 days |
9 | No | Yes | Yes | Total | 3 days and forensic triage |
10 | No | Yes | Yes | Partial | 14 days |
11 | No | Yes | No | Total | 14 days |
12 | No | Yes | No | Partial | 14 days |
13 | No | No | Yes | Total | 60 days |
14 | No | No | Yes | Partial | 60 days |
15 | No | No | No | Total | Fix on system upgrade |
16 | No | No | No | Partial | Fix on system upgrade |
Four things there contradict how most private-sector policies are written.
A three-day clock is not KEV-exclusive. Row 5 has no KEV entry at all. An internet-facing asset with an automatable, total-control flaw gets 72 hours whether or not CISA has catalogued exploitation. Policies that key urgency purely off KEV membership will miss this row.
There is no 21-day tier. The tiers are 3, 14, 60 and deferral. Any document referencing a 21-day KEV window describes catalog behaviour that ended in June.
Internal is not automatically slow. Row 9 puts a non-exposed asset on the same 72-hour clock with forensic triage, because KEV plus automatable plus total control is treated as decisive regardless of exposure.
There is an explicit deferral tier. Rows 15 and 16 read "fix on system upgrade", which the directive defines as remediation "the next time the vulnerable asset receives a scheduled major upgrade or rebuild". CISA's implementation guidance is blunter: "For items with the 'fix on system upgrade' timeline, agencies do not need to prioritize these vulnerabilities and can wait for the next system upgrade." A risk-tiered model that only compresses the top is not the model CISA published; it compresses the top and formally defers the bottom.
Three mechanics are worth copying into your own policy. If exposure information is unavailable, CISA treats the asset as publicly exposed. If CVE metadata is unavailable and the CVE is not in KEV, the timeline defaults to 60 days. The clock starts at whichever comes first, CISA adding the vulnerability to KEV or the agency enumerating it on an asset under BOD 23-01, and days are calendar days.
The numbers, recomputed from CISA's own catalog
The catalog is a published JSON feed, so the directive's effect is measurable rather than editorial. The figures below come from catalogVersion 2026.08.07, released 7 August 2026, taking each entry's due date minus its date added.
Remediation window on the entry | Added 1 Jan to 9 Jun 2026 | Added 10 Jun to 7 Aug 2026 |
|---|---|---|
2 days | 2 | 0 |
3 days | 31 | 40 |
5 days | 1 | 0 |
14 days | 55 | 5 |
21 days | 44 | 0 |
Total entries | 133 | 45 |
Before the directive, 31 of 133 new entries carried a three-day deadline, or 23 percent. After it, 40 of 45 do, or 89 percent. The median window on a new KEV entry moved from 14 days to 3.
Two cautions. The buckets are not exhaustive: the pre-window set also holds two entries at 2 days (both Cisco SD-WAN records added 25 February 2026) and one at 5 days (Drupal Core, 22 May 2026), so the three headline tiers sum to 130 of 133. And five entries added after 10 June still carry 14 days, including Microsoft Active Directory Federation Services CVE-2026-56155 and Cisco Catalyst SD-WAN Manager CVE-2026-20262, exactly as Table 1 predicts for partial-control or non-automatable combinations.
The 2025 baseline makes the change starker: of 245 entries added that year, 226 carried a 21-day window. The tier that dominated the catalog last year no longer exists.
Every vulnerability named in this post is a Category C event: a product vulnerability in third-party software, disclosed and patched. Stating categories explicitly matters because 2026 coverage routinely blends them. A is a jailbreak, a guardrail bypass with nothing accessed. B is platform misuse, an external attacker using a product against third parties. C is a product vulnerability. D is a corporate breach of the vendor itself. E, which we define here because the other four do not cover it, is a model-initiated action during evaluation: a vendor's own model, in an authorised test, acting against a real third party with no attacker involved. A KEV entry against a product you run says nothing about whether that product's maker was breached.
"And forensic triage": the obligation patching does not discharge
This is the part of BOD 26-04 that changes the shape of the work rather than its speed. The directive defines the phrase attached to rows 1, 3 and 9 like this: the text "& forensic triage" means the agency must complete remediation or mitigation within the three-day timeline "and carry out a forensic triage of the asset to assess whether the system is compromised."
The trigger is not "high severity". It is KEV membership plus total control, plus either public exposure or automatability. Row 11, an internal KEV vulnerability with total control that is not automatable, gets 14 days and no triage. Row 9, the same asset with automatable exploitation, gets 72 hours and a compromise assessment.
CISA's implementation guidance sets out six steps. The timings are explicitly advisory: "The requirement of BOD 26-04 is that an adequate forensic triage analysis is performed; the specific timeline below is not required."
Step | Target timeline | What it produces |
|---|---|---|
1. Scoping | First 2 hours | Boundaries, affected systems, an activated team, an out-of-band comms channel |
2. Preserve and collect evidence | 2 to 24 hours | Volatile then persistent data, with a log naming each item, source, timestamp and collector |
3. Critical patching and stabilization | 2 to 24 hours | Patches applied after collection, plus stabilisation of affected business systems |
4. Contain and control | 6 to 24 hours | Isolation of impacted and suspected systems, documented internally |
5. Triage analysis | 24 to 48 hours | Findings on unauthorised access, actor presence, lateral movement, persistence, exfiltration |
6. Escalation decision | 48 to 72 hours | A triage report, and a decision to close, continue or escalate to full incident response |
Two sentences in that guidance invert most teams' reflex. "Do not alter or remediate systems prior to evidence/artifact collection when possible." And on containment: "Premature containment can destroy vital evidence." The instinct to patch immediately is the instinct that destroys the evidence needed to answer the question the directive asks.
The catalog carries this through. All 45 entries added since 10 June share one required-action text instructing stakeholders to apply vendor mitigations "ensuring compliance with CISA's BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA's 'Forensics Triage Requirements' (see URL in Notes)", and to evaluate each asset's internet exposure themselves. Each links the directive and the triage guidance in its notes field.
BOD 26-02 and end-of-support edge devices: a finding with no CVE
Four months earlier, on 5 February 2026, CISA issued BOD 26-02 on end-of-support edge devices. It defines end of support as hardware, firmware and software versions "that no longer receive timely, supported updates from the original equipment manufacturer, including patches for CVEs, security updates, software fixes (hotfixes), and defects", and edge devices as technology devices "that reside on the boundary of an agency's network and are accessible from the public internet", including load balancers, firewalls, routers, switches, wireless access points, network security appliances, IoT edge devices and software-defined networking components. Its required actions run on a longer clock than BOD 26-04.
From issuance | Required action |
|---|---|
Immediately | Update each vendor-supported edge device running end-of-support software or firmware to a supported version, where that does not harm mission-critical functionality |
3 months | Inventory all devices on the CISA end-of-support edge device list and report it to CISA |
12 months | Decommission all listed devices reaching end of support by that date, report them, and inventory every edge device that is or will become end of support within twelve months |
18 months | Decommission all identified end-of-support edge devices, replacing them with vendor-supported devices, and report |
24 months | Establish continuous discovery of edge devices and decommission each one on or before its end-of-support date |
The directive excludes operational technology devices and FedRAMP-authorised cloud products defined out of scope by OMB Memorandum M-24-15, and applies to agencies rather than contractors.
For a testing programme the significant fact is structural. An end-of-support edge device is a finding with no CVE attached: no identifier to look up, no advisory to cite, and no row in the BOD 26-04 table, because that table is indexed by CVE ID. A scanner keyed on CVE matching reports the device as clean the day after its final patch ships, and keeps doing so for the rest of its life. Detection is an inventory and lifecycle problem, which is why it belongs in a scoping conversation rather than a scan report.
What breaks in your programme
Most of the damage lands in documents written years ago and never revisited.
Language you probably have today | What BOD 26-04 breaks | What to write instead |
|---|---|---|
"Critical findings remediated within 15 days per CISA BOD 19-02" | Revoked, and CVSS severity is no longer the federal prioritization currency | Tier on exposure, KEV status, automatability and technical impact |
"KEV entries remediated within 14 days per BOD 22-01" | Revoked, and 89 percent of new entries now carry 3 days | "Within the deadline published on the KEV entry, and no later than 72 hours where the asset is internet-facing with total-control impact" |
"Retest scheduled within 30 days of remediation" | A 30-day retest cannot evidence a 72-hour remediation commitment | Tie retest turnaround to the finding's tier, not to one flat number |
"Remediation is complete when the patch is deployed" | Rows 1, 3 and 9 require a compromise assessment as well | Completion means remediation plus a documented triage outcome |
"Vendor shall remediate critical vulnerabilities promptly" | "Promptly" was always unenforceable and is now visibly behind a public benchmark | Name the tier, the hours, the evidence, and who pays for retest |
Report validity is where teams most often go wrong. The practical acceptance window for a penetration test report is still roughly twelve months, and that convention has not moved, as we set out in our guide to whether your pentest report is still valid. Among common frameworks only PCI DSS v4.0.1 mandates penetration testing across a general population, at least every twelve months and after any significant change, with CMMC requiring it at Level 3; ISO 27001, SOC 2, NIST SP 800-171 and NIS2 set no testing frequency. BOD 26-04 changes none of that. What it changes is the credibility of the remediation and retest turnaround you claim inside that window.
Compromise assessment as a standing deliverable
The forensic triage requirement quietly converts an occasional service into a standing capability. Three days is not enough time to run a procurement, sign a statement of work and onboard a response firm. It is enough time to execute a plan you already have.
Pre-agree the trigger. Decide which findings escalate from "patch it" to "patch it and prove nobody got there first". The BOD 26-04 combination is a defensible starting point: catalogued exploitation, total-control impact, and either internet exposure or automatable exploitation.
Pre-agree evidence order. Write down that volatile data collection precedes patching and that containment follows collection, with a named person authorised to hold a patch for a defined number of hours. Without that authority in writing, the reflex to patch wins and the evidence is gone.
Pre-agree the out-of-band channel. Step 1 requires a communications channel that does not rely on potentially compromised infrastructure. Establishing one mid-incident is too late.
Pre-agree the report shape. The output is a document with an incident timeline, a technical who, what, where and when, containment actions taken, and a recommendation. If you cannot produce that in 72 hours, the gap is process, not tooling.
Stingrai works exclusively in offensive security, so our part is technical evidence: confirming whether a remediation actually closed the path, and whether an asset your inventory calls internal is reachable from the internet. Those exposure and automatability determinations are precisely what an emergency assessment after an incident tends to find were wrong. Human validation of every finding sits in our Hybrid engagements, the tier that matters most when a finding starts a 72-hour clock.
Rewriting the retest window in your next statement of work
Six clauses to add or amend, in priority order.
Replace severity-based SLAs with the four-variable model. State exposure, KEV status, automatability and technical impact as the inputs, and publish the resulting tiers. This is the single change that stops your policy citing revoked directives.
Define retest turnaround per tier, in hours for the top tier. A retest commitment slower than the remediation commitment it verifies is a contradiction a customer's security reviewer will find.
Separate remediation completion from triage completion, and add an evidence-preservation clause naming who may authorise holding a patch for collection, and for how long.
Put exposure determination in scope. Your tier depends on whether an asset is publicly exposed, an assertion your inventory makes and a test verifies. CISA's own default treats unknown exposure as exposed; adopt the same conservatism.
Name end-of-support edge devices as a deliverable, because they will not appear in a CVE-indexed scan. Our external network testing scope guide covers where they hide.
Set retest triggers, not just a retest date. A remediation event, a material architecture change and newly catalogued exploitation of a tested component should each trigger work, a pattern we extend to AI components in our retest trigger matrix.
None of this makes a private company subject to a binding operational directive. It makes your remediation programme legible against the benchmark your customers will reach for. If you want that benchmark tested rather than asserted, our pricing page sets out the engagement tiers and our scoping guide covers drawing the boundary before the clock starts.
Frequently Asked Questions
Is BOD 22-01 still in effect?
No. BOD 26-04, issued 10 June 2026, states that it supersedes and hereby revokes both BOD 22-01 and BOD 19-02, and CISA's page for BOD 22-01 now carries a banner reading that the directive has been revoked and is superseded by BOD 26-04. The KEV catalog that BOD 22-01 created continues to exist and to be maintained; what ended is the flat two-week remediation deadline it set. Any policy, contract or report still citing BOD 22-01 timelines is citing a revoked instrument.
What is CISA BOD 26-04?
BOD 26-04, titled Prioritizing Security Updates Based on Risk, is a binding operational directive issued on 10 June 2026 that replaces flat severity-based remediation deadlines with a risk-tiered model for federal civilian executive branch agencies. It sets timelines using four variables: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether exploitation is automatable by an adversary, and whether technical impact is partial or total control. Those inputs produce a sixteen-row table with tiers of 3 days, 14 days, 60 days, and a deferral tier of fix on system upgrade.
What is the current KEV remediation deadline?
There is no longer a single deadline. Under BOD 26-04 a KEV entry can carry 3 days or 14 days depending on exposure, automatability and technical impact, and the three-day tier can also apply to a vulnerability that is not in KEV at all if the asset is internet-facing with automatable total-control impact. In practice the catalog has shifted sharply: of 45 entries added between 10 June and 7 August 2026, 40 carry a three-day deadline and 5 carry 14 days, computed from CISA catalog version 2026.08.07. The correct answer for any specific vulnerability is the due date published on its own KEV entry.
Does BOD 26-04 require a forensic investigation?
For three of the sixteen rows in its timeline table, yes. Where the vulnerability is in KEV, technical impact is total control, and the asset is either publicly exposed or the exploit is automatable, the agency must remediate within three days and additionally carry out a forensic triage of the asset to assess whether the system is compromised. CISA's implementation guidance sets out six steps, from scoping within the first two hours to an escalation decision at 48 to 72 hours, and states the requirement is an adequate triage analysis rather than adherence to those specific timings. Notably it directs that evidence be collected before patching, because patching can destroy the artefacts the triage depends on.
What is CISA BOD 26-02 and does it apply to private companies?
BOD 26-02, issued 5 February 2026, requires federal civilian executive branch agencies to inventory and decommission end-of-support edge devices, defined as boundary devices reachable from the public internet whose vendor no longer supplies security updates. Its deadlines run from an immediate obligation to update supported devices, through inventory at 3 months, decommissioning at 12 and 18 months, and continuous discovery at 24 months. It does not bind private companies, and it excludes operational technology and certain FedRAMP-authorised cloud services. Its value outside government is the definition: an end-of-support edge device is a finding with no CVE attached, so CVE-indexed scanners will not surface it.
How long is a penetration test report valid for?
There is no legal expiry date, and in practice buyers and procurement teams treat a report as current for about twelve months. Among common frameworks only PCI DSS v4.0.1 mandates penetration testing across a general population, at least once every twelve months and after any significant change, with CMMC requiring it at Level 3; ISO 27001, SOC 2, NIST SP 800-171 and NIS2 set no testing frequency. A material change to the tested environment can void a report well inside the twelve-month window, which is why change-based retest triggers matter more than the date on the cover.
How quickly should you retest after remediation?
Fast enough that the retest can evidence the remediation commitment it verifies, which for top-tier findings now means hours or days rather than a flat thirty-day cycle. A useful benchmark is CISA's own tiering: internet-facing assets with catalogued exploitation and total-control impact sit on a 72-hour remediation clock, so a retest turnaround measured in weeks cannot substantiate that pace. Set retest turnaround per tier rather than as one number, and treat remediation events, material architecture changes and newly catalogued exploitation of a tested component as separate triggers.
Do private-sector companies have to follow CISA binding operational directives?
No. A binding operational directive is a compulsory direction to federal executive branch departments and agencies under 44 U.S.C. 3552(b)(1), and BOD 26-04's scope section states that, unless directed by the governing procurement contract, it does not apply to contractors. Two indirect routes still reach private companies: agencies must review their contracts to determine what modifications are needed, which propagates the language through procurement; and the directive is now the most visible public benchmark for remediation speed, which is what customers, insurers and regulators will compare your SLAs against.
References
CISA, "BOD 26-04: Prioritizing Security Updates Based on Risk," 10 June 2026: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
CISA, "BOD 26-04: Implementation Guidance for Prioritizing Security Updates Based on Risk," 10 June 2026: https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk
CISA, "BOD 26-02: Mitigating Risk From End-of-Support Edge Devices," 5 February 2026: https://www.cisa.gov/news-events/directives/bod-26-02-mitigating-risk-end-support-edge-devices
CISA, "BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities (Revoked)": https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities-revoked
CISA, "BOD 19-02: Vulnerability Remediation Requirements for Internet-Accessible Systems (Revoked)": https://www.cisa.gov/news-events/directives/bod-19-02-vulnerability-remediation-requirements-internet-accessible-systems-revoked
CISA, Known Exploited Vulnerabilities Catalog, catalogVersion 2026.08.07, released 7 August 2026: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
