These questions arise from CISO discussions, vulnerability management meetings, and incident response reviews I've observed over the past year. The CISA Known Exploited Vulnerabilities Catalog isn't new, but Binding Operational Directive 26-04 changed how federal agencies must use it. This shift is prompting others to reevaluate their own patch programs.
The recent addition of CVE-2026-63077, a JetBrains TeamCity deserialization vulnerability, to the KEV Catalog is a reminder: treating all CVEs equally wastes time on low-risk patches while attackers exploit the critical ones.
Here's what your team is likely asking now.
Q1: We're not a federal agency. Why should we care about BOD 26-04?
You don't need to follow it exactly, but you should adopt its logic.
BOD 26-04 requires Federal Civilian Executive Branch agencies to prioritize rapid remediation of high-risk vulnerabilities on publicly exposed assets that allow total control post-exploitation. That's the KEV Catalog. Lower-risk CVEs can wait.
The directive also expects you to check for system compromise before applying the patch. This isn't just compliance; it acknowledges that a patch doesn't erase evidence of prior exploitation.
For non-federal organizations, this model addresses a real issue: your patch team is overwhelmed with CVEs. The KEV Catalog provides a curated list of vulnerabilities with confirmed active exploitation. If you're deciding between patching a medium-severity CVE from three months ago or a KEV entry from this week, the choice is clear.
Q2: How do we integrate the KEV Catalog into our vulnerability management workflow?
Start by mapping KEV entries to your asset inventory. Identify which systems run software with KEV-listed vulnerabilities. If your asset inventory isn't accurate, fix that first. You can't remediate what you can't see.
Next, create a separate remediation track for KEV vulnerabilities. Don't just add them to your existing patch queue sorted by CVSS score. KEV entries bypass your normal prioritization because they represent confirmed exploitation. Your SLA for KEV remediation should be measured in days, not weeks.
Automate the intake. CISA updates the KEV Catalog regularly. You need a process that checks for new additions, cross-references them against your environment, and triggers alerts when there's a match. Most vulnerability management platforms can directly consume the KEV Catalog feed.
Finally, track remediation separately. Your board doesn't need a report on every CVE you patched last quarter. They need to know if you have any unpatched KEV vulnerabilities on internet-facing assets. That's the metric that matters.
Q3: What counts as a "publicly exposed asset" for prioritization?
Anything accessible from the internet without VPN authentication. Web servers, email gateways, VPN concentrators, remote desktop services, cloud-hosted applications, APIs. If an attacker can reach it from a coffee shop, it's publicly exposed.
The harder question is what counts as "total control post-exploitation." BOD 26-04 focuses on vulnerabilities that give attackers complete access to the compromised system. Remote code execution vulnerabilities, authentication bypasses granting administrative access, privilege escalation flaws leading to root or SYSTEM-level control.
The JetBrains TeamCity deserialization vulnerability (CVE-2026-63077) fits this pattern. Deserialization flaws often allow remote code execution, and TeamCity frequently runs with elevated privileges in enterprise environments. Compromise a build server and you've got access to source code, credentials, and deployment pipelines.
Your prioritization logic should be: KEV + public exposure + high-privilege service = patch immediately. KEV + internal-only + low-privilege service = patch quickly, but not before the first category.
Q4: How do we handle the "check for prior compromise" requirement without good logging?
You can't. That's the uncomfortable answer.
BOD 26-04 expects agencies to determine if threat actors exploited the vulnerability before remediation. Without logs covering the exposure window, you're flying blind. You patch the hole, but you don't know if someone already climbed through it.
Start logging now. At minimum, you need network traffic logs for publicly exposed systems, application logs capturing authentication attempts and privilege escalation, and endpoint detection telemetry showing process execution and lateral movement indicators.
For systems where you can't confirm a clean state, treat them as potentially compromised. This doesn't mean rebuild everything, but it does mean elevated monitoring post-patch and a review of recent activity for indicators of compromise.
This is where your Computer Security Incident Response Team earns their budget. They should define what "checking for prior compromise" looks like for each asset class: web servers, database servers, build systems, authentication infrastructure. Document the log sources, the lookback period, and the specific indicators you're hunting for.
Q5: We're pressured to patch everything in the KEV Catalog within 14 days. Is that realistic?
Fourteen days is arbitrary unless it's tied to your risk tolerance and operational constraints.
BOD 26-04 doesn't specify a universal remediation timeline. It requires agencies to prioritize rapid remediation based on risk. The key word is "rapid," which is deliberately vague because context matters.
For a critical vulnerability on an internet-facing authentication server, 14 days is too slow. You should be measuring in hours or days. For a KEV entry affecting an internal development tool with compensating controls, 14 days might be aggressive but achievable.
Your remediation timeline should account for change control requirements, testing windows, and downtime constraints. But don't let those processes become excuses for delay. If your change control board meets once a month, you need an expedited path for high-risk patches.
The better question is: what's your actual mean time to remediate for KEV vulnerabilities? Track it. Report it. If it's consistently over 30 days, you've got a process problem, not a technical one.
Q6: What if a KEV vulnerability doesn't have a patch available yet?
Apply compensating controls and document them.
CISA's KEV Catalog entries include clear mitigation guidance, even when a patch isn't available. This might mean disabling a vulnerable feature, restricting network access, deploying virtual patching through a web application firewall, or isolating affected systems.
Your job is to reduce the attack surface until a permanent fix is available. If the vulnerability requires network access to exploit, block that access at the firewall. If it requires authentication, enforce multi-factor authentication and monitor for anomalous login attempts. If it's a web application flaw, deploy a WAF rule that blocks the specific exploit pattern.
Document what you did and why. When auditors or executives ask why you haven't patched a KEV vulnerability, "no patch available" isn't enough. They need to see the compensating controls and the monitoring you put in place.
Where to go for more
CISA's KEV Catalog is available at CISA's website. You can download the machine-readable JSON feed and subscribe to updates.
If you want to nominate a vulnerability for KEV inclusion, use CISA's KEV Nomination Form. You'll need the CVE ID, evidence of active exploitation, and clear mitigation guidance.
For vulnerability management process design, review NIST SP 800-53 control SI-2 (Flaw Remediation) and the NIST Cybersecurity Framework (CSF) 2.0 Identify and Protect functions. They provide the structure that BOD 26-04 builds on.
Your vulnerability management program shouldn't just track CVEs. It should answer one question: are we patching the vulnerabilities that attackers are actually exploiting? The KEV Catalog tells you which ones those are.
