Why Windows 10’s end of support split every hospital fleet in three

The week

On October 14, 2025, Microsoft ended support for most editions of Windows 10, the operating system that had run on a vast number of office computers for years. An operating system is the foundational software that every other program on a computer relies on. “End of support” means the manufacturer stops fixing it. From that date, those editions stopped receiving security updates, the regular repairs Microsoft ships when it finds a weakness that attackers could use.

There was one way to keep the repairs coming: enroll the device in Microsoft’s paid Extended Security Updates program, known as ESU. For commercial customers, Microsoft priced that program at $61 per device for the first year, doubling in each of the two following years. It was designed as a bridge: affordable for a while, deliberately expensive if used for long.

Not every Windows 10 machine hit the same deadline. Long-Term Servicing Channel editions, usually shortened to LTSC, kept their own later end dates. LTSC is a version of Windows built for machines that should change as little as possible, such as the computers inside specialized and embedded equipment. Those editions are common in factories, laboratories and hospitals.

The October date had been public for years. Even so, many organizations reached it with Windows 10 machines still in service. Some had simply run out of time or budget. Others had machines that could not easily be moved at all.

Healthcare was among the sectors where the remaining machines were hardest to move, because many of them were attached to clinical equipment. A hospital’s computers sit inside imaging systems, run laboratory analyzers and display patient monitoring data as well as standing on desks. Many of those machines are not the hospital’s to change freely, and some do not clearly belong to anyone. For a hospital chief executive, the week turned a familiar IT refresh into a much harder question: which of our computers can we actually fix, and who is responsible for the ones we cannot?

Suppose a hospital board meets in the autumn of 2025. The chief information officer presents a slide on the Windows 10 deadline. It shows a single bar, mostly green, labeled “migrated.” The board nods and moves on. The slide does not show that the remainder includes the computer that runs the hospital’s main CT scanner, a dozen machines in a research lab nobody in IT has visited, and several PCs at an affiliated physician practice that connect to the hospital’s network every day.

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, the industry’s word for any computer or device at the edge of the network, 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.

A computer that still works but no longer gets fixed

Software is never finished. Every operating system contains mistakes, and some of those mistakes let attackers break in. While a product is supported, the manufacturer finds and fixes those weaknesses and ships the fixes as security updates, usually monthly. When support ends, the fixes stop. The computer keeps working exactly as before, which is what makes the risk easy to ignore. Nothing visibly breaks. Month by month the machine becomes easier to attack, because every newly discovered weakness stays open for good.

For a single office PC that might be tolerable. For thousands of machines in a building full of patients, the calculation changes.

Microsoft offered two ways around the deadline. The first was to move to Windows 11, which has stricter hardware requirements, so older machines often need replacing rather than upgrading. The second was to pay for Extended Security Updates. ESU was priced at $61 per device for the first year for commercial customers, doubling in each of the two following years, and organizations that join late must pay for the years they skipped. Specialized LTSC editions kept their own later end dates, which helped some equipment but did not change the general picture.

Most industries could stop there: replace what you can, pay for a bridge for the rest, finish within a year or two. Hospitals had a harder version of the problem because of who controls their machines.

Group one: machines IT controls

Nurses’ station PCs, registration desks, back-office laptops and workstations-on-wheels (the rolling carts clinicians push from room to room) running the electronic health record client make up the straightforward group. The electronic health record, or EHR, is the hospital’s central patient record system; the “client” is the program on each computer that lets staff use it. The work here 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 rather than the operating system. Peripherals are the devices plugged into the computer: label printers, badge readers, barcode scanners, signature pads and dictation microphones. Each depends on drivers and middleware, small pieces of software that let the computer talk to the device. A new operating system can break that conversation without anyone noticing until a nurse tries to print. A workstation that cannot print a specimen label is a patient safety issue, because a blood sample without the right label may be mixed up, delayed or drawn again.

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. That small investment turned a potential ward-level disruption into a ten-minute swap.

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 become the destination by default.

Group two: 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 (a CT scanner, an MRI machine or an X-ray system), the controller for a laboratory analyzer, the PC behind a physiological monitoring system. These computers look like ordinary PCs, but they are components of regulated equipment.

The hospital owns the hardware. The manufacturer validates the software configuration, meaning it has tested and documented that the device works safely with that exact combination of software. Applying an operating system change the manufacturer has not validated can void support and take the device outside the configuration the manufacturer validated. An aircraft engine works the same way: the airline owns it, but it cannot fit unapproved parts and keep flying under the manufacturer’s warranty and approvals.

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. A scanner that cost a large share of a department’s capital budget does not get replaced because a software company changed a date.

The practical controls are the ones already used for older systems, and they will be in place for years:

• Segmentation. Put these devices on separate networks that allow only the flows they need, so that even if one is compromised, an attacker cannot easily reach anything else.
• Controlled vendor access. Limit the manufacturer’s remote access to brokered, logged sessions that a hospital employee approves, rather than a permanent open connection.
• Application allow-listing. Where the manufacturer supports it, configure the computer to run only a pre-approved list of programs, so unfamiliar software will not start.
• An honest inventory. 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. They are standardized questionnaires in which manufacturers describe a device’s security features, including what software it runs.

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.

Group three: 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 (the outside firms that handle billing and collections), 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, the software IT uses to track and update its own machines, 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: the network checks each device as it plugs in, recognizes what kind of machine it is, and sends anything outdated to a quarantined area. Passive network monitoring tools used for medical device discovery, which listen to network traffic without touching the devices, can do the same on clinical networks.

For this group, end of support is mainly a third-party risk matter. Affiliate and vendor access agreements should require supported software, give the health system a right to verify it, and set 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. A virtual desktop is a computer session that runs inside the hospital’s data center and is merely displayed on the affiliate’s screen.

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.

Three answers on one cardiology floor

The three groups are easier to grasp on the ground than on a slide. Take a single cardiology floor at a community hospital and count the Windows machines on it.

At the nurses’ station there are four desktop PCs and six workstations-on-wheels, all running the EHR client. Each has a label printer or a barcode scanner attached, and one has a signature pad used for consent forms. These belong to IT. They can be replaced, tested and rolled out over a weekend, provided the unit manager has signed off that every printer and scanner still works. They are group one.

Down the corridor is the cardiac catheterization lab. Its imaging system is driven by a workstation that looks like any other PC but was supplied, configured and validated by the equipment manufacturer. Beside the patient beds, a central monitoring station displays heart rhythms from every room; it too runs on a Windows computer the manufacturer controls. Nobody in IT may simply upgrade these. Their fate depends on what the manufacturer offers and when. They are group two.

In a side office, a cardiologist from an affiliated practice logs in from a laptop the practice bought and manages. A dictation service supplied a small computer that sits under a desk and sends recordings to an outside transcription firm. A research coordinator runs a study instrument on a PC bought from a grant two years ago. Each of these touches the hospital’s network. None appears in IT’s management console. They make up group three.

So one floor gives three different answers to the question “are we off Windows 10?” The nurses’ station can say yes. The catheterization lab can say “not yet, and not on our timetable, but here is how we protect it.” The side office can, at first, say only “we don’t know.” Multiply that floor by every unit in a health system and the case for reporting three lines instead of one makes itself. The people who must act include the unit manager, the head of clinical engineering, the research office and whoever manages affiliate contracts, as well as the IT department.

What the board needs to see

An unsupported computer is not dangerous on its own. It becomes dangerous when attackers find a weakness in it and nobody will ever fix that weakness. In a hospital, the consequences of an intrusion are measured in diverted ambulances, postponed procedures and clinicians working from paper, as well as in data breaches and regulatory inquiries.

The costs also behave differently across the three groups. Group one is a capital and project cost with a clear end. Group two is a long-running operating cost: segmentation, monitoring and eventually equipment replacement on a timetable the manufacturer partly sets. Group three is mostly a contractual and governance cost, paid in negotiation and oversight rather than hardware.

Regulators and insurers increasingly ask hospitals to show that they know what is on their networks and how each item is protected. A single percentage does not answer that. Reporting the three groups separately gives a board or risk committee an honest picture: 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.

A three-line report, and the ways a single line misleads

Suppose a regional health system handled the deadline well. Its board report would have three lines, not one. The first would show general-purpose machines migrated, with a small, shrinking number on ESU and a retirement date for each. The second would list device-tethered machines by department, each with its manufacturer’s stated support position, its network segment and a note on whether vendor remote access was brokered. The third would show affiliate and vendor machines discovered by network access control, the contracts that covered them and the number moved to a restricted segment. Clinical engineering, IT and the contracts team would each own a line.

The failures were the mirror image. Some organizations reported a single migration percentage, which looked reassuring and told the board nothing about where risk remained. Some bought ESU for everything that was left and stopped there, turning a bridge into a habit. Some upgraded a device-tethered PC without the manufacturer’s approval and discovered they had lost support for an expensive piece of equipment. Some never looked at the affiliate practices and research labs at all, because no one had been told those machines were theirs.

A less visible error was treating the deadline as purely an IT event. The hardest decisions sat with procurement, clinical engineering, research administration and the legal team that negotiates vendor contracts. Where those groups were absent from the planning, the plan covered only group one.

Where the Windows 10 risk sits now

1. How many of our Windows 10 machines are in each of the three groups: IT-managed, built into medical devices, and belonging to affiliates, vendors or research?
2. Which machines are on Extended Security Updates, and what is the planned retirement date for each one?
3. For each device-tethered machine, what has the manufacturer said about support, and is it on a segmented network with brokered vendor access?
4. Do our medical device purchase and service contracts say who pays to move the device to a supported platform, and how much notice we get?
5. Would we know if an unsupported machine from an affiliate practice or a vendor connected to our network tomorrow?

With hindsight

The first group has reached 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. For a chief financial officer, this is a rare case where the security argument and the budget argument point the same way: the longer the bridge is used, the more it costs, so the incentive is to finish rather than renew.

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. That reframing matters for boards: a line that says “in progress” for five years erodes confidence, while a line that says “accepted risk, controlled this way, reviewed on this date” shows that someone is in charge. It also points the real fix toward procurement, where future contracts can settle who pays when the next operating system reaches its end.

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. A hospital that went looking for unsupported Windows machines in October 2025 ended up with a better map of everything connected to its network, which is worth far more than the original exercise.

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. Hospitals that took the broader view will find the next deadline, whichever product it comes from, far easier to handle.