IntermediatePatch Management

Test patches in staging, but do not let testing be a reason to delay production deployment

Patch testing exists to prevent broken production deployments — not to create a delay buffer. Security teams frequently report that patches are held in "testing" for weeks or months, negating the purpose of having a patch cycle. The WannaCry attack exploited EternalBlue — a vulnerability Microsoft had patched two months earlier. Most organisations that were hit had been holding the patch in their testing process. Establish a maximum testing window: 72 hours for critical patches. If a critical patch cannot complete testing in that window, deploy it with a rollback plan rather than waiting for testing to complete.

More in Patch Management

All guides

beginnerfeatured

Treat CVSS 9.0+ vulnerabilities as a 72-hour emergency, not a scheduled task

Equifax's catastrophic breach was caused by a vulnerability that had a published patch available 78 days before attackers exploited it. The Apache Struts vulnerability had a CVSS score of 10.0 — the maximum. At that severity, every day of delay is a calculated risk exposure. Establish a clear policy: CVSS 9.0 and above triggers an emergency patching process with a maximum 72-hour window from discovery to production deployment. Lower severities follow a normal cycle. This distinction alone would have prevented the Equifax breach.

See: Equifax BreachPatch Management

intermediate

Disable legacy protocols that no longer require patches — because they never get them

SMBv1 — the protocol exploited by EternalBlue, WannaCry, and NotPetya — had known vulnerabilities for years before the Shadow Brokers leak made exploitation trivial. Microsoft had provided a patch, but also offered a better solution: disable SMBv1 entirely, since no modern system requires it. The same principle applies to TLS 1.0/1.1, SSLv3, Telnet, and FTP. The safest patch for a protocol that has no legitimate current use is removal. Audit your network for legacy protocol usage and disable any that cannot be justified by a specific named business requirement.

See: EternalBlue / Shadow BrokersPatch Management

beginner

Run a continuous asset inventory — you cannot patch what you do not know exists

One of the most common root causes of successful vulnerability exploitation is an unmanaged, forgotten system that never received patches. The Equifax breach involved an application that security teams did not know was internet-facing. The Fortinet VPN zero-days were exploited on appliances that network teams had lost track of. A continuously updated asset inventory — covering servers, virtual machines, cloud instances, network appliances, and containers — is the foundation of any patch programme. Scan your network weekly for new assets. Any new internet-facing asset must be tracked and added to the patch programme before deployment.

See: Fortinet VPN Zero-DaysPatch Management