Bod 26-04 Explained: How Kev Deadlines Are Now Calculated

By December 7, 2026, federal civilian agencies have to meet the full deadlines set by CISA's Binding Operational Directive 26-04 (BOD 26-04). When CISA ran the directive's risk model against one large civilian agency's real findings, about 1% of vulnerability instances needed the three-day response and more than 60% could wait for the next scheduled system upgrade.

Those numbers hold only if the inputs behind each deadline are right, and one of the four inputs has to come from your own team. This article explains what the Known Exploited Vulnerabilities (KEV) catalog is, how BOD 26-04 turns four inputs into five deadline tiers, and when the clock starts, including the case where a finding is overdue on the day it changes tier.

What does a vulnerability need to get into the KEV catalog?

CISA launched the KEV catalog in November 2021 under BOD 22-01 with roughly 290 entries. It held 1,779 entries as of November 13, 2026, about sixfold growth in five years. New entries arrive weekly, with no fixed volume and no advance notice.

A vulnerability has to meet three conditions to be listed:

1. An assigned CVE ID, so the vulnerability is formally identified in the public record.
2. Reliable evidence of active exploitation in the wild. CISA requires observed use; a proof of concept or a technique shown at a conference doesn't qualify.
3. A clear remediation action, CISA's term for a vendor update or documented mitigation a defender can apply.

The evidence requirement makes the catalog backward-looking and incomplete by design. It records what attackers have used, which keeps the list short enough to act on and credible enough to carry a legal obligation. The third condition means every entry had a defensive step available when CISA published it.

The catalog can't tell you whether a listed vulnerability is in your images, whether the affected component is running, or whether it is reachable. Only your own inventory answers those questions.

How is KEV different from CVSS?

CVSS scores severity; how much damage a flaw could cause under conditions favorable to an attacker, computed from the flaw's characteristics. KEV records exploitation, answered from observation.

The two diverge constantly. Take one finding scored 9.8 with no observed exploitation and another scored 6.5 that is in KEV, with working exploit tooling in circulation. A severity-first queue puts the 9.8 on top. An evidence-first queue puts the 6.5 first, and only that order reflects what attackers are using against exposed systems this week.

CVSS still belongs in triage as engineering context. It was never designed to set schedules, and a CVSS-sorted backlog spends senior engineering time and change windows on worst cases while evidence-backed findings wait. BOD 26-04 makes the distinction formal: CVSS is not one of its inputs.

What did BOD 26-04 change from BOD 22-01?

BOD 19-02, issued in 2019, set deadlines for fixing vulnerabilities on internet-accessible systems. BOD 22-01, issued in November 2021, created the KEV catalog and gave every entry one flat deadline, about two weeks for most entries. A vulnerability on a public-facing web server and the same vulnerability on an isolated internal system got the same date.

BOD 26-04, issued June 10, 2026, replaces both directives and sets deadlines by risk. KEV membership is now one of four inputs. The directive rolls out in three phases:

• June 10, 2026: agencies update their vulnerability management policies.
• August 2026: agencies move their processes to the tiered model.
• December 7, 2026: agencies meet the full deadlines.

The directive is mandatory for federal civilian executive branch agencies. Contractors and suppliers usually meet it through procurement, when a customer writes it into contract requirements. For a supplier, the deadline arrives inside someone else's contract language, which makes it harder to plan for.

Which four inputs set a BOD 26-04 deadline?

The model answers four yes-or-no questions for each vulnerability:

1. Exposure: Is the affected asset publicly exposed, reachable from outside the network on a routable IP address?
2. KEV: Is the CVE in the KEV catalog?
3. Automatable: Can an attacker perform every step of exploitation (reconnaissance, weaponization, delivery, and exploitation) with no human involvement? This is what makes internet-wide scanning viable, and it says nothing about how difficult the exploit is.
4. Technical impact: Does exploitation give the attacker total control of the system, or partial control? Total means control of the system itself; access to the data on it counts as partial.

CISA publishes KEV status, automatable, and technical impact for every CVE through its Vulnrichment program. You get those three as free, current data, with nothing to debate internally.

Exposure depends on your network and deployment topology, so no outside source can supply it. Someone in your organization has to assert it on the record. Because CISA supplies the other three inputs, the accuracy of every deadline depends on how granularly and honestly your team answers the exposure question.

How do the five BOD 26-04 deadline tiers work?

The four inputs produce 16 combinations, which map to five deadline tiers:

The top tier asks for two actions. One is the update. The other is forensic triage, which establishes whether the system has already been compromised and needs different skills, owners, and evidence. Internal placement doesn't lower this tier, so an air-gapped system gets the same three days as an internet-facing one. If you haven't named the triage owner and workflow in advance, setting them up uses much of the window.

Tier assignment is independent of CVSS. A CVSS-critical finding can sit in the 60-day tier, and a CVSS-medium finding can land in the three-day tier. That is the directive working as designed, and your engineering leads should hear about it before the first escalation.

Exposure is the input that most often moves a finding between tiers, and it varies by asset. Before CISA lists it, the same vulnerability can be at three days (for total control) or 14 days (for partial control) on an exposed asset where exploitation is automatable, and at 60 days if automatable or 'Fix on system upgrade' if non-automatable on an internal asset. One container image running in two deployments can carry two different deadlines on the same day.

Does BOD 26-04 add urgent work?

The growing catalog makes BOD 26-04 sound like more work. CISA's agency analysis points the other way: about 1% of vulnerability instances needed the three-day response, and more than 60% could wait for the next scheduled upgrade. Catalog volume sets how often you ask the question, and the model sets how much emergency work the answers produce. The urgent queue holds only the findings that warrant it, and your team records each deferral as a decision with a reason.

That 1% is only as reliable as the four inputs behind it. If your team scores exposure per image instead of per deployment, or works from stale enrichment data, the model produces a precise figure that is wrong, and teams act on precise figures without questioning them.

When does the BOD 26-04 clock start?

The clock starts at the earlier of two dates: the day CISA added the CVE to KEV, or the day you discovered it on your asset. If a CVE was already in KEV when a scan first found it, the clock runs from that scan date. If CISA lists it after discovery, the listing can move it to a faster tier, but elapsed time still counts from discovery. The directive measures how long the asset was exposed, whenever your team noticed.

That means a finding can be overdue the day it changes tier. Say a scan first finds a vulnerability on November 1, and it lands in the 60-day tier. On November 20, CISA adds it to KEV and it moves to the 14-day tier. Counted from November 1, that window closed on November 15, so the finding is already overdue on November 20 even though your team followed the process correctly.

To catch that on November 20 instead of at the next scan, recompute deadlines every time the catalog or CISA's enrichment data changes.

How to prepare for BOD 26-04 before December 7

BOD 26-04 makes the answers behind each deadline matter more: whether a vulnerability is present, running, and exposed in your environment. Before the full deadlines apply, confirm two things. Your count of KEV entries in your environment should come from today's scan and catalog data, so check whether it was computed this morning or copied from last month's spreadsheet. And someone should own the clock; the person who notices when a finding moves from the 60-day tier to the three-day tier, which is a separate job from owning the patch.

RapidFort analyzes your running application footprint and generates a Runtime Bill of Materials (RBOM®) alongside your SBOM, so you know which KEV entries are present in your images and which are in use.

See which KEV entries are running in your environment.

Related reading: June 16, 2026 BOD 26-04 article and August 4, 2026 BOD 26-04 article. For the external sources, see the CISA BOD 26-04 directive, the KEV catalog, and the CISA Vulnrichment page.