The NHS trust’s anecdote is stark and simple: after upgrading thousands of endpoints during the Windows 10 retirement project, Rotherham NHS Foundation Trust still faces a small but stubborn final wedge of clinical devices that cannot move to Windows 11 because suppliers won’t or can’t certify their software — and one vendor quoted the trust £25,000 to make a three‑year‑old device “Windows 11 compatible.”
Background / Overview
The retirement of Windows 10 and the broad push to Windows 11 have become more than an OS migration. For many organizations this is a security, procurement, regulatory and supplier‑management event rolled into one. Microsoft formally ended mainstream support for Windows 10 on October 14, 2025, and now recommends eligible devices move to Windows 11 or enroll in a limited Extended Security Updates (ESU) bridge. Windows 11 imposes a higher baseline of platform security — most visibly the requirement for Trusted Platform Module version
TPM 2.0, UEFI firmware with
Secure Boot, and a narrow set of supported CPU families — which has left many otherwise healthy PCs ineligible for an official in‑place upgrade. That compatibility gate is the proximate cause of the bottleneck hitting sectors that run long‑lived, certified devices such as healthcare, industrial control systems and specialized manufacturing equipment. Community reporting and forum threads from IT professionals track real‑world pains: OEM firmware limits, bespoke legacy applications tied to a specific OS, and small specialist vendors who either lack the engineering resources to re‑certify software or choose not to for cost reasons. These dynamics produced the Rotherham example: a quoted retrofit cost that would be a material, unplanned expense for procurement teams and an operational headache for clinicians.
Why this is happening: the technical gatekeepers
Windows 11’s security baseline — non‑negotiable requirements
Windows 11’s enforced minimums are not cosmetic. The platform is design‑centered on hardware‑rooted protections and virtualization‑based mitigations that depend on TPM 2.0, UEFI Secure Boot, and supported CPU families. The most relevant, practical blockers are:
- TPM 2.0 (discrete or firmware fTPM/PTT). Many motherboards have TPM disabled by default, and older systems lack an upgrade path.
- UEFI with Secure Boot required or required to be available — legacy BIOS/MS‑DOS MBR configurations can block installs.
- Processor family constraints — Microsoft’s supported CPU lists exclude many mid‑2010s processors, creating hard exclusions beyond TPM/UEFI toggles.
- Minimum RAM and storage (4 GB / 64 GB) and DirectX 12 / WDDM 2.x requirements are rarely the main blocker but do matter in some embedded or thin clients.
These requirements materially shrink the set of devices eligible for a supported upgrade, and the remediation actions (BIOS updates, MBR→GPT conversion, hardware retrofits) are non‑trivial at scale. Microsoft and its documentation make these baseline requirements explicit.
Why medical and industrial devices are different
Medical devices, industrial control systems (ICS) and specialized lab instruments are typically delivered with a validated combination of hardware, firmware and
certified software. That certification — often required by regulators, internal clinical safety governance or contractual warranties — binds the vendor to a specific OS baseline.
- Many device vendors certify their software against a precise Windows build and driver stack and then test interaction with physical hardware under regulated conditions. This is a slower, more conservative lifecycle than commodity PC hardware.
- Updating a device’s host OS can trigger re‑validation, retesting, and in some cases regulatory notifications or conformity processes that take months. Suppliers may therefore delay or decline certification for new OSes until they can complete exhaustive testing.
This is not mere vendor foot‑dragging in all cases — for some devices the software‑hardware coupling is safety‑critical and legally significant. But the combination of cost, time and regulatory friction produces brittle outcomes: patients and clinicians can be left balancing clinical availability against cyber risk.
The NHS example: Rotherham and the £25,000 quote
The Rotherham NHS Foundation Trust upgraded roughly 98% of its Windows estate to Windows 11, but found that about 2% of devices remained blocked because the supplier software was not yet compatible. In one publicized instance a supplier reportedly quoted
£25,000 to retrofit a three‑year‑old medical device to work with Windows 11. The trust has isolated non‑upgraded systems to reduce cyber exposure while negotiating remediation with vendors. That figure crystallizes the policy tensions:
- Hospitals buy certified, high‑value medical equipment with long expected useful lives and often long warranty periods.
- Device vendors may charge for retrofits, cite regulatory testing costs, or choose to require full device replacement rather than reengineering older units.
- The trust’s risk posture cannot simply permit continuing network connectivity of unpatched Windows 10 hosts without compensating controls — the legacy threats seen in NHS incidents like WannaCry create real operational risk for patient care.
The economic and operational calculus
The blunt options
- Upgrade to Windows 11 where possible (free in‑place upgrade for eligible devices). This is the long‑term security‑first path but requires firmware/driver testing and application compatibility validation.
- Buy Extended Security Updates (ESU) as a temporary bridge. For consumers Microsoft offered a one‑year consumer ESU pathway and businesses have tiered ESU pricing across multiple years. ESU is a short, costed breathing space, not a final solution.
- Replace device hardware or buy new, Windows 11‑compatible equipment. Practically certain to maintain support but expensive and slow.
- Rehost legacy software in a controlled environment (virtual machine, Windows 365 or Azure Virtual Desktop) to decouple the certified application from the host hardware. This can be an engineering win but has performance, latency and procurement implications.
ESU: bridge, not balm
Microsoft’s ESU options were widely reported and debated. For consumers a one‑year ESU was made available, with enrollment mechanisms tied to Microsoft account sync in some free paths; for enterprises the ESU pricing ladder rises year‑over‑year. These choices change the risk calculus: paying for ESU may be cheaper than large‑scale forklift replacements in the short term, but the program is deliberately finite and not a substitute for migration planning.
Hidden costs hospitals must budget
- Vendor retrofit fees — as Rotherham’s quote illustrates, vendors may charge high fees for re‑validation or to ship updated firmware and software components.
- Clinical safety testing — retesting integrated clinical workflows after an OS upgrade consumes clinical engineering time and may require facility downtime.
- Procurement & inventory friction — large trusts may have thousands of devices with staggered lifecycles; replacing a portion of that estate in a hurry is a supply‑chain and logistics challenge.
Security and compliance risks
Running unsupported OS instances or delaying upgrades carries concrete regulatory and insurance implications. Unsupported machines do not receive regular OS‑level security patches, which increases exposure to remote code execution, privilege escalation and firmware‑level attacks — precisely the failure modes Windows 11’s baseline is intended to mitigate. Auditors and cyber‑insurers increasingly expect demonstrable patching or compensating controls for regulated environments such as healthcare. Failure to remediate or isolate legacy devices can:
- undermine compliance with data protection safeguards;
- increase the likelihood of ransomware or supply‑chain intrusions;
- erode insurer coverage if a managed control baseline is not maintained.
Vendor behavior, contracts and regulatory friction — the systemic problem
Three structural failure modes drive the uneven outcomes we’re seeing:
- Procurement contracts that lack long‑term OS portability clauses. Many device purchase agreements focus on initial acceptance testing and fail to require affordable long‑term OS compatibility or clear upgrade‑path obligations. This leaves trusts negotiating ad‑hoc retrofits.
- Regulatory testing timelines. Changes to software that interacts with medical hardware often trigger formal safety‑case work with regulators (for example the MHRA in the UK). That extra step is necessary but slow — vendors may opt for conservative timelines.
- Small‑vendor resource constraints. Many specialist medical or industrial device vendors are small and may not have the engineering bandwidth to rework legacy product lines for a new OS baseline. The economic calculus for them can favor new‑product development over retrofits.
These systemic issues mean IT teams and procurement officers are negotiating a tripwire: clinical safety, vendor economics and cyber risk.
Practical mitigations for IT and clinical engineering teams
Immediate (0–30 days)
- Inventory and classification: record device model, OS build, CPU, TPM status, network exposure and clinical criticality. This is the single most valuable dataset you can produce.
- Segmentation and quarantining: isolate devices that cannot be upgraded or certified into restricted VLANs or air‑gapped enclaves, and limit which hosts can reach them. Rotherham has used quarantining as a short‑term control.
- Prioritize patient‑critical systems: keep the highest priority devices either in the most secure enclaves or target them for remediation first.
Short‑term (1–3 months)
- Engage vendors formally with timelines and contractual levers. Demand vendor remediation plans and firm cost estimates for certification activities. Escalate in procurement if necessary.
- Evaluate ESU selectively: buy time for the small subset of devices that cannot be remediated quickly, but budget the eventual migration costs.
- Validate virtualization and rehosting paths: test moving legacy clinical apps into a supported VM or cloud‑hosted Windows instance to decouple software compatibility from host hardware.
Medium term (3–18 months)
- Replace and modernize where necessary using staged procurement and trade‑in programs to reduce e‑waste.
- Rewrite procurement templates for future purchases to insist on OS portability, upgrade commitments and defined remediation SLAs — build the upgrade path into the contract lifecycle.
- Improve device lifecycle governance with a central medical device asset register, firmware management plan and scheduled vendor certification windows.
Alternatives and tradeoffs
- Cloud desktops (Windows 365 / AVD): host the certified Windows environment centrally and provide thin clients locally. Pros: faster compliance, centralized patching. Cons: licensing, latency, and clinical device integration complexity.
- Switch to Linux / ChromeOS Flex for non‑clinical endpoints: reuses older hardware and avoids Microsoft lifecycles. Pros: lower cost and longer life. Cons: application compatibility and peripheral driver gaps.
- Maintain Windows 10 with ESU: buys time but creates a multi‑year commercial and operational cost; does not remove the vendor certification problem for devices that cannot ever be upgraded.
Critical analysis — what works, what risks remain
Strengths of Microsoft’s approach
- Clear security baseline. Requiring TPM 2.0, Secure Boot and a modern CPU list raises the default difficulty for firmware‑level and supply‑chain attacks — an advantage for organizations concerned about advanced persistent threats.
- A defined lifecycle and a purchasable ESU bridge. Microsoft’s ESU options provide a predictable, temporary commercial path for organizations needing time to migrate.
Weaknesses and unintended consequences
- Vendor and regulatory friction. Specialized device ecosystems are ill‑suited to abrupt platform shifts; vendors’ certification cycles, regulatory retesting and small engineering teams create an asymmetric burden on buyers. The Rotherham example exposes the real cost of that asymmetry.
- Environmental and equity impacts. Forced refresh cycles increase e‑waste and hit underfunded institutions and lower‑income users hardest. Advocacy groups warned about these distributional effects during the migration rollouts.
- Fragmentation risk. A mixed estate with some devices on ESU, some upgraded, and some isolated increases operational complexity and may create network attack vectors if compensating controls are imperfect.
Unverifiable or uncertain claims — flagged
- Industry estimates of the total number of devices that cannot upgrade to Windows 11 vary widely; numbers like “400 million” appear in some analyses but are estimates built from differing methodologies and should be treated as indicative rather than definitive. Planning must rely on internal inventories rather than headline device totals.
What procurement teams, CISOs and clinical engineers should demand next
- Contractual upgrade clauses: require explicit vendor commitments to maintain compatibility with future OS baselines or provide affordable retrofit options.
- Transparency on certification process and timelines: vendors should publish timelines and costs for re‑certifying devices against new OS releases.
- Regulatory engagement: health regulators and procurement authorities should provide clear, expedited pathways for software updates that preserve clinical safety while minimizing unnecessary replacement.
Conclusion — pragmatic priorities for the next six months
The migration to Windows 11 is fundamentally a systems problem: it touches firmware, vendors, procurement, clinical safety and cyber risk all at once. Rotherham’s experience — where the trust has upgraded the large majority of its estate and is now stuck on a small set of certified devices — is the story of the months ahead for many healthcare and industrial organizations. The trust’s remedy path — quarantining non‑upgraded devices, negotiating with suppliers and selectively using short‑term ESU — is the practical route for now, but it will require sustained procurement reforms, vendor accountability and realistic budgets to finish the job.
Immediate priorities should be: finalize an authoritative asset inventory, isolate legacy clinical endpoints, insist on vendor remediation roadmaps with contractual teeth, and budget for a combination of targeted hardware refreshes and virtualization rehosting where that preserves clinical workflows. These steps will not be cheap or quick, but they convert an intractable liability into an auditable, funded program — and they reduce the chance that a small technical incompatibility turns into a patient‑facing outage or a costly cyber incident.
For teams standing between clinicians and devices: treat Windows 10’s retirement as a project with measurable phases and deliverables, not simply an IT ticket; hold vendors to upgrade commitments or sensible retrofit pricing; and plan procurement and clinical safety together so that the next platform transition is less about crisis management and more about managed, risk‑aware modernization.
Source: Computerworld
Industrial and medical devices struggle to upgrade to Windows 11