Living With End-of-Life Software You Can't Retire

Windows 10 reaches end of support next Tuesday, October 14, 2025. After that, unsupported devices get no more security fixes, and every newly discovered vulnerability stays open for good. If you have systems you can't retire by then, the answer is to contain the risk rather than ignore it: find every end-of-life system, isolate it, buy extended support where it exists, add compensating controls, set a dated migration plan and have a named owner formally accept what's left.

That approach works for Windows 10 and for any other end-of-life software you're stuck with. This post covers both.

What happens when Windows 10 reaches end of support?

From October 14, 2025, Microsoft stops providing security updates, non-security fixes and technical support for Windows 10 Home, Pro, Enterprise and Education. Version 22H2 is the final release. Devices will keep booting and running applications. They just won't be fixed.

Windows 10 isn't the only product on that date. Microsoft's list of products reaching end of support on October 14, 2025 also includes Office 2016 and Office 2019, Exchange Server 2016 and Exchange Server 2019, and several other products. Check it against your own estate.

Long-Term Servicing Channel (LTSC) editions of Windows 10 follow their own lifecycle dates, so check those separately if you run them on kiosks or embedded systems.

What are Windows 10 Extended Security Updates for organizations?

Microsoft's Extended Security Updates (ESU) program is a paid annual subscription that keeps delivering critical and important security updates to enrolled Windows 10 devices after end of support. For commercial and educational organizations, it runs for a maximum of three years, to October 2028.

Home users have a separate one-year consumer program, which isn't covered here.

The pricing tells you how Microsoft intends ESU to be used. It's a bridge to buy time for migration, and the cost of standing still doubles every year.

Why do organizations end up with software they can't retire?

Few teams keep old software by choice. The usual reasons:

• Hardware that can't upgrade. Many older PCs don't meet Windows 11's hardware requirements, and replacement budgets don't always line up with vendor deadlines.
• Vendor certification. Lab instruments, production line controllers and specialist equipment often ship with a PC the vendor supports only on a specific operating system.
• Legacy line-of-business applications. An old accounting package, a custom database front end or a thick client whose developer went out of business.
• Cost and disruption. Replacing the software may mean retraining staff, migrating data and revalidating processes.

None of these reasons makes the risk go away. But they're real, and a plan that ignores them won't survive contact with the business.

Step 1: Inventory every end-of-life system

You can't manage exposure you can't see. Build a list of everything that is out of support or will be within the next 12 months. Look beyond Windows 10 to server operating systems, databases, runtimes such as Java and .NET, web frameworks, network appliances and embedded devices.

For each item, record:

• Hostname, location and network segment
• Business owner and technical owner
• What it does and what data it handles
• Why it can't be upgraded or retired
• What it connects to, and what connects to it
• The target date for replacement

Vulnerability scanners and endpoint management tools can usually flag unsupported software automatically. The CIS Controls treat this as basic hygiene: Safeguard 2.2 asks organizations to ensure authorized software is currently supported, and to document an exception for anything that isn't.

Step 2: Isolate and segment

An unpatched system is far less dangerous if nothing hostile can reach it. Isolation is usually the single most effective control you have.

• Move end-of-life systems onto their own network segment.
• Default-deny traffic in both directions, then allow only the specific flows the system needs.
• Block direct internet access. If the system needs an external service, allow that one destination and nothing else.
• Don't let users browse the web or read email on these machines.
• Require administrators to connect through a hardened jump host with multi-factor authentication.

Segmentation also limits the blast radius. If an unsupported machine is compromised through stolen credentials or an unpatched service, a tight segment stops the problem spreading to the rest of the network.

Step 3: Pay for extended support where it exists

For Windows 10, ESU is the obvious option for devices that can't move by October 14. Enroll only the devices that genuinely need it, and treat each license as a line item with an expiry date.

Other vendors sometimes sell extended or custom support for older versions. It's usually expensive, and it's usually worth it for systems that handle sensitive data or can't be isolated well. Before signing, confirm exactly what's covered: security fixes only, or bug fixes too, and at what severity threshold.

Step 4: Contain the application, not the whole machine

Sometimes the old dependency is a single application rather than the whole operating system. In that case, you can often move the application somewhere safer.

• Application virtualization or publishing. Run the legacy application on a supported server platform and present it to users remotely, so the endpoints can be upgraded.
• Virtual machines. Run an old operating system as a virtual machine on a supported, patched host. You gain snapshots, easy rebuilds and tight control over the virtual network.
• Containers. For some server-side applications, packaging the old runtime in a container on a supported host narrows the attack surface and makes the dependency explicit.
• Cloud-hosted desktops. Moving a Windows 10 workload into a hosted desktop service where ESU is included can buy time without new hardware.

None of these makes old code safe. They reduce how much of your environment depends on it.

Step 5: Add compensating controls

When you can't fix the vulnerability, you make it harder to reach and easier to spot. Use this as a checklist for each end-of-life system:

• Application allowlisting so only approved programs can run
• Unneeded software, services and legacy protocols removed or disabled
• No local administrator rights for everyday users
• Endpoint protection that the security vendor still supports on that operating system
• Removable media blocked or tightly controlled
• Logs forwarded to a central system and reviewed
• Sensitive data kept off the device wherever possible
• Tested backups and a documented rebuild procedure
• The last available updates installed

Check your endpoint security vendor's support matrix. Security tools also drop support for old operating systems, sometimes on a different schedule from the operating system itself.

Step 6: Build a migration plan with real dates

A compensating control without an end date quietly becomes permanent. Every end-of-life system needs a plan to leave, owned by someone with the budget to deliver it.

A useful plan includes:

1. A target date, ideally tied to an ESU renewal point or a budget cycle.
2. Dependencies, such as a new application version, a vendor recertification or new hardware.
3. Budget, approved rather than hoped for.
4. Milestones you can track, like pilot complete, data migrated and old system decommissioned.

For Windows 10, the ESU pricing gives you natural checkpoints. Review the remaining population ahead of each annual renewal and ask what it would take to reach zero.

Fix the procurement side too. When buying new specialist equipment or software, ask vendors how long they'll support the underlying operating system and how they deliver security updates. Put the answer in the contract.

Step 7: Document the risk acceptance

Some risk will remain even after isolation and compensating controls. That residual risk needs to be accepted by someone with the authority to accept it, usually the business owner of the process the system supports, not the IT team.

A risk acceptance record should capture:

• The system and why it can't be retired
• The specific risk, in plain language
• Compensating controls in place
• The residual risk rating
• Who accepted it, and when
• An expiry or review date, typically no more than 12 months out

When an auditor or customer asks about unsupported software, this record is your answer. It also forces a conversation at every review about whether the plan is still on track.

Frequently asked questions

Will Windows 10 stop working after October 14, 2025?

No. Devices will continue to run. They'll stop receiving security updates, fixes and support, so newly discovered vulnerabilities won't be patched unless the device is enrolled in ESU.

Can we sign up for Windows 10 ESU later?

Yes, but ESU is cumulative. If you join in the second year, you pay for the first year as well, so delaying the decision doesn't save money.

Is endpoint protection enough to make an unsupported system safe?

No. Endpoint protection helps detect malicious activity, but it can't fix the underlying vulnerabilities. Combine it with isolation, allowlisting and a migration plan.

Does ESU include non-security fixes or new features?

No. ESU delivers critical and important security updates only. If a later application version needs a newer operating system, ESU won't help.

Next steps

With a week to go before Windows 10 support ends:

• Pull a current count of Windows 10 devices and confirm they're on version 22H2.
• Decide which devices will upgrade, which will be replaced and which need ESU.
• Check your estate for Office 2016, Office 2019, Exchange Server 2016 and Exchange Server 2019.
• Move anything that will stay unsupported onto an isolated segment.
• Give every remaining end-of-life system an owner, a migration date and a signed risk acceptance.