Risk Over Compliance: What CISA’s BOD 26-04 Asks of Federal Civilian Agencies
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.
An admission, not just a directive
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.
Risk, simplified to four questions
Strip away the methodology, and the directive resolves urgency to four clear criteria.
Is the vulnerable asset publicly exposed to untrusted networks?
Is the CVE listed on CISA's Known Exploited Vulnerabilities catalog?
Can an adversary automate every step required to exploit it?
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.
Why now, and why AI changes the math
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.
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.
Prioritization is necessary, though not sufficient
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.
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.
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.
What agency leaders should do now
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.
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.
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.
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.
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, 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.
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.
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.
Schedule a Demo →Subscribe to receive the latest blog posts to your inbox every week.
Stay in touch
Subscribe for product updates and RapidFort newsletter.
Latest posts
Eliminate Attack Vectors at the Source
Continuously eliminate up to 99.9% of CVEs without code changes
Products
Use Case
Address
440 North Wolfe Road, Sunnyvale, CA 94085
Stay in touch
Subscribe for product updates and RapidFort newsletter.
© 2026 RapidFort, Inc.
RapidFort, RAPIDFORT, and RBOM are registered trademarks of RapidFort, Inc. All other marks and names mentioned herein may be trademarks of their respective companies.
