Myth vs fact: patch everything immediately and you are safe

Patching quickly reduces risk, but "patch everything immediately and you are safe" is a myth. Some attacks use flaws before a patch exists, some assets cannot be patched, and untested patches can break systems. A tiered plan that patches fastest where exploitation and exposure are highest works better.

Myth 1: if you patch everything at once, you are safe

Fact: zero-days are exploited before patches exist. Mandiant's analysis of 138 vulnerabilities exploited in the wild that were disclosed in 2023 found 97 were exploited as zero-days. Patching cannot help with those. Mitigation and detection can. See zero-day vs n-day data.

Myth 2: patching never needs testing

Fact: NIST SP 800-40 Rev 4 recommends deploying first to a small canary subset to determine likely operational impact, even under emergency conditions for a few minutes to hours. It also notes that patches can be flawed, can disrupt other systems, or can even be compromised. See canary patch rollouts.

Myth 3: every high severity score is urgent

Fact: FIRST's CVSS FAQ says base scores are not risk and should not be used alone for patch prioritization. Exploitation likelihood, exposure and asset importance matter. FIRST's EPSS FAQ says EPSS is not a complete risk score either, and it does not know which assets you run. See the CVE, CVSS, EPSS and SSVC comparison.

Myth 4: if it is unpatched, it is negligence

Fact: some assets cannot be patched in a reasonable time, because the vendor stopped issuing patches or the system must run without interruption. NIST treats these as a defined scenario with long-term mitigation and periodic review, not as an automatic failure. See unpatchable assets. The key is that the decision is deliberate and recorded. See the exception register.

Myth 5: routine patches can wait because only emergencies matter

Fact: NIST says routine patching is often postponed and neglected, which gives attackers more windows and makes later emergency patching harder. See patch debt. Most patching is routine, so the routine process is where most of the risk reduction happens.

What works instead

1. Know your assets and software.
2. Group assets by how they should be patched.
3. Use exploitation evidence and exposure to choose emergency, routine or mitigation.
4. Roll out in rings and watch for problems.
5. Track exceptions with end dates.
6. Measure by importance, not a single percent. See patch metrics that show risk.

Click through it at your own pace, or open it full screen.

Safeguard's reachability analysis and policies support step three for code, showing which vulnerable functions are called and letting you gate builds by rule. Its fix pull requests are off by default and every category begins on Manual.

Quick check

Sources

• Google Cloud, Mandiant time to exploit analysis for 2023
• NIST SP 800-40 Rev 4 full text (PDF)
• FIRST CVSS v4.0 FAQ
• FIRST EPSS FAQ

Last reviewed: 19 October 2026.