Why not all vulnerabilities need to be fixed immediately
Treating every vulnerability as an emergency isn't actually the safer approach, NIST's own SP 800-40 guidance frames patching as one of several legitimate risk responses (alongside mitigation, avoidance, transfer, and documented acceptance) and explicitly warns that rushed, untested patches carry their own operational risk. With only 2 to 7 percent of disclosed vulnerabilities ever actually exploited, spreading urgency evenly across every finding wastes limited remediation capacity that should go toward what's genuinely reachable, actively exploited, and sitting on systems that matter.
Treating every vulnerability as an emergency sounds cautious, but it is not actually how mature security programs operate, and it is not what NIST's own patch management guidance recommends either. NIST SP 800-40 Revision 4 explicitly frames patching as one of several valid risk responses, alongside mitigation, avoidance, transfer, and documented risk acceptance, and states plainly that for a vulnerability not yet being exploited, organizations should weigh the risk of leaving it unpatched against the operational risk of applying a fix without proper testing. In other words, the guidance itself does not say patch everything immediately. It says make a deliberate, informed decision.
That distinction matters more than it might sound. Only a small share of disclosed vulnerabilities, generally cited in the range of 2 to 7 percent, are ever actually exploited in the wild, based on research from FIRST, the organization behind the EPSS scoring model. Treating a critical CVSS rating as an automatic all-hands emergency, regardless of whether that specific flaw is actually being targeted, spreads urgency across far more findings than genuinely warrant it.
Why "patch everything immediately" is not actually the safer choice
Applying every patch the moment it is released sounds like the cautious default, but NIST's own guidance pushes back on that instinct directly. Patches themselves carry operational risk, a rushed deployment without proper testing can break a dependent system, disrupt a production process, or introduce a new problem while solving the old one. NIST's recommendation is explicit about this tradeoff, weigh the security risk of waiting against the operational risk of deploying too fast, rather than assuming faster is always safer.
There is also a resource reality underneath this. Every organization has a finite amount of remediation capacity, staff hours, maintenance windows, change approval bandwidth. Spending that limited capacity on a low-severity finding on an isolated system means less capacity available for a high-severity finding sitting on something that actually matters. Treating every vulnerability as equally urgent does not make an organization safer, it just spreads the same finite effort more thinly across findings that do not deserve equal attention.
What NIST actually recommends instead of blanket urgency
SP 800-40 Rev 4 outlines several legitimate responses to a given vulnerability, not just a single patch-or-fail choice:
• Patching, applying the vendor fix once it has been properly tested and validated
• Mitigation, reducing exploitability through segmentation, restricted access, or a compensating control while a permanent fix is planned
• Avoidance, removing or disabling the vulnerable component entirely if it serves no meaningful purpose
• Transfer, shifting the risk through insurance or a contractual arrangement, in cases where that is a genuine option
• Authorized acceptance, a documented, deliberate decision that the risk is acceptable given the actual exposure and business context
The common thread across all five is that the decision has to be explicit and documented, not a default outcome of simply never getting around to it. NIST's guidance also specifically calls for periodically reevaluating whatever alternative was chosen, since a compensating control that made sense six months ago may not still be sufficient today.
How to actually decide what can wait
A few factors consistently separate a vulnerability that genuinely needs immediate action from one that can reasonably sit for a planned remediation cycle.
1. Is it actually reachable? A severe vulnerability on a system with no network path an attacker could realistically use carries a different urgency than the same flaw on an internet-facing asset.
2. Is there evidence of active exploitation? A vulnerability confirmed to be under active attack, the kind tracked in CISA's Known Exploited Vulnerabilities catalog, deserves priority over one that is theoretically dangerous but has no observed exploitation.
3. What does the affected system actually support? The same finding on a system holding sensitive data or supporting a core business function warrants faster action than an identical finding on a low-value, isolated asset.
4. Is a tested, stable patch actually available? A rushed, unverified patch applied under pressure can introduce its own operational risk, which is exactly what NIST's guidance warns against.
Emergency-everything approach vs a deliberate risk response
| Treat Every Finding as Urgent | Deliberate, Risk-Based Response | |
|---|---|---|
| Resource allocation | Spread thin across all findings | Concentrated on highest actual risk |
| Patch testing | Often rushed to hit a blanket deadline | Weighed against operational risk first |
| Low-risk findings | Consume the same urgency as high-risk ones | Handled through mitigation or acceptance |
| Documentation | Often informal or absent | Explicit response recorded for every decision |
| Alignment with NIST SP 800-40 | Not aligned | Directly aligned |
Frequently asked questions
Does NIST actually recommend delaying patches sometimes?
Not exactly delaying without cause, but NIST SP 800-40 Rev 4 does explicitly recommend weighing the operational risk of a rushed, untested patch against the security risk of waiting a bit longer to apply it properly, when the vulnerability is not yet being actively exploited.
Is risk acceptance a legitimate response to a vulnerability?
Yes, according to NIST's own guidance, as long as it is an explicit, documented decision rather than something that happens by default from inaction. A risk acceptance decision should also be periodically reevaluated, since circumstances around the vulnerability or the affected system can change over time.
How many disclosed vulnerabilities actually get exploited?
Research from FIRST, the organization behind the EPSS model, puts the figure at roughly 2 to 7 percent of all disclosed vulnerabilities. The overwhelming majority of findings rated critical or high by CVSS alone are never actually exploited in the wild.
Does deprioritizing a vulnerability mean ignoring it?
No, and this is an important distinction. A deprioritized finding should still be tracked, documented, and periodically reassessed, whether through a planned remediation window, an active mitigation, or a formally accepted risk. It should not simply disappear from view.
What is the actual risk of patching everything immediately without prioritization?
Beyond spreading limited remediation resources too thin, rushed, untested patches can themselves cause operational disruption, which is exactly the tradeoff NIST's own guidance calls out directly. Immediate, unprioritized patching also tends to burn out remediation teams faster, since not every fix carries the same urgency in practice.
Bottom line
Fixing everything immediately is not the same as fixing what actually matters, and NIST's own guidance backs a deliberate, risk-based response over blanket urgency. The Saner platform applies that same logic across endpoints, operating systems, firmware, and third-party software, along with cloud posture, prioritizing remediation by actual exposure and exploitability so effort goes where it genuinely reduces risk instead of everywhere at once.