On June 10, 2026, CISA retired more than a decade of "patch everything" doctrine and ordered federal civilian agencies to remediate using a risk focus. The risk was defined based on whether there is an exploit and the blast radius of said risk. The concept of risk first versus compliance focus is new. The challenge is what agency leaders can do now that this directive exists, especially given that the AI risk generation machine keeps increasing the number of risks and shortening the time to act.
BOD 26-04 is most interesting for what it concedes. By ordering civilian agencies to remediate based on risk rather than on volume, the government has formally acknowledged that "patch everything" was never a strategy so much as an aspiration, and that against a capable adversary, the aspiration had become a liability. The directive says so without hedging, directing organizations to concentrate "on the areas of highest risk rather than treating all vulnerabilities and systems equally." That is not the tuning of a process. It is the retirement of a failing doctrine and the creation of a more viable one.
The directive applies to federal civilian agencies, and it is clear about why. There was never enough capacity to fix everything. SLAs were never truly achievable, so they lost credibility. The only questions worth arguing about became what should be fixed first and why. Every CIO and CISO operating under the Federal Information Security Modernization Act (FISMA) already lives with that arithmetic. BOD 26-04 simply makes it the official answer.
Strip away the methodology, and the directive resolves urgency to four clear criteria.
The Four Criteria of Urgency
01
Asset Exposure
Is the vulnerable asset publicly exposed to untrusted networks?
02
KEV Status
Is the CVE listed on CISA's Known Exploited Vulnerabilities catalog?
03
Exploit Automation
Can an adversary automate every step required to exploit it?
04
Technical Impact
Does exploitation grant partial or total control of the asset?
Two of those four, Asset Exposure and Technical Impact, are not severity questions at all. They are severity/blast radius assessments, and that is where the directive quietly points past itself.
The directive is unusually candid about its motivation, and that candor is itself a strategic statement. Adversaries' use of AI, it warns, "may further narrow the time defenders have to react between patch release and possible exploitation." This is the central theme of the document, and it reflects a warning the broader government has been sounding: that AI will let adversaries weaponize a disclosed vulnerability faster than agencies can patch it.
For two decades, vulnerability management has been a race. Disclose, patch, and deploy faster than an adversary can weaponize. Risk-based prioritization is what an enterprise adopts when it concedes the race cannot be won on speed alone. That concession is not hypothetical. Exploit windows have already collapsed under ten hours, while federal remediation cycles are still measured in weeks. The gap is not a forecast about what AI might do. If the previous state of patching was not viable, AI only now widens it.
Exploit window vs. federal remediation cycle
Adversary exploit window Under 10 hours
Federal agency remediation cycle Weeks
Prioritization buys time by spending attention more wisely. It does not reduce the underlying volume of work that agencies and their support contractors must carry. That gap, between what policy can mandate and what operations can absorb, is where the next phase of federal cyber strategy will be decided.
Agency leaders and policymakers should consider the corollary. Triage is a response to scarcity, not a remedy for it. Ranking vulnerabilities tells an organization what to fix first. It does nothing to reduce the number of vulnerabilities that arrive in the first place. An agency that implements BOD 26-04 flawlessly still runs the same software it ran the day before. It has organized the backlog more intelligently, which is real progress, but the backlog itself is unchanged, and on a contested timeline, an unchanged backlog is still exposure.
The fastest way to satisfy a prioritization mandate is to have less to prioritize.
Reachability and blast radius cuts the other way too. The directive uses it to decide what gets fixed first. It can and should just as easily decide what never needs fixing at all. If a component is never present, it is never exposed, never exploitable, and therefore should never appear on any program's remediation timeline.
Key Insight
The easiest vulnerability to manage is the one that was never there.
The most defensible attack surface is the one that was never there in the first place. It cannot be exploited, triaged, reported, or funded, because it is not there. Most software, though, is assembled in the reverse direction. A container image, the unit of nearly everything the government now fields, routinely carries far more than the workload it runs. Interpreters, shells, package managers, and libraries arrive in a base layer and are never questioned. In any production system, each of these components is an image that someone may later be ordered to triage, and an adversary needs only one of them to survive a patch cycle.
Triage is a response to scarcity, not a remedy for it
Backlog unchanged
Backlog exists and keeps growing
Every component must be scored against all four criteria
Remediation capacity spent on inherited exposure
Authorization cycle carries the full finding count
Component never present
Components never present never enter the queue
Fewer items to score against the KEV catalog
Remediation capacity focused on real risk
Authorization cycle carries fewer findings
Every component that was never there is one of the four criteria that never need to be scored, one fewer line item in the next cross-check against the KEV catalog, and one less thing to defend on a shortening clock.
None of this competes with risk-based prioritization. It simply makes the prioritization effort smaller. BOD 26-04 sets the floor by asking programs to fix the highest-risk findings faster. The more demanding question, and the one worth asking leadership, is why so many of those findings were ever present to begin with. That is not a tooling question. It is a question about how the government specifies, buys, and accepts the software it depends on.
BOD 26-04 and an agency's own mission want the same thing, even if they phrase it differently. The directive wants less risk to remediate. An agency wants less to defend, a faster authorization, and systems that stay available to the public it serves. Both are served by a single decision, made earlier than anyone is used to making it. Remove what a system never runs, and the risk, the backlog, and the delay leave with it. Four imperatives turn that into practice.
01
Count attack surface, not closed tickets
A program that closes a thousand findings, often through liberal administrative adjudication, and ships the same bloated image is not safer. Measure success by how much unused software a system carries, and drive that number down. That is the measure an adversary actually feels.
02
Refuse to field what you cannot account for
Make one question a condition of every authorization: What does this system actually run, and why is everything else there? Software no one can explain is software no one is paying attention to or defending.
03
Put minimization in the contract
The cheapest place to remove a vulnerability is a requirement written before the work starts. Specify lean, hardened software in solicitations so the next decade of findings is kept out, not inherited and triaged at public expense.
04
Prove security continuously, not at audit time
Tie the evidence of your posture to the pipeline that builds and ships the software. When the proof is always current, an authorization stops being a snapshot and starts describing what is true today.
A component removed before deployment never enters the prioritization queue
Before deployment
Remove unused components
Specify lean, hardened software in requirements
→
Result
Component never enters the queue
Never scored, never defended, never reported
→
Authorization cycle
Fewer findings to carry
Remediation capacity freed for real risk
A component removed before deployment never enters the prioritization queue, never has to be scored against the four criteria, and never has to be defended on a shortening clock. The work it would have generated simply never appears.
This is the rare case where the compliant move and the mission move are the same move. Every component a system does not carry is one fewer finding to remediate under BOD 26-04, one fewer obstacle between an agency and its authorization, and one fewer door the adversary can try while the clock runs. The decision that follows is a narrow one. Treat minimization of unused software as a program requirement rather than a remediation tactic, applied both to what systems already run and to what an agency acquires next.
The agencies that make that decision now carry fewer findings into their next authorization cycle, spend less time defending exposure they inherited rather than chose, and free remediation capacity for the vulnerabilities that actually warrant it.
BB
Berk Bucukoglu
VP, Public Sector · RapidFort
Berk leads the public sector at RapidFort, which helps organizations deploy near-zero CVE software and remove the software components they never use before those components become vulnerabilities to manage. To talk through what risk-based remediation could look like for your agency, reach out directly at berk@rapidfort.com or visit www.rapidfort.com.
Policy commentary reflecting the author's analysis of public CISA guidance. It is not legal or compliance advice.
References: CISA BOD 26-04, "Prioritizing Security Updates Based on Risk" (June 10, 2026).
Get in touch
RapidFort helps organizations deploy near-zero CVE software and remove the software components they never use before those components become vulnerabilities to manage. To talk through what risk-based remediation could look like for your agency, reach out directly.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。