cisatrade-pressNewsThe Broadside2 min read

CISA BOD shifts agencies from patch speed to risk triage

Federal patch metrics are finally meeting the asset inventory problem most dashboards have been politely avoiding.


TL;DR

CyberScoop reports CISA will publish a binding operational directive (BOD) Wednesday moving federal vulnerability management away from uniform patch speed and toward risk scored by asset exposure, Known Exploited Vulnerabilities (KEV) status, exploitability and criticality. Federal agencies are first in line; state CISOs and contractors supporting federal systems should expect the same vocabulary in oversight and performance conversations. The missing piece is whether the BOD gives agencies a scoring method and implementation deadlines.

CISA BOD shifts agencies from patch speed to risk triage
Editorial illustration · drawn by The Broadside

CyberScoop reports that CISA acting director Nick Andersen will publish a binding operational directive (BOD) Wednesday that changes the federal vulnerability-management question from how fast an agency patched everything to whether it patched the vulnerabilities that matter first. The criteria Andersen named are concrete: internet exposure, presence in CISA’s Known Exploited Vulnerabilities (KEV) catalog, automatable exploitation, and system or function criticality. If the published BOD matches that description, it is Andersen’s first major operational directive to state an operational fact plainly: the federal patch queue has to be governed by asset risk.

The idea has history. CISA already says organizations should use the KEV catalog as an input to vulnerability-management prioritization, and BOD 22-01 requires Federal Civilian Executive Branch agencies to remediate KEV-listed vulnerabilities within prescribed timeframes (https://www.cisa.gov/known-exploited-vulnerabilities-catalog/reducing-significant-risk-known-exploited-vulnerabilities). CISA’s Stakeholder-Specific Vulnerability Categorization work also gives analysts a way to sort vulnerability response decisions by exploitation status, safety impact and affected-product prevalence (https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc). The new piece is compulsion and granularity: CISA is moving from catalog-driven urgency toward asset-level decisions.

Where CISA is turning

Andersen’s critical infrastructure comments matter because they use the same theory outside the federal enterprise. Past approaches such as Section 9 designations and systemically important critical infrastructure labels identified important entities. Andersen said that level of designation has not produced the fidelity CISA needs. His example was a major bank: the process supporting bulk payments and a nearby branch location sit inside the same company, but they carry different risk to national functions.

That is the more serious shift. CISA is trying to move from company-level importance to function-level and asset-level importance. For federal agencies, that means the vulnerability queue becomes harder to defend with generic patch statistics. For contractors running or supporting federal systems, the agency customer’s risk ranking may become the remediation calendar. For state CISOs and critical infrastructure operators, the BOD is also a preview of how CISA wants future risk conversations conducted.

Where the text has to work

The directive still has to answer the part that turns doctrine into compliance: how agencies score asset criticality, whether they must use a particular decision tree, who approves prioritization calls, and what implementation deadlines apply. Agencies with mature asset inventories can adapt to that workflow. Agencies still reconciling scanner output to system ownership will find the compliance gap quickly.

Andersen tied part of the move to AI-enhanced threats and shorter timelines for weaponization and exploitation, while saying the directive discussions had been underway for months. The AI point is plausible and secondary. Shorter exploitation windows punish patch programs that treat every vendor release as the same operational event. A risk-based BOD only works if agencies can name what each vulnerable system does, where it is exposed, and what breaks when it fails.


Published ·Deep Fathom