
![]()
By Nagomi Security
Why Risk-Based Remediation Requires More Than Vulnerability Management
When CISA released Binding Operational Directive 26-04 in June 2026, the headline for many security teams was the remediation timeline. Under the directive, certain vulnerabilities now require teams to investigate and act on them within three days. At first glance, that sounds like a patching problem. Looking deeper, it’s a clear prioritization problem.
BOD 26-04 uses CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) model to determine how urgently a vulnerability should be addressed. The criteria include public exposure, active exploitation, exploit automation, and technical impact. In other words, the directive is not asking organizations to patch everything faster. It’s asking organizations to be more discerning about what they consider urgent.
That’s an important shift, because most security teams already know how to patch. What they don’t always know is what to prioritize based on anything other than the CISA KEV and the CVSS.
Agencies inside the federal government are required to comply. For organizations outside the federal government, the directive still matters; it addresses a longstanding problem of reactive security measures, and instead focuses on how organizations can use the wealth of security data at their disposal to more accurately pinpoint high-severity findings. That is: high-severity findings per their own environments, not a general assessment.
The Flood of Findings
The scenario is familiar to anyone who has spent time in security operations. Organizations continue to collect vulnerabilities faster than they can remediate them, while AI continues to compress the time between disclosure, weaponization, and exploitation. The result is a shrinking window between “known” and “active.”
CISA’s citation of the Verizon 2026 Data Breach Investigations Report makes that problem hard to ignore. Only 26% of Known Exploited Vulnerabilities (KEV) were fully remediated in 2025, down from 38% the year before. Median remediation time rose from 38 days to 43. The knee jerk reaction may be to tell teams to patch faster, but faster patching, alone, won’t solve the problem.
What will solve the problem:
- Organizations’ abilities to understand which vulnerabilities in their individual environments create high or critical risk, depending on factors such as threat intelligence, compensating controls, and business context. This must be based on:
- Clear evidence gathered from tool outputs
- Business goals and risk tolerances
- The operational cost of fixing identified exposures
A long list of vulnerabilities is not the same thing as a long list of risks.
For example, take two vulnerabilities with similar CVSS scores and evidence of active exploit. For “ABC Company,” one vulnerability exists on an internet-facing application that processes sensitive customer data. The other exists on an internal development database with no direct internet path, limited access, and a small set of privileged users.
The vulnerabilities may share similar technical characteristics, but their operational risk is very different. Only one creates a realistic path to business impact in the current environment. The other is constrained by exposure and access boundaries that significantly reduce its exploitability. While it wouldn’t hurt to fix both exposures, given the limited time most teams have for patching, only the first scenario needs attention right now.

Why Attackers Care About Context
Most security programs still organize work around individual vulnerabilities (like in the example above), but attackers don’t think that way. They look for toxic combinations: an exposed asset, an excessive permission, a weak boundary, a neglected control, a vulnerability that becomes useful only because everything around it makes exploitation easier.
That’s why risk is rarely located in a single finding. An issue that looks routine in isolation is risky when it sits on a public-facing system with too much privilege and too little segmentation. A critical vulnerability may be less important if there is no realistic path for an attacker to reach it.
This is where vulnerability management starts to show its limits and why exposure management is emerging as the answer.
BOD 26-04 focuses on the factors that make exploitation practical, not just severe.
Prioritization Is Only Half the Job
One of the more notable parts of the directive is the requirement for forensic triage on the “highest-priority” vulnerabilities. With this requirement, CISA is, in effect, admitting something security teams generally know but don’t always admit: by the time a vulnerability reaches the top of the queue, it may already have been exploited.
That changes what remediation is supposed to accomplish. Security teams can no longer focus solely on vulnerability identification and generic prioritization. They must also understand how individual vulnerabilities relate to active attack paths and whether adversaries can manipulate progressive exposures to reach their objectives.

How Exposure Operations Aids BOD 26-04
Exposure operations emerged largely in response to vulnerability and patch management shortcomings.
Exposure ops identifies the conditions that create viable attack paths and determines which remediation actions will have the greatest impact on risk. It can help answer risk-based questions like:
- Is the asset exposed?
- Is exploitation occurring?
- Can exploitation be automated?
- What happens if exploitation succeeds?
Those questions are fundamentally contextual and require SecOps teams to know how a vulnerability functions under specific conditions.
What’s more, BOD 26-04 sets remediation timelines. This means that if (when) an exposure reappears, the clock resets to neutralize the risk. This assumes that the organization knows a “closed” ticket is no longer closed because permissions changed, controls drifted, a path that was blocked yesterday was opened today.
Effective exposure operations automatically re-validates closure so that when things shift, the team has confidence that risk isn’t reintroduced.

What the Directive Really Means
Now imagine the same day with a different operating model.
The most important thing about BOD 26-04 isn’t the three-day deadline; it’s deciding what deserves attention first.
CISA seems to be acknowledging that traditional vulnerability management must be more contextual, more operational, and more closely tied to exposure. Simple severity scoring is insufficient in light of exposure operations, which helps teams understand reachability, exploitability, and impact in their own environments and prioritize accordingly.
Maybe more importantly, exposure ops allows SecOps teams to move away from the frenzy of traditional patch management and toward a more sustainable process capable of handling evidence-backed critical exposures.
Want to see how Nagomi’s Agentic Exposure Ops Platform handles your environment? Request a demo..
See Nagomi in action at nagomisecurity.com



