Retrospective note. The original 6 January 2017 date is retained. The March patch and May attack described below occurred later that year.
Microsoft issued security bulletin MS17-010 on 14 March 2017. WannaCry began spreading on 12 May, reaching more than 200,000 computers across at least 100 countries in a matter of days. In England, at least 80 of 236 NHS trusts were affected. Of those trusts, 34 were infected and 46 were not infected but reported disruption. A further 603 primary care and other NHS organisations were infected, including 595 GP practices. The patch had been available for eight weeks. That interval, not the malware, is the story, and it is the story every ERP patching conversation has been having ever since. The systems that stayed unpatched longest were rarely the ones nobody cared about. They were the ones that mattered most: the manufacturing execution system connected to the production line, the ERP application servers that finance depends on, the terminals attached to medical or industrial equipment, the integration servers that would break something downstream if they restarted. High criticality had become, perversely, a reason not to patch.
Why business-critical means unpatched
The logic that produces this outcome is entirely rational at each step, which is why it is so durable. A patch requires a restart. A restart requires a maintenance window. A maintenance window on the ERP requires agreement from finance, operations, warehousing and anyone running a batch job, which means coordination weeks in advance. Before the window, the patch should be tested against the ERP's customisations and integrations, because vendors certify their software against specific configurations and a patch that breaks a custom interface at month-end is a worse outcome than a vulnerability nobody has exploited yet. Testing requires an environment that matches production, which many organisations do not have, and time from people who are busy. So the patch waits. And the next one waits behind it. Within a year the system is far enough behind that catching up is a project rather than a task, which makes it easier to defer again — and now there is a genuine technical argument for deferral, because the cumulative change is large enough to be risky. The second mechanism is vendor certification. Enterprise application vendors specify supported operating system and database versions, and support can be withdrawn if you deviate. This gives organisations an apparently authoritative reason to stay on an unsupported platform: "the ERP vendor does not certify that version." It is frequently true, sometimes out of date, and almost always worth challenging directly rather than accepting as received wisdom from an implementation partner. The third is simply that nobody owns the decision. Security raises the risk, the application owner raises the availability risk, and in the absence of a forum where those two are weighed by someone accountable for both, the default outcome is inaction. Inaction favours availability, because an outage is visible and a vulnerability is not.
Reframing the trade-off
The genuine insight from 2017 was that the availability argument had been reasoning about the wrong risk. Deferring a patch to protect uptime treats the four-hour maintenance window as the cost and zero as the alternative. The actual alternative is not zero. It is a probability-weighted multi-day or multi-week outage with data loss, forensic costs, regulatory notification, customer impact and a recovery that runs on whatever your backups actually restore — which, in the organisations that lived through it, was usually less than the runbook claimed. Stated that way, a planned four-hour window is not a cost of security. It is insurance purchased at a known price against an unknown one. That framing is the argument that actually moves ERP owners, because it speaks in their currency rather than in the security team's.
What the organisations that fixed it did
Four things, consistently. They scheduled windows in advance for the year. A standing monthly or quarterly window in the operational calendar, agreed once, removes the per-patch negotiation that kills patching programmes. The window exists whether or not it is needed; the argument is had once rather than twelve times. They built a test environment that actually resembles production. Not a scaled-down sandbox with stale data — an environment with the same integrations, the same customisations and refreshed data, so that testing a patch is a two-day exercise rather than a project. This is the expensive part and it is what unblocks everything else. They separated the patch decision from the patch schedule. Critical, remotely exploitable vulnerabilities in internet-reachable or laterally-reachable systems get an emergency path with a defined authority to invoke it. Everything else waits for the window. Without that distinction, either everything is an emergency or nothing is. They compensated where patching genuinely was not possible. Some systems cannot be patched — equipment-attached workstations, vendor-locked appliances, systems awaiting replacement. Those get network isolation, strict egress control, removal of unnecessary services and heightened monitoring, documented as an accepted risk with a named owner and a review date. "Cannot patch" is a valid position; "cannot patch and did nothing else" is not.
| Control | Purpose |
|---|---|
| Standing maintenance windows | Remove repeated negotiation over each patch schedule |
| Production-like test environment | Check customisations and integrations before deployment |
| Named emergency authority | Separate urgent exposure decisions from the routine schedule |
| Compensating controls | Isolate genuinely unpatchable systems, restrict access and record an owner and review date |
| Restore testing | Check that recovery assumptions hold before accepting deferral risk |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for ERP Patch Strategy Review
- Put standing maintenance windows in the annual operating calendar. Negotiating each window individually is the single biggest cause of patch backlog.
- Fund a production-like test environment before anything else. Every other improvement depends on being able to test a patch quickly and credibly.
- Define an emergency path with named authority to invoke it. Remotely exploitable, actively exploited, internet-reachable — those three conditions should bypass the normal cycle.
- Challenge vendor certification claims directly with the vendor. Partner-relayed "not supported" statements are often stale, and the real position is frequently more permissive.
- Inventory what genuinely cannot be patched and isolate it. Network segmentation, egress filtering and monitoring are the substitute control, documented with an owner and a review date.
- Measure time-to-patch by criticality, not patch counts. The metric that predicts exposure is how long a critical vulnerability stays open on an exposed system.
- Test the restore, not just the backup. The recovery assumption in every deferral decision is the one least often verified.
- Cost the deferral in outage terms and put it in front of the ERP owner. A four-hour planned window against a multi-day unplanned one is the argument that changes behaviour.
The Regional Dimension
Several Gulf-specific factors make this harder here than the generic advice assumes. The integrator model is the first. A large share of regional ERP estates are implemented and operated by systems integrators under multi-year managed service contracts, and patching is frequently a scheduled service line rather than an owned function. The practical consequences: patch cadence is whatever the contract specifies, emergency patching may be a change request with commercial implications, and the customer often cannot answer basic questions about patch state without asking the partner. Any regional patch strategy has to start by reading the contract — what cadence is committed, who can invoke an emergency change, and what it costs. Heavy customisation compounds it. Regional implementations carry substantial localisation and bespoke development: Arabic and bilingual document handling, wage protection system payroll files, gratuity and end-of-service calculations, VAT and now e-invoicing clearance integrations with the tax authority, agency and distributor rebate structures, and multi-entity consolidation across free zone and mainland entities. Every customisation is a regression testing obligation, and estates with years of accumulated local development test slowly, which lengthens every patch cycle. The operating calendar is genuinely different and needs planning around. Weekend days differ across regional markets, which narrows the common window for a group operating in several countries. Ramadan brings reduced working hours and, for retail, hospitality and logistics, the busiest trading period of the year. Major national holidays, the Hajj period and quarter-end regulatory filings all constrain the calendar further. Setting windows a year ahead matters more here than in a single-country operation, because the genuinely available slots are fewer. Two further points. Regulatory expectation has risen sharply: national cybersecurity authorities in the UAE and Saudi Arabia, and the central bank frameworks applying to financial institutions, set explicit vulnerability management and remediation timeframe requirements, which has converted patching from an IT preference into an auditable obligation for regulated entities. And the region's exposure to destructive attacks is not theoretical — the Shamoon-era wiper campaigns against regional energy and government targets remain the reference point, and they are the reason a "we are not a target" argument gets less traction in a Gulf boardroom than it does elsewhere.
The objection worth taking seriously
The strongest counter-argument is that aggressive patching has its own failure mode, and security teams rarely account for it honestly. Patches break things. Vendor updates have caused outages, data corruption and application failures often enough that operations teams' caution is evidence-based rather than obstructive. An organisation that patches immediately and without testing will eventually take an outage caused by the patch, and when that happens the security argument loses credibility for years. The correct position is not "patch faster" — it is "be able to patch faster", which is an investment in test environments, automation and rollback capability, not an instruction to take more risk. There is also a fair point about proportionality and resourcing. A mid-market organisation with a small IT team cannot run a full test environment, a formal change advisory process and a monthly window across every system. For them the realistic version is narrower and still effective: patch anything internet-facing on a short cycle, patch endpoints and email automatically, segment the systems you cannot patch, and accept a slower cycle on internal application servers that are not reachable from the internet or from a compromised laptop. The failure in 2017 was rarely that organisations patched slowly — it was that flat internal networks let a worm reach systems that should never have been reachable. And a scoping caution: patching is one control among several, and an organisation with perfect patch compliance and no segmentation, no privileged access management and no tested backups is still fragile. WannaCry spread over a protocol that had no business being open across an entire hospital network. The patch was the fix that week; the network design was the underlying problem.
Common Questions
How quickly should critical ERP patches be applied?
Set the target by exposure rather than by a single number: internet-reachable systems in days, internally reachable application servers within the next scheduled window, and isolated systems on a documented longer cycle. What matters is having a defined target per tier and measuring against it.
What if the ERP vendor does not certify the patched platform?
Escalate to the vendor directly rather than accepting a partner's summary, ask for the timeline to certification, and if the gap is real, apply compensating controls and record it as an accepted risk with an owner and a date. Do not let an uncertified state drift into a permanent one.
What is the highest-value investment for a slow patching programme?
A production-like test environment. It converts patching from a risk-laden project into a routine task, and everything else — cadence, emergency response, confidence — follows from it.
Has AI changed patch management?
Meaningfully, on both sides. Exploitation timelines have compressed: automated tooling turns disclosed vulnerabilities into working exploits far faster than the eight weeks that separated MS17-010 from WannaCry, which squeezes the window that patch programmes were designed around. Defensively, AI is genuinely useful for prioritisation — correlating vulnerability data with actual exploitation activity and your own asset exposure produces a far better ranking than severity scores alone, and exploit-prediction and known-exploited-vulnerability feeds have made "which of these 4,000 findings matter this week" an answerable question. It also helps with regression testing, which is the real bottleneck in ERP patching: generating and maintaining test coverage for customisations is exactly the kind of tedious work that now has decent tooling. The caution is that AI-assisted change should not shorten the verification step; faster analysis is useful, faster untested deployment is not.
ERP Patch Strategy Review — the patch existed for eight weeks before WannaCry; the fix is a standing window and a test environment, not a faster decision.