Stuck on an end-of-life OS? Emergency measures until you migrate

Updated November 2026

A server on an end-of-life (EOL) release no longer gets security fixes, so every new flaw stays open for good. You cannot make it safe, but you can make it much harder to reach and buy time: isolate it, switch off what it does not need, consider paid extended support, and set a firm date to move to a supported release.

Do this first.

Check whether the server has already been compromised before you spend money on it (see signs of compromise).
Close every port that does not have to be open to the internet, and limit SSH and admin panels to your own IP addresses.
Take a full backup or snapshot now, and copy it off the server.
Write down a migration date and tell whoever owns the service.

Why it matters

The UK National Cyber Security Centre (NCSC) puts it plainly: weaknesses found in unsupported products stay unpatched, and the only fully effective way to remove the risk is to stop using the product. The US Cybersecurity and Infrastructure Security Agency (CISA) lists unsupported or end-of-life software among its “bad practices” and calls it especially egregious in technologies reachable from the internet. Everything on this page is a stopgap.

How to recognize it

apt update fails with “404 Not Found” or “does not have a Release file”, or yum/dnf cannot find its repositories.
A scanner, your host or your control panel warns that the OS is unsupported.
Vendor advisories for a new flaw list newer releases but not yours.

Check the exact release and compare it with the dates on Is my OS supported?:

cat /etc/os-release          # name and version (missing on some very old releases)
cat /etc/debian_version      # Debian point release
cat /etc/redhat-release      # RHEL, CentOS, Rocky, AlmaLinux, Oracle Linux
uname -r                     # running kernel
pro status                   # Ubuntu: shows whether ESM is enabled

The first hour: cut exposure

1. See what is listening

sudo ss -tulpn               # listening TCP/UDP ports and the process behind each

For each line, ask: does this need to be reachable from the internet? A web server needs ports 80 and 443. A database, Redis, rpcbind or a control panel almost never does.

2. Firewall to the minimum

Replace 203.0.113.10 with your own fixed IP address. Keep a second session or console open while you change the firewall, so a mistake does not lock you out (see Locked out of SSH).

# Debian / Ubuntu with ufw
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp                # web server only
sudo ufw allow 443/tcp               # web server only
sudo ufw default deny incoming
sudo ufw enable
sudo ufw status verbose

# RHEL / CentOS 7 and later with firewalld
sudo firewall-cmd --permanent --zone=trusted --add-source=203.0.113.10   # trusts ALL traffic from this IP
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --permanent --zone=public --add-service=http    # web server only
sudo firewall-cmd --permanent --zone=public --add-service=https   # web server only
sudo firewall-cmd --reload
sudo firewall-cmd --list-all --zone=public

If the server sits behind a cloud provider, also tighten the security group or network firewall there; it still works if the server itself is compromised. More on rules in Firewall basics.

3. Switch off what is not needed

systemctl list-units --type=service --state=running
sudo systemctl disable --now rpcbind.service    # example only: skip if you use NFS

On releases without systemd (for example CentOS 6) use service NAME stop and chkconfig NAME off. The NCSC also advises blocking web browsing and email from obsolete machines, restricting what they can reach inside your network, and treating them as untrusted: do not let other servers trust their SSH keys or credentials.

4. Get every update the release ever had

Make sure the last published fixes are installed. Debian moves old releases to archive.debian.org; if apt update returns 404 errors, your sources need to point there to install anything at all. Nothing new arrives there, so this only closes old holes.

5. Watch it more closely

Turn on log forwarding to another machine and check logs daily until the server is gone (Logging and monitoring). The NCSC stresses that alerts must lead to action, not just be recorded.

Extended support options

Several vendors sell security fixes after the normal end of life. They cost money and usually cover only some packages, and the NCSC describes paid extended support as a temporary measure, not an alternative to migrating. The facts below are as of November 2026; check the vendor’s page before you buy.

Paid or free extended security support for common EOL releases
Release	Option	What the vendor states
Debian 9, 10, 11 (and later)	Extended LTS (ELTS) by Freexian	Commercial service, not run by the Debian project. Debian 9 to June 30, 2027; Debian 10 to June 30, 2029; Debian 11 to June 30, 2031. Private repository; amd64 at least, other architectures on request.
Ubuntu 18.04, 20.04 LTS	Ubuntu Pro (ESM)	Expanded Security Maintenance for main and universe: 18.04 to May 2028, 20.04 to May 2030. Free for personal use on up to five machines.
Ubuntu 14.04, 16.04 LTS	Ubuntu Pro Legacy add-on	ESM has ended; the Legacy add-on runs to May 2029 (14.04) and May 2031 (16.04).
RHEL 7.9	Red Hat Extended Life Cycle Support (ELS) add-on	Until May 31, 2029. Covers certain critical-impact security fixes and selected urgent bug fixes. From RHEL 8.10, ELS is replaced by Extended Life Cycle Premium (ELCP) from June 1, 2029.
CentOS 6, 7, 8, Stream 8; Oracle Linux 6, 7; RHEL 7; Ubuntu 16.04–20.04; Debian 10, 11; Amazon Linux 2; Alpine	TuxCare Endless Lifecycle Support	Commercial; patches delivered through the normal package manager, with no fixed end date stated.

On Ubuntu, attaching a machine takes two commands. Get the token from your account at ubuntu.com/pro:

sudo pro attach YOUR_TOKEN
pro status                          # esm-infra and esm-apps should show "enabled"
sudo apt update && sudo apt upgrade

For Debian ELTS, RHEL ELS and TuxCare, follow the vendor’s setup guide, then install updates as usual. CentOS 7 users can also convert to RHEL 7 and buy ELS; see CentOS.

Migrate: the real fix

Isolation and extended support buy weeks or months. Only migration ends the risk.

In-place upgrade

Upgrades must go one release at a time. Debian’s release notes for Debian 13 say only upgrades from Debian 12 are supported, so a Debian 11 server goes to 12 first, then to 13. Ubuntu supports upgrades only to the next LTS release (20.04 to 22.04, then to 24.04) with sudo do-release-upgrade, which restarts services and asks to reboot. RHEL uses the Leapp tool, one major version per step; see RHEL, Alma, Rocky, Oracle. Take a snapshot before each step.

Rebuild and move

Often cleaner, and the only safe choice if you suspect a compromise: build a new server on a current release, install the applications from packages, copy only the data and configuration you have reviewed, test, then switch DNS. Keep the old server powered off (not deleted) for a week or two in case something was missed, then wipe it.

Containers and virtual machines

Moving a physical server into a virtual machine does not patch anything, but it gives you snapshots, easy isolation and a quick way back. Containers help when an application needs old libraries: run it on a supported host with a supported base image where you can. A container built from an EOL image still carries unpatched packages, and all containers share the host kernel, so keep the host current (Containers).

Confirm the measures work

From a machine outside your network, a port scan of the server shows only the ports you meant to open.
sudo ss -tulpn shows no services you did not expect.
If you bought extended support, apt list --upgradable or yum check-update now shows updates from the new repository.
A restore from your latest backup has been tested.
The migration date is in someone’s calendar.

When to get help

Ask your hosting provider or a Linux consultant if the server runs software that cannot move (old PHP or database versions, vendor appliances), if a release upgrade fails part-way, or if you find signs of intrusion. An EOL server that has been compromised should be rebuilt, not cleaned: see Incident response.