Solutions

Patch Management Gone Wrong: Real Incidents and Prevention Tips

June 18, 2025

Learn from major patching failures like WannaCry and Equifax, and apply practical patch management tactics to prevent similar incidents in your organisation.

Almost every major breach post-mortem contains a familiar phrase: “A patch was available, but not applied in time.” From WannaCry to Equifax, some of the most damaging cyber incidents in history have been traced back to known vulnerabilities that remained unpatched on exposed systems.

In 2024 and 2025, this pattern continues. The CISA Known Exploited Vulnerabilities (KEV) catalog tracks vulnerabilities that are actively exploited in the wild and mandates rapid remediation for US federal agencies. Recent additions include critical flaws in endpoint management tools and network appliances, with agencies given days or even hours to patch or take systems offline.

For CISOs and IT leaders, the lesson is clear: patch management is no longer a background hygiene task. It is a frontline security control that must be prioritised, governed and measured.

When patch management fails: three illustrative incidents

These incidents highlight different ways patch management can go wrong, and what can be learned from each.

1. WannaCry: patch available, but applied too late

WannaCry ransomware spread globally in 2017 by exploiting a Windows vulnerability (EternalBlue) for which Microsoft had already released a patch. Organisations that did not apply the security update quickly faced widespread encryption of endpoints and servers across more than 150 countries.

Key lessons:

  • Exposed internet-facing systems with unpatched critical vulnerabilities are prime ransomware targets.
  • Relying on manual patching and inconsistent maintenance windows leaves dangerous gaps.
  • Legacy systems that cannot be patched must be isolated and protected with strict compensating controls.

2. Equifax: a missed patch and incomplete asset visibility

The Equifax breach traced back to an unpatched Apache Struts vulnerability on a public-facing web application. Despite the availability of a patch and internal alerts, the specific system remained unpatched, allowing attackers to exfiltrate sensitive consumer data at massive scale.

Key lessons:

  • Asset inventories must be accurate and maintained; you cannot patch what you do not know exists.
  • Patch campaigns should verify actual remediation through scanning or configuration management, not just change tickets.
  • Critical internet-facing applications should have enhanced monitoring for exploit attempts and anomalous behaviour.

3. Modern KEV exploitation: endpoint managers and remote gateways

Recent years have seen critical vulnerabilities disclosed in widely used endpoint management tools and remote access gateways, some actively exploited as zero-days before patches were broadly deployed. CISA has repeatedly added such flaws to its KEV catalog and imposed tight patch deadlines on agencies, for example in endpoint management platforms and Citrix NetScaler gateways.

Key lessons:

  • Third-party infrastructure and management tools can become high-value targets for attackers.
  • Organisations need processes to rapidly evaluate vendor advisories and apply emergency patches or mitigations.
  • Overly complex change control processes can delay urgent security fixes.

Common structural problems in patch management

Beyond individual incidents, several recurring organisational issues cause patching failures:

  • Fragmented ownership – Different teams own servers, applications, OT and cloud resources, leading to inconsistent approaches and conflicting priorities.
  • Lack of risk-based prioritisation – All patches are treated equally, or prioritised only by CVSS score, ignoring real-world exploitability, exposure and business impact.
  • Incomplete asset discovery – Shadow IT, legacy systems and mislabelled assets fall outside regular patch cycles.
  • Change management friction – Strict change windows or fear of downtime result in security patches being postponed repeatedly.

Akamai’s analysis of 2024 breaches estimates that the top 35 incidents alone exposed billions of records and cost organisations billions in fines, much of it tied to failures in basic cyber hygiene such as patch management.

Building a modern, risk-based patch management process

To prevent history from repeating itself, organisations need a structured, risk-based patch management programme.

1. Start with visibility: complete asset and vulnerability data

  • Deploy continuous vulnerability scanning or agent-based tools across on-premises, cloud and remote endpoints.
  • Integrate asset discovery with CMDB or IT asset management systems to maintain up-to-date inventories.
  • Ensure that business owners are mapped to critical systems, so risk and downtime can be evaluated quickly.

DACTA Global’s Vulnerability Monitoring service is designed to provide exactly this continuous visibility, along with prioritised remediation guidance.

2. Prioritise using real-world exploit intel, not just CVSS

  • Use the CISA KEV catalog as a “must-fix” list; KEVs represent vulnerabilities confirmed to be exploited in the wild.
  • Cross-reference with threat intelligence feeds and vendor advisories to identify actively exploited or weaponised vulnerabilities.
  • Consider business context: internet-exposed assets, OT systems and systems holding sensitive data should receive higher priority.

3. Streamline emergency patching procedures

  • Establish clear criteria for when a patch can bypass normal change processes (for example, KEV-listed vulnerabilities or vendor-confirmed active exploitation).
  • Pre-define communication templates for IT, business owners and leadership when emergency patching is required.
  • Maintain lab or staging environments to quickly test critical patches on representative systems.

4. Address legacy and unpatchable systems

  • Isolate legacy systems using network segmentation, strict firewall rules and application gateways.
  • Limit access to a small set of admin accounts with strong MFA and monitoring.
  • Plan for migration or decommissioning as part of medium-term IT strategy.

5. Monitor and measure patch management performance

Track metrics such as:

  • Mean time to remediate (MTTR) for critical vulnerabilities
  • Percentage of KEV vulnerabilities remediated within defined SLAs
  • Number of high/critical vulnerabilities on internet-exposed systems
  • Patch success rates versus failures or rollbacks

Reporting these metrics to senior leadership helps align patching priorities with business risk.

How DACTA Global can help operationalise patch management

For many mid-sized organisations, patch management fails not because of a lack of intent, but because of limited capacity and complex environments. DACTA Global often supports customers by:

  • Implementing continuous Vulnerability Monitoring and integrating KEV-based prioritisation
  • Conducting Risk Assessments to identify which systems represent the highest business impact if compromised
  • Helping design pragmatic change processes that balance availability and security
  • Providing Incident Response support when a vulnerability has already been exploited

Conclusion: from reactive patching to proactive vulnerability management

Patch management gone wrong has already cost organisations worldwide billions in fines, lost revenue and reputational damage. The good news is that most of the underlying issues are solvable with better visibility, prioritisation and governance.

By aligning patch management with threat intelligence, KEV data and business impact, and by simplifying how emergency patches are handled, you can turn patching from a reactive chore into a proactive defence. If you need support designing or operating such a programme, DACTA Global’s vulnerability and risk services are built to help organisations move from sporadic patching to disciplined vulnerability management.

Under attack or experiencing a security incident?

If you're experiencing an active security incident and need immediate assistance, contact the DACTA Incident Response Team (IRT) at support@dactaglobal.com.

You might also be interested in