CISA's KEV Catalog Just Got Teeth: What the New BOD Means for You

CISA dropped a significant update to their Known Exploited Vulnerabilities (KEV) program this month. If you’ve been ignoring KEV because “we’re not a federal agency,” that calculus might need to change.

What’s the KEV Catalog?

Quick refresher: CISA maintains a catalog of vulnerabilities that are actively being exploited in the wild. Not theoretical risks - confirmed, in-the-wild exploitation.

Currently sitting at 1,200+ entries, it’s essentially a prioritized “patch these first” list.

Previously, only federal civilian agencies were required to remediate KEV entries within mandated timeframes. Private sector could use it as guidance, but there was no requirement.

What Changed

The new Binding Operational Directive (BOD 25-01) expands requirements in several ways:

1. Federal Contractor Obligations

If you hold federal contracts involving IT systems, you’re now expected to address KEV entries affecting those systems. Not “suggested” - contractually expected.

This flows down to subcontractors. If you’re a small company providing services to a federal contractor, this might affect you.

2. Tighter Timelines

Previous guidance gave 2-3 weeks for most vulnerabilities. New timelines:

Severity	Previous	New
Critical (actively exploited, network-accessible)	14 days	7 days
High	21 days	14 days
Others	30 days	21 days

For context: the MOVEit vulnerability (CVE-2023-34362) was added to KEV and exploited at scale within days. A 14-day window was already tight.

3. Reporting Requirements

Federal agencies must now report:

Current KEV remediation status
Any exceptions or compensating controls
Planned remediation dates for open items

This data will be aggregated and (eventually) made available for benchmarking.

4. Cloud Service Expectations

Explicit guidance now covers cloud services. If you’re using a SaaS product affected by a KEV entry, you’re expected to:

Verify the vendor has remediated
Document vendor remediation status
Consider compensating controls if vendor is slow

Why This Matters for Private Sector

Even if you’re not in the federal ecosystem, pay attention:

Cyber Insurance

Insurers are increasingly referencing KEV in underwriting and claims. “Did you patch known-exploited vulnerabilities in a timely manner?” is becoming a standard question.

Failure to address KEV items could affect:

Policy premiums
Coverage availability
Claim payouts after incidents

Due Diligence Standards

KEV is becoming a de facto standard of care. In breach litigation:

“Your organization was compromised via CVE-XXXX, which had been on CISA’s Known Exploited Vulnerabilities catalog for 45 days before the breach. Why wasn’t it patched?”

That’s a hard question to answer in front of a jury.

Supply Chain Requirements

Large enterprises are pushing KEV compliance onto their vendors. If you want to do business with Fortune 500 companies, expect questions about your vulnerability management program and KEV specifically.

Practical Implications

What You Should Do

1. Automate KEV monitoring

The catalog is available as JSON and CSV. Set up automated checks:

# Simple example - download and check against your inventory
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | \
  jq '.vulnerabilities[] | select(.vendorProject == "Microsoft") | .cveID'

Or use commercial vuln management tools that incorporate KEV data (most do now).

2. Integrate with patch management

KEV items should jump the queue. Whatever your normal patch cycle is, KEV entries need expedited handling.

3. Document exceptions

If you can’t patch something immediately (legacy systems, testing requirements), document:

Why you can’t patch
What compensating controls exist
When you plan to remediate

4. Track mean time to remediation

Start measuring how long it takes to address KEV items. This metric will be asked about by auditors, insurers, and customers.

What This Means for Vulnerability Management

KEV creates a clear tier system:

Tier 1: KEV entries (actively exploited) - Patch NOW
Tier 2: Critical CVSS, known PoC - Patch within cycle
Tier 3: Everything else - Risk-based prioritization

This simplifies prioritization conversations. When leadership asks “why are we doing emergency patching on a weekend?” the answer “it’s on CISA’s active exploitation list” carries weight.

The Bigger Picture

CISA is slowly building a vulnerability management standard through KEV. What started as federal guidance is becoming industry baseline.

This mirrors patterns we’ve seen before:

NIST frameworks started as federal guidance, now are industry standard
FedRAMP security requirements influenced cloud security broadly
FISMA compliance became a model for private sector frameworks

KEV is following the same trajectory.

Criticisms and Limitations

Not everyone loves KEV:

“It’s reactive, not proactive” True. By definition, something is only added after exploitation is observed. You can’t rely on KEV alone for vulnerability management.

“Timelines are unrealistic for some environments” 7 days to patch a critical in a complex environment with change management? Tough ask. But “tough” isn’t the same as “unreasonable” when the alternative is getting breached.

“It creates a false sense of completeness” If you only patch KEV items, you’re missing thousands of other vulnerabilities. KEV is a floor, not a ceiling.

What to Watch

A few developments I’m tracking:

International adoption: Will other countries create their own KEV equivalents?
Automated sharing: Integration with STIX/TAXII for real-time updates
Vendor accountability: Will vendors face pressure to patch KEV items faster?
Insurance mandates: How quickly will KEV become an insurance requirement?

References

CISA’s KEV started as federal guidance. It’s becoming the industry standard for “you should have patched this.” Plan accordingly.