Security standards, plainly, part 4: CISA KEV and BOD 26-04

The first three parts of this series, SSDF, SAMM and SLSA, share one gap: none of them says how fast a vulnerability must be fixed. This part is about the clock.

Two things, one agency

#

CISA is the US Cybersecurity and Infrastructure Security Agency. It publishes two things that work together:

• KEV, the Known Exploited Vulnerabilities catalog: a public list of vulnerabilities that attackers are actually using.
• BOD 26-04, a Binding Operational Directive: an order to US federal civilian agencies that says how quickly to fix vulnerabilities, using KEV as one of its inputs.

KEV answers “is this being exploited?”. BOD 26-04 answers “so how many days do I have?”.

KEV: the “this is real” list

#

Most CVEs are never exploited. KEV is the short list of the ones that are. CISA calls it “the authoritative source of vulnerabilities that have been exploited in the wild” (KEV catalog), and at the time of writing it holds 1,762 entries. Compare that with the roughly 48,000 CVEs published in 2025 alone.

A vulnerability is added only when it meets three criteria (KEV criteria):

1. It has a CVE ID.
2. There is reliable evidence of active exploitation in the wild.
3. There is a clear remediation action, such as a vendor update.

“Active exploitation” means an attacker actually ran malicious code on a system without the owner’s permission, or tried to. Scanning, security research and proof-of-concept code do not count. That is what makes the list short and trustworthy.

Each entry shows the CVE, vendor and product, a description, the date added, a due date, whether it is known to be used in ransomware campaigns, and whether BOD 26-04 requires forensic triage. The catalog is free to download as CSV or JSON. Checking a CVE takes two lines:

curl -sSfo kev.json https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
python3 -c "import json; ids={v['cveID'] for v in json.load(open('kev.json'))['vulnerabilities']}; print('CVE-2021-44228' in ids)"

True

BOD 26-04: four questions, one deadline

#

BOD 26-04, issued on 10 June 2026, replaced two older directives, BOD 19-02 and BOD 22-01. Instead of one deadline for every “critical”, it asks four yes-or-no questions about each vulnerability on each asset:

The combination of answers maps to a deadline. Tenable’s summary of Table 1 lists five tiers:

flowchart LR
  V([Vulnerability on an asset]) --> Q1{In KEV?}
  Q1 --> Q2{Internet-exposed?}
  Q2 --> Q3{Automatable?}
  Q3 --> Q4{Total or partial control?}
  Q4 --> T["Deadline from Table 1:
3 days · 14 days · 60 days · next upgrade"]

The deadline can move. Take a system off the internet and its timeline gets longer; CISA adds the CVE to KEV and it gets shorter immediately. CISA will also review the timelines once each fiscal year.

The directive is explicit about why it exists now: adversaries’ use of AI “may further narrow the time defenders have to react between patch release and possible exploitation”.

Why it is worth anything, even if you are not a US agency

#

BOD 26-04 binds only US federal civilian agencies. The idea travels anywhere.

• It makes most of the pile not urgent, officially. CISA reports that at one large agency only 1% of vulnerability instances fell into the fastest category, and over 60% could wait for the next planned upgrade. That is a gift to tired teams.
• It replaces severity with risk. A CVSS 9.8 on an internal test box and the same CVE on your login page are not the same emergency. The four questions capture that difference.
• KEV is free and public. Any team can download it every night and flag matches in its findings. That one join changes how a vulnerability list reads.
• It gives you a defensible policy. “We follow the BOD 26-04 model” is easier to agree with than a home-made rule.

In the SSDLC post I use a simplified version: KEV plus exposure plus EPSS (a daily probability that a CVE will be exploited), with 3, 14 and 30-day tiers. The triage script that implements it is about ten lines of policy. Mine is stricter than BOD 26-04’s 60-day tier; choose what fits your risk.

What it does not do

#

• It does not find vulnerabilities. It ranks the ones your scanners find. Without an inventory of assets and their CVEs, there is nothing to rank.
• KEV lags reality. A vulnerability can be exploited for days before reliable evidence reaches CISA. That is why exposure and likelihood (EPSS) still matter for CVEs not yet on the list.
• “Exposed” and “automatable” need your knowledge. CISA cannot know which of your services face the internet. You need an asset inventory with that tag, which is exactly what the directive asks agencies to build.

Takeaways

#

• KEV is the short, trustworthy list of CVEs attackers are really using: three criteria, free JSON and CSV.
• BOD 26-04 (10 June 2026) turns four questions into a deadline from 3 days to fix on next upgrade.
• Most vulnerabilities land in the slow lanes. Fix a small set very fast, and stop pretending the rest is urgent.
• It is the clock the other three standards leave out. Together: SSDF says what, SAMM says how well, SLSA proves where from, and KEV with BOD 26-04 says how fast.

References

#

• BOD 26-04: Prioritizing Security Updates Based on Risk: CISA, issue date, scope, superseded directives, four criteria, AI statement, annual review, asset tagging
• CISA BOD 26-04 FAQ: Tenable, the five remediation tiers and examples from Table 1, how timelines change
• Patch Smarter, Not Harder: CISA, the 1% and over-60% figures
• Known Exploited Vulnerabilities Catalog: CISA, entry count, entry fields, CSV and JSON downloads
• Reducing the Significant Risk of Known Exploited Vulnerabilities: CISA, the three KEV criteria and the definition of active exploitation
• Exploit Prediction Scoring System (EPSS): FIRST, the daily exploitation probability used in my triage

Previous: part 3, SLSA. Start of the series: part 1, NIST SSDF.