DEV Community

endoflife-ai
endoflife-ai

Posted on • Originally published at endoflife.ai

CISA rewrote how the US government handles dying software — twice this year

Two binding directives landed in 2026 that most of the private sector hasn't noticed — and together they're the clearest public statement yet of what competent vulnerability management looks like.

BOD 26-04 (June 10): severity scores are out, risk is in

Since 2021, federal patching ran on a simple rule: CVE lands in CISA's Known Exploited Vulnerabilities catalog → fixed clock starts. BOD 26-04 supersedes that entirely. Now four questions set the deadline for every vulnerability on every asset:

  1. Asset Exposure — is it publicly reachable?
  2. KEV Status — is the CVE actively exploited in the wild?
  3. Exploit Automation — can an adversary automate the whole attack?
  4. Technical Impact — partial or total control after exploitation?

Worst case on all four: three calendar days to remediate, plus mandatory forensic triage to check whether you're already compromised. Lowest tier: legitimately wait for the next scheduled upgrade. CISA pre-computes three of the four answers for every CVE through its Vulnrichment program.

The design says the quiet part loudly: severity is not risk. A CVSS 9.8 on an internal box with no exploit in the wild can matter less than a 7.5 being mass-exploited on your edge.

BOD 26-02 (February 5): end-of-support became a compliance deadline

The one almost nobody covered. This directive targets a single category — end-of-support edge devices: the firewalls, VPN appliances, and routers that face the internet and no longer receive vendor patches. Agencies got three months to find and remediate them, using a CISA-maintained EOS Edge Device List (yes — the US government now curates its own end-of-life database). The underlying OMB policy is blunt: unsupported systems must be "phased out as rapidly as possible."

The gap between the two directives

26-04 optimizes patching for software that can be patched. 26-02 evicts hardware that no longer can be. The gap: end-of-life software that isn't an edge device. The directive defines remediation as "patching, decommissioning the system, or another action" — but for EOL software, the patching option is permanently gone. Every future KEV entry against a dead product arrives pre-aged: exploited, often automatable, unfixable except by migration. Risk that cannot decay.

That's why lifecycle status is effectively the fifth risk variable — the one that determines whether the patch-based timelines are achievable at all. (It's the variable we build our EOL risk scores around, so yes, we're biased — but the government got here on its own.)

The 20-minute private-sector version

  1. Inventory with lifecycle status — you can't triage what you haven't dated.
  2. Adopt the four questions for patch priority; Vulnrichment answers three of them for free.
  3. Treat EOL as its own tier — anything past end of support can never satisfy a patch deadline again. Migrate, or bridge with extended support while you do.

Both directives are public, battle-tested at federal scale, and free to copy: BOD 26-04 · BOD 26-02. Full analysis with the FAQ: endoflife.ai/article-cisa-bod-26-04-eol

Top comments (0)