What Changed
This week, CISA added two vulnerabilities to its Known Exploited Vulnerabilities Catalog: CVE-2026-65660 affecting Microsoft SharePoint and CVE-2026-67279 in Mikrotik RouterOS. Both are actively exploited.
More significant than these additions is their implication under Binding Operational Directive 26-04, which took effect for Federal Civilian Executive Branch agencies earlier this year. BOD 26-04 marks a shift from traditional patch-everything strategies. It requires federal agencies to prioritize rapid remediation only for high-risk vulnerabilities on publicly exposed assets that grant total control post-exploitation, while deferring action on lower-risk issues.
This isn't just federal housekeeping. It's a model for risk-based vulnerability management that your team should study closely.
Key Findings
Compromise-detection requirements
The directive doesn't just tell agencies when to patch. It establishes expectations for checking whether threat actors compromised the system before the patch was applied. This requirement acknowledges what incident responders already know: patching a compromised system doesn't remove an attacker who's already established persistence.
For your team, this means your vulnerability management program needs an investigation trigger, not just a remediation workflow. When you patch a KEV-listed vulnerability on a production system, you need criteria for when to treat it as a potential incident, not just a maintenance task.
Evidence-based catalog
CISA's KEV submission criteria require three elements: a CVE ID, evidence of active exploitation, and clear mitigation guidance. This evidence standard matters because it filters out theoretical risks and focuses resources on vulnerabilities that attackers are actively exploiting.
Compare this to vendor severity ratings, which often reflect potential impact rather than observed exploitation. A CVSS 9.8 vulnerability that nobody's exploiting presents different operational risk than a CVSS 7.2 that's being weaponized across multiple campaigns.
"Total control" as the prioritization threshold
BOD 26-04 targets vulnerabilities on publicly exposed assets that grant total control post-exploitation. This threshold creates a practical triage mechanism. Not every vulnerability in your environment deserves the same urgency, even if CISA lists it in the KEV Catalog.
Your internal systems behind segmented networks don't face the same exploitation timeline as your internet-facing infrastructure. A SharePoint vulnerability matters more if your SharePoint instance is externally accessible than if it's locked behind VPN and conditional access controls.
Community contribution model
CISA invites organizations to submit exploited vulnerabilities through its KEV Nomination Form. This creates a feedback loop where private sector observations can influence federal priorities and vice versa.
For organizations with mature threat intelligence programs, this is an opportunity to shape the broader vulnerability landscape. If your security operations center identifies exploitation patterns before they hit public disclosure, submitting that intelligence helps the entire community prioritize defenses.
What This Means for Your Team
Federal directives often preview insurance requirements by 12 to 18 months. The vulnerability management controls outlined in BOD 26-04 will likely appear in your next underwriting questionnaire, either as explicit requirements or as factors in your Cyber Maturity Assessment.
Insurers already ask whether you maintain an asset inventory and patch management program. Expect those questions to evolve toward: Do you maintain a public-facing asset inventory? Do you have a defined process for prioritizing KEV Catalog vulnerabilities? Can you demonstrate detection capabilities for pre-patch compromise?
The shift from compliance-based patching to risk-based prioritization also changes how you justify resource allocation. When defending your security budget, you can point to BOD 26-04's framework as the federal standard for reasonable vulnerability management. If it's good enough for agencies managing classified systems, it's defensible for your board.
Action Items by Priority
Immediate: Build a public-facing asset inventory
You can't prioritize KEV vulnerabilities on externally exposed systems if you don't know which systems are externally exposed. This isn't your CMDB. This is a filtered view of assets with direct internet accessibility. Include cloud infrastructure, web applications, VPN gateways, email security appliances, and any system that accepts connections from untrusted networks.
Update this inventory continuously. Shadow IT and forgotten development environments are where KEV vulnerabilities become actual breaches.
Within 30 days: Define your KEV response workflow
Create a documented process for when CISA adds a vulnerability to the catalog. Your workflow should answer: Who gets notified? What's the assessment timeline? How do you determine if you're running the affected software? What's the patching SLA for internet-facing versus internal systems? When do you escalate to incident response?
Test this workflow with the two vulnerabilities CISA just added. Even if you don't run SharePoint or Mikrotik RouterOS, walk through the process to identify gaps.
Within 60 days: Integrate compromise detection into patch management
For KEV vulnerabilities on production systems, you need indicators of compromise checks before and after patching. This doesn't require sophisticated threat hunting for every patch. It means having defined log review procedures, file integrity monitoring, and behavioral analysis for systems that meet the "total control" threshold.
Document when you'll treat a patch event as an investigation trigger. If you're patching a vulnerability that's been exploited in the wild for three weeks, and your logs show unusual authentication patterns during that window, you're investigating an incident, not closing a ticket.
Ongoing: Monitor the KEV Catalog as threat intelligence
Add CISA's KEV Catalog RSS feed to your threat intelligence sources. When new vulnerabilities appear, use them to validate your detection capabilities. Can your security controls identify exploitation attempts for these CVEs? Would your monitoring catch the attack patterns described in CISA's advisories?
Treat KEV additions as free penetration testing scenarios. If an attacker is exploiting CVE-2026-65660 against SharePoint deployments, and you run SharePoint, test whether your defenses would detect that specific attack.
