Ubuntu 20.04 End of Standard Support: Options After Focal Fossa Stopped Getting Free Patches

Ubuntu 20.04 LTS (Focal Fossa) left standard security maintenance on 31 May 2025, so any focal server, VM, WSL instance or container image that is not attached to Ubuntu Pro has been running without free security updates for more than a year. The way out is a choice between three levers: attach the machines to Ubuntu Pro for Expanded Security Maintenance, upgrade in two hops to 22.04 and then 24.04, or rebuild workloads on a newer base. This guide is specific to 20.04: the dated timeline as Canonical publishes it, how to find every focal host, image and Pro token in your estate, the breaking changes waiting in the first upgrade hop, and how to test and roll back. It is for Linux administrators, platform and container teams, and vulnerability managers. The lifecycle rules shared by every Ubuntu LTS are in the Ubuntu LTS End of Standard Support guide, and this page does not repeat them.

This is an independent guide from NHI Mgmt Group, based on Canonical's public documentation as of November 2026. It is not sponsored or reviewed by Canonical. Product features change, so confirm settings against Canonical's current documentation.

Key takeaways

• Free patches ended on 31 May 2025. Canonical's release cycle page lists standard security maintenance for 20.04 ending in May 2025, ESM with Ubuntu Pro to May 2030 and the Legacy add-on to May 2035.
• Two hops to 24.04. Ubuntu upgrades only from one LTS to the next, so focal goes to 22.04 (jammy) first, and that hop carries most of the breaking changes: OpenSSL 3.0, ssh-rsa disabled, PHP 8.1 and nftables.
• Pro buys time, not a destination. ESM keeps Main and Universe patched for high and critical issues until May 2030; use the time to plan the upgrade rather than to defer it.
• Focal images are gone from the official list. As of 8 November 2026 the Docker Official Images library for ubuntu lists 22.04 and newer only, so any FROM ubuntu:20.04 build is pulling an image that no longer receives rebuilds there.
• Pro tokens are credentials. Attach tokens and attach config files grant access to your subscription, so vault them, use short lived guest tokens in builds, and detach before an image ships.

What is changing and why

Every Ubuntu LTS gets five years of standard security maintenance for packages in the Main repository. For 20.04 that window closed in May 2025. After that date the public archive no longer publishes security updates for focal; fixes continue only through the ESM repositories that a machine reaches when it is attached to an Ubuntu Pro subscription. Canonical's own announcement put it plainly: running 20.04 without ESM means no longer receiving security updates.

Two repositories matter, and they are often confused:

• esm-infra: continues coverage of Main packages (the kernel, OpenSSL, OpenSSH, systemd and the rest of the core) after the five year window. Canonical sells an infra-only subscription for estates that need only this.
• esm-apps: covers Universe packages for ten years from the LTS release. Universe has over 36,000 packages per release against about 2,300 in Main (Canonical's figures as of 24.04), and it was never covered by standard maintenance, so many focal hosts were already carrying unpatched Universe packages before May 2025.

Canonical describes ESM as covering high and critical CVEs, with Ubuntu Pro adding fixes for selected medium ones and kernel Livepatch. Plan for low and most medium issues to stay unfixed on focal for good.

Official timeline and current status

All dates below are from Canonical's release cycle page and ESM page, checked on 8 November 2026. Canonical publishes month and year; the exact day for end of standard support comes from its November 2024 announcement.

• Status today: 20.04 is in its ESM phase. Patches flow only to machines attached to Ubuntu Pro with esm-infra and esm-apps enabled.
• Legacy dates moved: Canonical's November 2024 announcement said the Legacy add-on would extend 20.04 to May 2032 (12 years). The release cycle and ESM pages now show May 2035, matching Canonical's 15 year total. Contracts signed on the earlier figure may say 2032: check yours.
• Cost tier: the announcement states Ubuntu Pro is free for personal and small commercial use on up to five machines, with a 30 day trial for enterprises. Everything beyond that is a paid subscription.
• 22.04 is next: moving focal only to 22.04 buys standard support to May 2027, about 18 months from today. Treat 22.04 as a stepping stone unless you also plan Pro for it.

Dates move. Re-check the release cycle page before quoting them in a risk register or a contract, and record the date you checked.

Who and what is affected

The identity angle is real here. Build agents, runners and automation hosts carry machine credentials: deploy keys, cloud access keys, signing keys, Kubernetes service account tokens and the Ubuntu Pro token itself. An unpatched focal runner is a soft place for those secrets to live. See the Linux Service Accounts and Keytab Management Guide.

Finding affected systems and identities

1. Query the host fleet. Collect VERSION_CODENAME from /etc/os-release through your configuration management, EDR or vulnerability scanner inventory and filter for focal. Reconcile the list against the CMDB so that unmanaged hosts surface. See the Asset Inventory and CMDB Security Guide.
2. Measure real coverage per host. On each focal machine, pro security-status --format json summarises installed packages by origin: Main and Universe, esm-infra and esm-apps, third party and unknown. pro status --format json shows whether the machine is attached and which services are enabled. A host that is attached but shows esm-apps disabled is still exposed on its Universe packages.
3. Search image definitions. Search repositories for FROM ubuntu:20.04, FROM ubuntu:focal and pinned focal digests, then scan registries for images whose OS layer reports focal. Upstream images (language runtimes, databases) may be built on focal without saying so in their tag.
4. Search infrastructure code. Look for focal image IDs, image family names and 20.04 strings in Terraform, CloudFormation, Packer templates, launch templates and CI runner definitions.
5. Inventory Pro tokens. List where Ubuntu Pro tokens and attach config files live: configuration management variables, cloud-init user data, CI secrets and Dockerfiles. A token pasted into user data or a committed YAML file is an exposed credential. See the guide to finding hard-coded secrets in container images.
6. Record the owner and the plan. For each focal asset record the business owner, the chosen lever (Pro, upgrade, rebuild or retire) and a target date.

Detection queries should read data only. Keep remediation as a separate, change-controlled step.

Migration options

Attaching to Ubuntu Pro

Interactively, sudo pro attach displays a code to enter at ubuntu.com/pro/attach, and the recommended services, including esm-infra and esm-apps, are enabled by default. At scale, use an attach config file delivered by configuration management, or --no-auto-enable followed by explicit pro enable calls so that the enabled set is deliberate. Then run apt update and apt upgrade so the ESM fixes are actually installed, and check with pro security-status.

Container images

The preferred fix is to rebase on ubuntu:24.04 or a hardened minimal base. Where an image must stay on focal for now, Canonical documents enabling Pro inside a Dockerfile: the attach config is passed as a BuildKit secret (--secret id=pro-attach-config) and read through RUN --mount=type=secret, and attach, upgrade, pro detach --assume-yes and purging the Pro client all happen in one RUN instruction so no token reaches an image layer. Canonical's guide uses a short lived, single use guest token obtained on an attached host. See the Hardened and Minimal Base Images Guide.

The 22.04 hop: what breaks

Canonical's 22.04 release notes list the changes most likely to bite a focal estate:

• OpenSSL 3.0: many legacy algorithms are disabled by default, certificates signed with SHA-1 or MD5 are rejected at the default security level, and third-party software linked against libssl1.1 must be rebuilt for libssl3. See the How TLS Works Guide.
• OpenSSH: ssh-rsa signatures are disabled by default. If you upgrade over SSH, confirm first that no client, key or automation depends on them, or you may lose access. Older SSH keys used by service accounts and network gear are the usual casualties. See the OpenSSH Server Hardening Guide.
• Runtimes: PHP moves from 7.4 to 8.1 and Python to 3.10, which removes deprecated features applications may still use. See the End-of-Life Language Runtimes guide.
• Kernel and networking: servers move to the 5.15 LTS kernel and nftables becomes the default firewall backend; every component on the host must agree on xtables or nftables.
• Service specifics: OpenLDAP 2.5 removes the BDB and HDB backends, BIND 9.18 drops the map zone file format, and Quagga is replaced by FRR. Migrate those first or the services will not start.

Testing and rollback

1. Snapshot or back up first. Canonical's upgrade documentation offers no rollback beyond restoring from backup, so take a VM or volume snapshot and a data backup, and prove the restore works.
2. Prepare the host. Run sudo apt update and sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true, reboot if /run/reboot-required exists, and confirm several gigabytes of free disk space.
3. Clone and rehearse. Upgrade a clone or a staging twin with sudo do-release-upgrade. Third-party repositories and PPAs are disabled during the upgrade and are Canonical's most common cause of problems, so record them and plan how to re-enable compatible versions.
4. Keep a session open. The upgrade is interactive, can take hours and cannot be cancelled once the download completes. It uses GNU screen to survive dropped connections. Keep console access available in case SSH changes lock you out.
5. Test the application, not just the boot. Run functional tests, TLS handshakes to and from partners, SSH automation, scheduled jobs and monitoring agents on the upgraded clone.
6. Roll in rings. Start with low risk hosts, then a pilot group, then production. A host that fails goes back to its snapshot and is attached to Pro while the issue is fixed.
7. Repeat for 24.04. The second hop needs its own rehearsal; do not chain both hops in one window on production.

Risks of doing nothing

• Accumulating exposure: every new high or critical issue in OpenSSL, OpenSSH, the kernel or a web stack stays open on unattached focal hosts. Internet-facing services are the first target for exploitation of public-facing applications (ATT&CK T1190).
• Audit findings: unsupported software is a standard audit finding against NIST SP 800-53 SA-22, CIS Controls Safeguard 2.2 and ISO/IEC 27001 A.8.8. Canonical's announcement also notes PCI DSS, SOC 2 and GDPR exposure for delayed patching.
• Growing upgrade debt: each month makes the two hop path longer and the library gaps wider, and 22.04 itself leaves standard support in May 2027.
• Supply chain drift: upstream images and vendors stop building for focal, so your images freeze while their dependencies age.
• Exposed machine credentials: secrets on unpatched build and automation hosts outlive the host's protection.

Framework mapping and metrics

Metrics that show progress:

• Number of focal hosts and images, trending to zero by your target date.
• Percentage of remaining focal hosts attached to Pro with both esm-infra and esm-apps enabled.
• Count of packages reported as unknown or unavailable by pro security-status across the fleet.
• Mean time from ESM fix publication to installation on focal hosts.
• Upgrade success rate per ring, and number of snapshot rollbacks.
• Number of Ubuntu Pro tokens found outside the approved secrets store.

Practitioner checklist

• Record the 20.04 dates from Canonical's release cycle page in your risk register, with the date checked.
• Build a complete list of focal hosts, cloud images, container images, runners and WSL instances, each with an owner.
• Run pro security-status on every focal host and fix any with esm-apps or esm-infra disabled.
• Attach hosts that cannot move before your next window to Ubuntu Pro, and install the ESM updates.
• Rebase every focal container image on 24.04 or a hardened minimal base.
• Audit ssh-rsa keys, SHA-1 certificates and libssl1.1 dependents before the 22.04 hop.
• Rehearse both upgrade hops on clones, with snapshots and tested restores.
• Move Ubuntu Pro tokens into a secrets manager and use guest tokens with BuildKit secrets in image builds.
• Set a target date to leave 22.04 too, ahead of May 2027.

Standards and references

• Canonical: Ubuntu release cycle
• Canonical: Ubuntu 20.04 LTS end of standard support, how to prepare
• Canonical: Expanded Security Maintenance
• Canonical: Ubuntu Server, upgrade your release
• Canonical: Ubuntu 22.04 LTS release notes
• Canonical: Enable Ubuntu Pro services in a Dockerfile
• Canonical: pro(1) manual page
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Ubuntu LTS End of Standard Support · Operating System End of Life and Extended Support Guide · Ubuntu Server Security Hardening Guide · Container Image Security Guide · NIST SP 800-40 Rev 4 Patch Management Guide