GRC leaders are grappling with rising vulnerability counts and shrinking remediation windows. They're frustrated with SLA-based patching that treats a 2015 privilege escalation bug the same as last month's remote code execution (RCE). The CISA additions to the Known Exploited Vulnerabilities (KEV) Catalog and the requirements in BOD 26-04 have prompted a shift: if federal agencies must prioritize based on actual risk rather than CVSS scores alone, shouldn't everyone?
Here's what your team needs to consider when transitioning from scan-and-patch to risk-based vulnerability management.
Why Should We Care About BOD 26-04?
It's not about the directive itself, but the reasoning behind it.
BOD 26-04 mandates that Federal Civilian Executive Branch agencies prioritize rapid remediation of high-risk vulnerabilities, specifically those in CISA's KEV Catalog on publicly exposed assets that grant total control post-exploitation. This directive acknowledges that the old model of patching everything within 30 days based on CVSS scores is ineffective when overwhelmed with findings.
The KEV Catalog includes vulnerabilities with evidence of active exploitation. Recent additions include CVE-2015-3246, CVE-2015-5287, CVE-2019-1068, CVE-2021-23758, CVE-2022-0995, and CVE-2026-8452. Some of these are nearly a decade old, showing that age matters less than exploitation reality.
Your auditors and board want assurance that you're addressing actual threats, not just ticking compliance boxes. A risk-based prioritization model aligned with federal practices provides a defensible approach.
How Do We Integrate KEV Without Creating a Parallel Process?
Modify your existing severity tiers instead of creating a new workflow.
Most teams already use CVSS scores, asset criticality, and exposure to prioritize patches. Add KEV status as a modifier to escalate priority. If a vulnerability is in the KEV Catalog, it should move to your highest remediation tier regardless of its base CVSS score.
Operationally, this means:
- Your vulnerability scanner should tag CVEs that match KEV entries.
- Your ticketing system needs a field or label for KEV status.
- Your remediation SLAs should have a separate clock for KEV vulnerabilities on internet-facing assets.
Automation is key. Manually cross-referencing every CVE against the KEV Catalog is impractical. CISA updates it regularly based on evidence of active exploitation. Use a script or tool to pull the KEV feed and flag matches in your asset inventory. Modern vulnerability management platforms likely have this capability.
What's Different About the KEV Approach?
CVSS measures theoretical severity, while KEV measures observed threat activity.
A vulnerability can have a CVSS score of 9.8 but remain unpatched for years if it's not being exploited. Conversely, a CVSS 7.2 privilege escalation bug that's actively weaponized needs immediate attention. The KEV Catalog identifies which vulnerabilities threat actors are using.
BOD 26-04 requires federal agencies to prioritize based on risk context, not just score. It highlights vulnerabilities on publicly exposed assets granting total control post-exploitation. This combination of exposure, impact, and active exploitation defines high risk.
For your program, you need three data points for every vulnerability:
- Is it in the KEV Catalog?
- Is the affected asset internet-facing or accessible from untrusted networks?
- Would successful exploitation give an attacker administrative or system-level control?
If the answer to all three is yes, it's your highest-priority remediation target.
How Do We Manage KEV Patching with Limited Resources?
Focus on your external attack surface first.
BOD 26-04 emphasizes publicly exposed assets because that's where initial access occurs. If you have 10,000 vulnerabilities and 200 are KEV-listed, prioritize the KEV vulnerabilities on internet-facing web servers, VPN gateways, and email infrastructure.
For internal assets, use compensating controls like network segmentation, Privileged Access Management, and monitoring to reduce risk while working through the queue. The directive even suggests checking for system compromises before patches, indicating realistic timelines.
A practical tiering model:
- Tier 1 (48-72 hours): KEV vulnerabilities on external assets with no compensating controls
- Tier 2 (7 days): KEV vulnerabilities on external assets with partial mitigations
- Tier 3 (14 days): KEV vulnerabilities on internal critical assets
- Tier 4 (30 days): High CVSS non-KEV vulnerabilities following standard prioritization
How Do We Secure Funding for This Approach?
Present it as threat-informed defense, not just compliance.
Your CISO and CFO are concerned about breach risk and resource efficiency. The KEV approach shows you're focusing on vulnerabilities that attackers are exploiting, not theoretical risks.
Create a comparison: show how many of your current "critical" findings are in the KEV Catalog versus how many aren't. If you're spending equal effort on both, you're misallocating resources. The KEV Catalog provides free threat intelligence to guide your focus.
The business case is clear: "We can reduce our most likely attack vectors by 60% if we prioritize these 47 KEV vulnerabilities on external assets, versus spreading our team across 300 high-CVSS findings that aren't being exploited."
What If We Discover an Exploited Vulnerability Not in the KEV Catalog?
Submit it through CISA's KEV Nomination Form.
CISA encourages nominations for vulnerabilities with a CVE ID, evidence of active exploitation, and clear mitigation guidance. If you have forensic evidence or threat intelligence showing exploitation of a vulnerability not yet listed, use the nomination process.
While waiting for CISA's review, treat it as if it's already in the KEV Catalog for your prioritization. You've got evidence of exploitation; that's what matters. Don't wait for official confirmation to act.
Next Steps
Start by pulling the current KEV Catalog and mapping it against your asset inventory. Identify which KEV-listed vulnerabilities exist on your internet-facing infrastructure. That's your immediate action list.
Then build the automation to keep that mapping current. CISA updates the catalog regularly based on evidence of active exploitation, so this can't be a one-time exercise.
Finally, update your vulnerability management policy to reflect risk-based prioritization. Your audit and compliance teams need to understand why you're patching a 2015 privilege escalation bug before last quarter's CVSS 9.1 finding. Document the criteria, reference BOD 26-04's approach as industry practice, and ensure your remediation SLAs reflect the new priority tiers.
The goal isn't perfect compliance with a federal directive. It's aligning your patching efforts with actual threat activity so you're closing the doors attackers are trying to open, not the ones they've already walked past.
