When software passes end of life you have four moves: upgrade it, buy extended support where it exists, isolate it so exposure is small, or retire it. Upgrade when you can, extend or isolate while you prepare, and retire what no one needs. Each path needs an owner and an end date.
The four options compared
| Option | What you get | Main cost | Use when |
|---|---|---|---|
| Upgrade | Full vendor support again | Engineering time and testing | A supported version exists and the app can move |
| Extend | Security fixes for a limited period | Money and a new deadline | You need a bridge, and the vendor offers one |
| Isolate | Smaller exposure, no new fixes | Network work and monitoring | A fixed function system you cannot change |
| Retire | No risk from that system | Migration of data and users | Usage is low or a replacement exists |
Extended options are real but narrow. Microsoft's Windows 10 program, for instance, delivers Critical and Important security updates only, excludes new features and general support, and runs for a maximum of three years for organizations. Ubuntu's Expanded Security Maintenance for 20.04 requires Ubuntu Pro and runs to 2030. Read the terms for what is excluded.
Questions that point to a choice
- Is there a supported version? If yes, upgrade is the default.
- Does the system face the internet or handle sensitive data? If yes, move faster or isolate hard.
- How much does it cost to upgrade, in people and downtime? If it is high, bridge with extend or isolate and set a date.
- Does anyone still use it? Ask. Retirement often wins.
- Does a vendor own it? If so, push the vendor for a supported release and record the request.
What isolation should mean
Isolation is a set of concrete controls, not a label:
- Network segment with deny by default rules, and no outbound internet.
- Only named administrators can log in, with strong authentication.
- No untrusted input reaches it, such as files from outside.
- Logs sent to a central place and watched.
- An approved exception record with an owner and expiry date.
Prioritise by exposure and reachability
Not every end-of-life component deserves the same urgency. An old library whose vulnerable function your code never calls matters less than a public facing runtime. Reachability analysis helps separate the two.
Try it yourself
Use the exploitability view to see how a finding looks different when you ask whether it can actually be exploited in your context.
Click through it at your own pace, or open it full screen.
Quick check
Is isolation a permanent answer?
Rarely. It reduces exposure but leaves the software unpatched. Set an end date.
Should I always buy extended support?
No. It only buys time. Buy it when the upgrade is scheduled and the risk until then justifies it.
Where Safeguard fits
Safeguard's reachability analysis and policies help you rank findings and enforce your decisions on pull requests, while compliance and evidence automation keeps the exception records. Try the free scan.
Sources
Last reviewed: 19 October 2026.
