Operating System End of Life and Extended Support Guide: deciding between upgrade, paid support and isolation

When an operating system reaches end of support, every vulnerability found afterwards stays open for good unless you have paid for extended updates, and most organisations discover their unsupported systems only after the date has passed. In the last two years Windows 10, CentOS Linux 7 and RHEL 7 maintenance, and Ubuntu 20.04 standard support all ended, and the final extended updates for Windows Server 2012 R2 stopped on 14 October 2026. This guide explains the vendor lifecycle models, what paid extended support does and does not include, how to decide between upgrade, extended support and isolation, and how to run the programme and measure it. It is for infrastructure, endpoint and vulnerability management leads and complements our Patch Management Guide, which covers patching supported systems.

Key takeaways

• Know the date before the date. Track end of support for every OS version in your inventory at least 24 months ahead; the budget cycle for replacement hardware or paid support is usually a year long.
• Extended support buys time, not safety. Windows 10 ESU, RHEL Extended Life Cycle Support and Ubuntu Pro ESM give security fixes only, under defined scope, and Windows ESU pricing rises each year.
• "End of maintenance" is not always "no patches". Lifecycle terms differ: Red Hat's Extended Life Phase gives no security fixes without an add-on, while Ubuntu standard support ends but ESM continues for Pro subscribers.
• Isolation is a control, not a plan. NCSC states that the only fully effective mitigation is to stop using the obsolete product; network isolation and monitoring reduce risk while migration completes.
• Every unsupported system needs an owner, an exception and an end date. Record it in the exception register with compensating controls, and report the count to leadership monthly.

Vendor lifecycle models compared

Each vendor uses different terms for the same idea. Read the vendor's own lifecycle page, not a summary site, and record which phase each version is in.

Watch the times as well as the dates. Microsoft lifecycle dates end at 06:59:59 Pacific Time, so in Europe the cutoff falls in the afternoon of the stated date. Plan as if support ends the day before.

What extended support does and does not cover

• Scope is narrower than full support: Windows 10 ESU covers critical and important security updates only. Red Hat ELS covers certain critical security fixes and selected urgent bug fixes, so lower-rated CVEs may stay open. Check the vendor's scope statement before assuming a scanner finding will be fixed.
• Eligibility rules: Windows 10 ESU requires version 22H2; earlier builds must be updated first. RHEL 7 ELS applies to RHEL 7.9.
• Cost escalation: Microsoft lists Windows 10 ESU at USD 61 per device for Year One through volume licensing, says the price doubles each consecutive year and that ESU is cumulative: joining in Year Two means paying for Year One too.
• Cloud entitlements: Microsoft states that Windows 10 virtual machines in Windows 365, Azure Virtual Desktop, Azure virtual machines and several Azure hybrid services receive ESU at no extra charge. This makes virtual desktops a practical holding pattern for a small number of legacy applications.
• Application vendors may stop first: browsers, EDR agents, backup agents and line-of-business software often drop support for an OS before or at its end of support. An ESU-patched OS running an unsupported EDR agent is not well protected.
• Activation is a task: Windows 10 ESU uses Multiple Activation Keys from the Microsoft 365 admin centre volume licensing area, which are not usable until end of support. Build the activation into your deployment tooling and verify it per device.

Deciding: upgrade, extend, isolate or retire

Small and large organisations. A small organisation with a few dozen Windows 10 PCs usually does best replacing hardware in one cycle and buying Year One ESU only for stragglers. A large estate should segment by hardware readiness and application dependency, buy ESU per device only for named cohorts with dates, and use cloud desktops for legacy applications where the entitlement applies. For Linux, compare ELS or ESM cost against the engineering effort of rebuilding on a current release; containerised workloads usually move faster than hand-built servers.

Running an end of life programme

1. Inventory with lifecycle data: pull OS name, version and build from endpoint management, configuration management and cloud inventory, and join it to the vendor's lifecycle dates. Include virtual machines, golden images, container base images and appliances built on a general-purpose OS. See the Asset Inventory and CMDB Security Guide.
2. Set horizons: flag versions at 24, 12 and 6 months before end of support. At 12 months, every system needs a chosen option from the table above and a funded plan.
3. Test the target: build pilot rings (IT, early adopters, then business units), test applications on the target OS, and keep a rollback image for each ring.
4. Buy extended support deliberately: for systems that will miss the date, buy only the years needed, by named device, and set a migration date inside the coverage period.
5. Isolate what remains: for systems with no supported path, apply NCSC's mitigations: block direct email and web access, restrict network flows with an external firewall, disable non-essential services, control removable media, and log and alert on activity. NCSC also suggests a separate Active Directory forest for obsolete Windows clients.
6. Record exceptions: every unsupported system gets an exception with owner, compensating controls and expiry. Use the Hardening Exceptions and Compensating Controls Template.
7. Verify after the date: confirm that ESU-covered devices are receiving updates, that converted or upgraded systems report the new version, and that nothing new on the old OS has appeared.

Special cases: embedded, OT and vendor-certified systems

Some systems run an end of life OS because a third party certifies the whole stack: medical imaging workstations, laboratory instruments, building management servers, industrial HMIs, point of sale terminals and appliances built on an old Linux kernel. The owner often cannot patch or upgrade without voiding support or regulatory approval.

• Ask the supplier for its lifecycle: request the OS version, the supplier's own end of support date for the product, and whether it ships its own security updates. Put this into contract renewals and procurement requirements for new equipment.
• Use the bill of materials: where a supplier provides an SBOM, it shows the underlying OS and library versions, so you can see which components are past end of life. See the SBOM Guide.
• Isolate by design: place these systems in their own zone with an allow-list of flows to the specific servers they need, no internet access and controlled remote vendor access.
• Plan replacement with the asset: the end of support date of the embedded OS should set the replacement date of the equipment in the capital plan, not the date it physically fails.

Explaining it to the business. Present each unsupported population as a decision with three numbers: the cost of migration, the annual cost of extended support or isolation, and the number of known exploitable vulnerabilities that will remain open. Business owners then make the risk acceptance explicitly, through the exception process, rather than by default.

Where identity fits

Unsupported systems often hold credentials that outlive their protection. An old server may run services under domain accounts with non-expiring passwords, store application secrets in configuration files, or require legacy protocols such as NTLMv1 or SMBv1 that newer domain controllers would otherwise refuse. When a system is isolated rather than replaced, rotate the service account passwords it uses, restrict those accounts to that host, and remove any domain administrator logons to it. When it is retired, disable and then delete its computer object and service accounts. See the Windows Server Hardening Guide and the Weak Cipher and Legacy Protocol Retirement Playbook.

Detection and measurement

• Scanner checks: most vulnerability scanners have an "unsupported operating system" check; treat it as a critical finding with its own SLA and route it to the exception process. See the Vulnerability Management Guide.
• New-build drift: alert when a new host appears running an OS version already past or within six months of end of support, often from an old template or image.
• Isolated systems: monitor allowed flows, and alert on any connection outside them, on new local accounts and on interactive logons by privileged accounts. Do not rely on the obsolete host's own firewall, as NCSC notes.
• ESU health: confirm each covered device installs the monthly ESU update; an activation failure looks like a patched device in some reports.

Metrics: number and percentage of systems on unsupported OS versions (target zero outside approved exceptions); systems within 12 months of end of support without a funded plan; extended support spend by year; median days between end of support and migration for each version; percentage of unsupported systems with documented, tested compensating controls.

Framework mapping

Common failure patterns

• Counting only the endpoints: the Windows 10 laptops are tracked, but servers, VDI images, kiosks and appliances built on old Linux or Windows Server are not.
• ESU as a strategy: extended support bought for a second and third year with no migration date, at rising cost, until it ends with the systems still in place. Windows Server 2012 R2 ESU ended on 14 October 2026 for organisations that took this path.
• Misreading Linux lifecycle terms: assuming a RHEL release in the Extended Life Phase still gets security errata, or that an Ubuntu LTS out of standard support is patched without Ubuntu Pro attached.
• Isolation that is not isolation: a "segmented" legacy server still reachable over SMB or RDP from the user network, or still browsing the web.
• Forgotten credentials: legacy hosts keep privileged service accounts and cached domain admin credentials that make them a pivot point.
• Images and templates: golden images or container bases on an end of life release keep producing new unsupported systems. See the Edge Device End of Life Replacement Playbook for the equivalent problem on network appliances.

Practitioner checklist

• Join OS inventory to vendor lifecycle dates, including servers, images and appliances.
• Flag versions at 24, 12 and 6 months before end of support, with a funded plan at 12 months.
• Check eligibility for extended support (Windows 10 22H2, RHEL 7.9, Ubuntu Pro) before relying on it.
• Buy extended support per named device and only for the years needed, with a migration date inside the coverage.
• Use cloud desktop ESU entitlements for legacy Windows applications where they apply.
• Isolate systems with no supported path and record each as an exception with compensating controls.
• Rotate and restrict service accounts on legacy hosts; remove privileged interactive logons.
• Treat "unsupported OS" scanner findings as critical, with their own SLA.
• Report unsupported system counts and extended support spend to leadership monthly.
• Add OS lifecycle and supplier update commitments to procurement and contract renewals for appliances and certified equipment.

Standards and references

• Microsoft Learn: Extended Security Updates (ESU) program for Windows 10
• Microsoft Learn: Windows Server 2012 R2 lifecycle
• Microsoft Learn: Windows 11 release information
• Red Hat: Red Hat Enterprise Linux Life Cycle
• Red Hat: CentOS Linux end of life
• Canonical: Ubuntu release cycle
• NCSC: Obsolete products
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Patch Management Guide · Vulnerability Management Guide · Red Hat Enterprise Linux Security Hardening Guide · Ubuntu Server Security Hardening Guide