Introduction
CISA’s Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk,” is a game changer leading the transition to risk-based vulnerability management.
For years, vulnerability management has been trapped in a compliance ritual: scan the environment, export a giant list of Common Vulnerabilities and Exposures (CVEs), sort by Common Vulnerability Scoring System (CVSS) score, prioritize everything labeled “Critical,” and then spend precious cybersecurity talent hours arguing about why half the findings are either unreachable, mitigated, irrelevant, duplicative, or sitting on a system nobody has touched for a long time. That was a lot of Excel cosplay, meetings and wasted effort leading to a false sense of precision.
The CVSS based Vulnerability Management model has given us a common language for severity. That matters. But CVSS was never a complete risk model. A CVSS 9.8 vulnerability on an isolated, non-production host with compensating controls is not automatically more urgent than a CVSS 7.5 vulnerability on an internet-reachable system with known exploitation and an automatable path to compromise. One is scary in theory only. The other is scary in reality, you know the place where attackers actually live.
CISA BOD 26-04 acknowledges this in a refreshingly practical way. Instead of leaning on static severity as the main driver, the directive pushes agencies to prioritize based on criteria that actually matter
- Is the asset publicly exposed?
- Is the vulnerability in the Known Exploited Vulnerabilities (KEV) catalog,
- Can exploitation be automated? (good luck arguing “no” in our AI-centric world)
- What level of control an attacker gains if exploitation succeeds?
This is truly a breath of fresh air for us folks who are supposed to be looking at “risk”. CISA has mandated that agencies stop asking “what is the score?” and start asking “can this thing be used against us, from where, how fast, and to what effect?”
That is a big deal.
Figure 1: CVSS Era vs. Risk-Based Era
The FedRAMP VDR Connection
The most interesting part of BOD 26-04 is not just what it tells agencies to do. It is how neatly it aligns with where FedRAMP is already going through the Vulnerability Detection and Response process.
FedRAMP VDR tells cloud service providers to persistently discover vulnerabilities, track them, evaluate them, monitor them, mitigate them, remediate them, assess exploitation, and report the activity in support of ongoing authorization. That is not a quarterly scan-and-comply model. That is a living vulnerability management program.
More importantly, FedRAMP VDR asks providers to evaluate vulnerabilities in the context of the cloud service offering. It specifically calls out exploitability, internet-reachability, potential adverse impact, criticality, prevalence, privilege gained, detectability, proximate vulnerabilities, and known threats. Any of that sound familiar?
CISA is now telling agencies to prioritize vulnerabilities using the same kind of real-world context that FedRAMP is asking CSPs to produce. That is the alignment worth hammering home. Agencies and FedRAMP are starting to speak the same operational language.
Instead of “how bad is this CVE in a vacuum?”, CISA is changing to conversation to “what does this vulnerability mean in this actual system, with this architecture, this exposure, these controls, these customers, and this threat activity?”
That is risk management. Finally. Welcome to the party. We saved you a seat.
Figure 2: The future is not a score. It is a decision model backed by evidence.
Why This Matters
This shift matters because vulnerability backlogs are not getting smaller. The number of disclosed vulnerabilities keeps growing, exploit development is getting faster, and AI is not exactly going to make attackers slower, dumber, or more considerate of your change window.
The old model forced teams to chase theoretical severity with limited operational context. That meant security teams could spend precious time remediating vulnerabilities that looked terrifying on paper while truly dangerous exposures sat quietly in the environment waiting for someone with a Shodan account and a Red Bull. BOD 26-04 and FedRAMP VDR both push us toward a smarter operating model with much more meaningful risk signals:
- Severity
- Exploitability
- Reachability
- Known Exploitation
- Privilege Gained
- Business and mission Impact
In this new world of “risk-based” vulnerability management, the job is not to worship any single signal. The job is to combine them into a defensible decision. This is where compliance starts to look less like paperwork and more like engineering. And yes, that is, in fact, a good thing.
Figure 3: CISA and FedRAMP Are Converging.
How to Prepare Now
Organizations should not wait for this to become a contract clause, agency expectation, 3PAO discussion topic, board question, or “friendly” customer security questionnaire. The direction of travel is obvious.
- Fix Your Asset Inventory – If you cannot prove whether an asset is publicly exposed, you cannot apply a risk-based model with confidence. If the answer to “Is the component internal?”, is “We think so.” You’re operating on vibes, not security. I promise you vibes do not survive audits or incident response calls.
- Enrich Vulnerability Findings Automatically – Your scanner output should not stop at CVE and CVSS. Pull in KEV status, exploit intelligence, exploit automation indicators, affected asset ownership, network exposure, compensating controls, and mission criticality.
- Map Reachability – To be frank, this ain’t gonna be easy. A database may not be directly internet-accessible, but if an internet-facing application can pass a malicious payload into it, congratulations, your “internal-only” database may still be internet-reachable in the way that matters. This will require out-of-the-box thinking and true engineering capability. The teams’ gonna earn its paycheck here.
- Define Your Decision Logic Before the Emergency – Create a vulnerability triage model that maps the CISA-style criteria into remediation expectations. Make the logic transparent enough that security, engineering, compliance, and executives can understand why one finding gets a three-day sprint and another gets scheduled for the next major upgrade.
- Automate the Evidence Trail – A modern vulnerability program needs to show not only that the vulnerability was detected and fixed, but how it was prioritized, who owned it, what compensating controls existed, whether exploitation was assessed, and how the final disposition was validated. This will most likely incorporate Large Language Models (LLMs) into the mix, so traceability is going to be critical. A spreadsheet ain’t gonna cut it. This will require a fully realized and embedded workflow.
Figure 4: Continuous vulnerability management is not a report. It is a loop.
The Takeaway
CISA BOD 26-04 is more than another federal patching directive. It is a signal that the government is moving away from static, in-a-vacuum vulnerability management and toward a model that reflects how attacks actually happen.
FedRAMP VDR is moving in the same direction from the CSP side. Together, they point to a future where agencies and providers evaluate vulnerability risk using shared concepts: exploitability, reachability, exposure, impact, threat activity, and continuous reporting. That is worth applauding.
CVSS is not dead. It just got demoted to where it always belonged: one input among many.
The future of vulnerability management is dynamic, contextual, automated, and evidence-driven. It is less “sort by score and pray” and more “understand the system, understand the threat, and act where it matters.” Frankly, that is how this should have worked all along.
But progress is progress, and this is real progress. Now the job for all those LinkedIn heroes out there is to build programs that can keep up. Get some.
Copyright © 2025 stackArmor, Inc., a Tyto Athene Company. All rights reserved. All other trademarks not owned by stackArmor are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by stackArmor. This document does not provide you with any legal rights to any intellectual property in any stackArmor product or solution.
