Why Windows 10’s end of support split every hospital fleet in three
Hospital endpoints fell into machines IT controls, machines device makers control and machines nobody clearly controls. Reporting them as one migration hid where the residual risk sat, and only the first group had a simple answer.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On October 14, 2025, Microsoft ended support for most editions of Windows 10. From that date, those editions stopped receiving security updates unless the device was enrolled in the paid Extended Security Updates program. For commercial customers, Microsoft priced that program at $61 per device for the first year, doubling in each of the two following years. Long-Term Servicing Channel editions, common on embedded and specialized systems, kept their own later end dates.
The date had been public for years. Even so, many organizations reached it with Windows 10 machines still in service. Healthcare was among the sectors where the remaining machines were hardest to move, because many of them were attached to clinical equipment.
End of support is usually run as a refresh project: buy hardware that meets Windows 11 requirements, migrate users, retire old devices. In a hospital that description fits only part of the estate. The October 2025 deadline sorted endpoints into three groups with different owners and constraints. The first is general-purpose machines that IT controls. The second is machines whose software configuration a medical device manufacturer controls. The third is machines in the gaps between organizations. A single migration plan applied to all three produces a misleading status report, because progress on the first hides the risk in the other two.
Machines IT controls
Nurses’ station PCs, registration desks, back-office laptops and workstations-on-wheels running the electronic health record client make up the straightforward group. The work is familiar. Check hardware eligibility, replace or upgrade, validate the EHR client, and roll out in waves that avoid clinical peaks such as winter surges.
The binding constraint here is peripheral validation and clinical scheduling, not the operating system. Label printers, badge readers, barcode scanners, signature pads and dictation microphones all depend on drivers and middleware. A workstation that cannot print a specimen label is a patient safety issue. Health systems that finished on time treated peripherals as first-class test items, with a sign-off from each clinical department that uses them. They also kept a small pool of pre-built Windows 11 devices on each unit for same-day swaps when a validation surprise appeared.
For machines that could not be replaced in time, Extended Security Updates were a sensible bridge. The price doubles each year, and Microsoft requires organizations that join late to pay for the years they skipped. That gives finance a clear reason to finish within the first year rather than renew. ESU enrollment should be tracked per device, with a planned retirement date, so the bridge does not quietly become the destination.
Machines the device maker controls
The harder group is the Windows computer that forms part of a medical device: the workstation driving an imaging modality, the controller for a laboratory analyzer, the PC behind a physiological monitoring system. The hospital owns the hardware. The manufacturer validates the software configuration. Applying an operating system change the manufacturer has not validated can void support and alter the device’s cleared configuration.
The hospital’s options therefore depend on the manufacturer’s roadmap. Some manufacturers offered Windows 11 or an LTSC build, often tied to a hardware upgrade or a new service contract. Others offered nothing short of replacing the modality, which may have years of clinical life left. Neither answer arrives on Microsoft’s schedule.
The practical controls are the ones already used for older systems. Segment these devices onto networks that allow only the flows they need. Limit vendor remote access to brokered, logged sessions that a hospital employee approves. Use application allow-listing where the manufacturer supports it. Record each device’s operating system, its patching owner and the manufacturer’s stated support position in the clinical engineering inventory. Manufacturer Disclosure Statements for Medical Device Security, the MDS2 forms many vendors publish, are a useful starting point for that record.
Procurement can prevent the next round. A modality expected to run for ten years will outlive at least one Windows release. The purchase agreement should state who pays to move it to a supported platform when that happens, and how much notice the manufacturer must give. Capital planning should carry the replacement cost of devices the manufacturer will not update.
Machines in the gaps
The third group is the easiest to miss: devices that touch the health system’s network or data without belonging clearly to its IT department. Examples include PCs at affiliated physician practices, machines supplied by transcription or revenue-cycle vendors, waiting-room kiosks and equipment in research labs with their own budgets.
Ownership is the first problem. Visibility is the second. A device that does not report to the health system’s endpoint management tools has an unknown operating system until someone looks. Network access control that fingerprints connecting devices can find unsupported Windows versions and move them to a restricted segment. Passive network monitoring tools used for medical device discovery can do the same on clinical networks.
For this group, end of support is mainly a third-party risk question. Do affiliate and vendor access agreements require supported software? Is there a right to verify it, and a consequence when it fails? Remote access for affiliates through virtual desktops removes much of the dependency, because the affiliate’s own machine never joins the network.
Research labs need their own treatment. Instruments bought on grant funds often run Windows builds chosen by the instrument maker, sit on the hospital network and fall outside both IT and clinical engineering budgets. A joint register held by research administration and IT, reviewed when grants are awarded, keeps them from becoming the next unknown fleet.
Reporting the three groups separately gives a board or risk committee an honest picture. It shows what has been migrated, what is protected by segmentation and contracts, and what is still unknown. Each group needs its own owner and its own target state. Only the first has a target of zero.
With hindsight
A year later, the first group has the clearest end point. The ESU price doubles in late 2026, which gives every health system a financial reason to finish its general-purpose migration. The second group is a long tail. Device-tethered Windows 10 machines will remain in hospitals for years, protected by segmentation rather than patches. They are better reported as a managed exception with compensating controls than as a migration still in progress.
The third group is where the deadline had its most useful side effect. Finding unmanaged devices and tightening affiliate and vendor access requirements pays off in third-party risk reviews and in incident response, where an unknown device is often the starting point. An operating system deadline works well as a forcing function for an ownership review. Treated only as a hardware refresh, it leaves the riskiest machines exactly where they were.