The question at hand
Your vulnerability scanner just flagged 847 issues across your infrastructure. Your patching team can realistically address 50 this month. Which ones do you fix first?
This isn't a hypothetical dilemma. It's the daily reality for security teams everywhere. At the heart of this challenge is a fundamental split in how organizations approach vulnerability management: comprehensive remediation versus risk-based prioritization.
The Cybersecurity and Infrastructure Security Agency (CISA) recently added CVE-2025-39682 to its Known Exploited Vulnerabilities (KEV) Catalog, and the requirements in Binding Operational Directive 26-04 have reignited this debate. The directive requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities on publicly exposed assets, specifically those listed in the KEV Catalog that grant total control post-exploitation. Meanwhile, lower-risk vulnerabilities can wait.
But should private sector organizations follow the same playbook? Or does a different operational reality demand a different approach?
The case for comprehensive vulnerability remediation
Some security leaders argue that you can't pick and choose. Every unpatched CVE is a potential entry point, and threat actors are increasingly sophisticated at chaining low-severity vulnerabilities into high-impact exploits.
The comprehensive approach has its merits. First, it eliminates judgment calls that might prove wrong. The vulnerability you deprioritize today could be the one exploited tomorrow. Security teams have been burned before by assuming certain CVEs were "low risk" only to watch them become weaponized weeks later.
Second, comprehensive patching creates organizational discipline. When your team knows that every vulnerability gets addressed on a predictable cycle, you build the infrastructure and processes to support that cadence. Patch management becomes a repeatable operation rather than a crisis response.
Third, certain compliance frameworks still expect broad vulnerability coverage. PCI DSS requires remediation of high-risk vulnerabilities within defined timeframes, but it also establishes expectations for addressing the full vulnerability population. Audit teams don't always accept "we only patch KEV items" as adequate justification for leaving other CVEs open for months.
Finally, comprehensive remediation simplifies reporting. Your metrics are straightforward: mean time to patch, percentage of estate current on updates, number of outstanding CVEs by severity. You don't need to defend why you chose to ignore certain vulnerabilities or explain your risk scoring methodology to the board.
The case for risk-based prioritization
The counterargument is equally compelling: comprehensive remediation is a fantasy for most organizations. You don't have infinite patching windows, unlimited testing capacity, or the ability to reboot production systems weekly.
Risk-based prioritization acknowledges resource constraints and focuses effort where it matters most. CISA's KEV Catalog provides evidence-based guidance on which vulnerabilities threat actors are actively exploiting. That's not theoretical risk, it's observed behavior in the wild.
The practical benefits are significant. Your security team stops drowning in noise and starts making meaningful progress on real threats. Instead of chasing every medium-severity finding in an internal system with no internet exposure, you concentrate on the publicly accessible assets running software with known exploitation.
Binding Operational Directive 26-04 goes further by requiring agencies to check whether systems were compromised before patches were applied, but only for those high-risk KEV items. This acknowledges a hard truth: you need to assume breach on your most exposed, most dangerous vulnerabilities. Extending that level of forensic scrutiny to every CVE would paralyze incident response teams.
Risk-based approaches also align better with how attackers actually work. They don't methodically test every CVE in your environment. They scan for specific vulnerabilities they know how to exploit, often the same ones CISA adds to the KEV Catalog. Matching your defense to their offense makes operational sense.
The challenge is building the capability to execute this model. You need asset inventory accurate enough to identify publicly exposed systems. You need a process to continuously monitor the KEV Catalog and trigger emergency patching workflows. You need executive support for deferring action on lower-risk items, even when your scanner dashboard shows red.
Where practitioners actually land
Most organizations aren't choosing one approach exclusively. They're running a hybrid model, often without articulating it as such.
Critical infrastructure operators and financial institutions tend toward comprehensive remediation because their regulatory obligations and threat profiles demand it. They have the resources to maintain aggressive patch cycles and the compliance pressure to document every decision.
Mid-market companies with leaner security teams gravitate toward risk-based prioritization by necessity. They use the KEV Catalog as a forcing function to get emergency patches approved and deployed, while running quarterly or monthly cycles for everything else.
The real dividing line isn't organization size, it's asset exposure and control maturity. If you've segmented your network properly, hardened your perimeter, and limited public exposure, you can afford to be more selective about internal vulnerabilities. If your architecture is flat and your internet-facing attack surface is large, you need both speed on KEV items and steady progress on the rest.
Our take
Risk-based vulnerability management isn't about doing less work. It's about doing the right work first.
CISA's approach deserves adoption beyond federal agencies because it solves the prioritization problem with evidence rather than guesswork. The KEV Catalog represents vulnerabilities that adversaries are actively using, not theoretical CVSS scores. When you patch a KEV item, you're closing a door that someone is trying to open right now.
But here's the critical nuance: risk-based prioritization only works if you actually have a plan for everything else. Deferring action on lower-risk vulnerabilities is defensible if you're deferring to a specific timeline, not indefinitely. You still need a remediation cadence for non-KEV items, asset lifecycle policies that retire unpatched legacy systems, and compensating controls for vulnerabilities you can't immediately fix.
The organizations that get this right treat KEV additions as break-glass events that trigger emergency patching workflows, while maintaining quarterly or monthly cycles for everything else. They don't ask "should we patch this?" They ask "when must we patch this, and what happens if we don't?"
If you're still trying to patch everything simultaneously, you're setting yourself up for failure. If you're only patching KEV items and ignoring the rest, you're leaving gaps that will eventually matter. The answer is a tiered approach that acknowledges both the reality of active exploitation and the discipline of systematic remediation.
Your vulnerability scanner will keep finding hundreds of issues. Your job is making sure the dangerous ones don't stay open long enough to matter.
