Every Ubuntu LTS release loses free security updates five years after it ships, and most estates discover too late that "LTS" never covered the majority of their installed packages in the first place. Standard security maintenance covers the Main repository only; Universe packages, which many servers and container images depend on, are covered only through Expanded Security Maintenance in Ubuntu Pro. With 20.04 LTS past standard support since 31 May 2025 and 22.04 LTS due to follow in May 2027, the question for most organisations is not whether to act but which lever to pull. This guide is for Linux administrators, platform teams and vulnerability managers. It covers the official lifecycle, how to measure real coverage per host and image, the choice between upgrading, ESM and replacement, upgrade testing and rollback, and the risk of drifting. The cross-platform decision framework is in the Operating System End of Life and Extended Support Guide, and the release-specific companion is Ubuntu 20.04 End of Standard Support.
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
- Five years, Main only. Canonical's release cycle page gives each LTS five years of standard security maintenance for packages in Main; Universe is not covered by standard support.
- ESM extends to ten years. Ubuntu Pro adds Expanded Security Maintenance for Main (esm-infra) and Universe (esm-apps), with a paid Legacy add-on beyond that.
- Measure, do not assume. pro security-status shows how many installed packages come from Main, Universe, ESM, third parties or nowhere at all, per host.
- Upgrades are sequential. Ubuntu supports only LTS to next LTS, offered after the first point release, so 20.04 to 24.04 is two upgrades.
- Containers age silently. An image built FROM an old LTS tag carries that release's support status into every service built on it, whatever the host runs.
What is changing and why
Ubuntu publishes a long-term support release every two years in April, with interim releases supported for nine months in between. Each LTS moves through phases, according to Canonical's release cycle page:
| Phase | Length | What gets security fixes | Cost and access |
|---|---|---|---|
| Standard security maintenance | 5 years from release | Main repository (about 2,300 packages per release) | Free, no subscription |
| Expanded Security Maintenance (Ubuntu Pro) | To 10 years from release | Main through esm-infra after year 5; Universe (over 36,000 packages as of 24.04) through esm-apps for ten years from release | Ubuntu Pro subscription; free for personal use on up to 5 physical machines |
| Legacy add-on | 5 more years after ESM, per the release cycle page | Continued security maintenance | Paid add-on to Ubuntu Pro |
Canonical's ESM page states that ESM fixes cover critical, high and selected medium vulnerabilities, so even covered releases receive a narrower stream of fixes than the free window. Canonical also offers a lower-cost infra-only subscription that covers Main but not Universe.
Official timeline and current status
The dates below are copied from Canonical's release cycle page as it stood on 8 November 2026. Canonical shows months, not days, except where noted.
| Release | End of standard support | End of ESM (Ubuntu Pro) | End of Legacy add-on | Status on 8 Nov 2026 |
|---|---|---|---|---|
| 16.04 LTS | April 2021 | May 2026 (with Legacy add-on) | May 2031 | Legacy add-on only |
| 18.04 LTS | May 2023 | May 2028 | May 2033 | ESM only |
| 20.04 LTS | May 2025 (31 May 2025 per Canonical's announcement) | May 2030 | May 2035 | ESM only |
| 22.04 LTS | May 2027 | May 2032 | May 2037 | Standard support, about six months left |
| 24.04 LTS | May 2029 | May 2034 | May 2039 | Standard support |
| 26.04 LTS | May 2031 | May 2036 | May 2041 | Standard support |
Note on changing figures: Canonical's 2025 announcement for 20.04 said the Legacy add-on would run to May 2032; the release cycle page now shows May 2035, and Canonical's ESM page lays out coverage dates differently again. Treat the release cycle page as the reference, record the date you checked it, and confirm contract terms with Canonical before relying on Legacy dates.
Who and what is affected
- Servers and VMs on 18.04 or 20.04 without Ubuntu Pro attached: no security updates at all, for Main or Universe.
- 22.04 hosts: still receiving Main updates until May 2027, but any Universe package they run has relied on Ubuntu Pro for fixes all along. Universe holds far more packages than Main, so check rather than guess which of yours come from it.
- Container images: base images on old tags, and images built years ago and never rebuilt. Canonical lists Chiseled OCI images among the images Ubuntu Pro supports with CVE fixes.
- Appliances and vendor images: products built on Ubuntu where the vendor, not you, controls the base release. Ask for their support statement.
- Hosts on interim releases: non-LTS releases get only nine months of updates and have no ESM phase, so a server left on an interim release falls out of support far faster than its owners expect. Move these to the nearest LTS.
- Desktops and developer workstations: often forgotten, frequently holding SSH keys and cloud credentials.
- Hosts with PPAs and third-party repositories: outside Canonical's coverage regardless of phase, and the most common cause of failed release upgrades according to the Ubuntu Server documentation.
Finding affected systems and identities
- Build the release inventory. Collect VERSION_ID from /etc/os-release on every host through your configuration management or endpoint agent, and from every image in your registries. Group by release and by environment.
- Measure package coverage per host. Run pro security-status, read-only, on each host. Its JSON or YAML output summarises installed packages by origin: Ubuntu archive, ESM, third party and unknown. The --esm-apps, --esm-infra, --thirdparty and --unavailable options list each group. The share of Universe and unknown packages is your real exposure.
- Check subscription state. Record which hosts are attached to Ubuntu Pro and which services are enabled. Hosts on 18.04 or 20.04 with no attachment are your first priority.
- Scan images. Use registry or pipeline scanning to report the base OS release of each image and flag end-of-standard-support releases. Rebuilds are cheap compared with host upgrades. See the Container Image Security Guide.
- Map identities on each host. Old hosts usually carry the oldest credentials: service accounts with static passwords, SSH keys with no expiry, database credentials in config files, and Ubuntu Pro attach tokens embedded in images or scripts. Record them so they can be rotated at upgrade or replacement. See the Linux Service Accounts and Keytab Management Guide.
- Check third-party sources. List enabled PPAs and external repositories per host; each is a dependency to resolve before an upgrade and a separate trust decision. See the Linux Package Signing and Repository Trust Guide.
Migration options
| Option | When it fits | Trade-offs |
|---|---|---|
| In-place upgrade with do-release-upgrade | Long-lived servers with state that is hard to rebuild; one LTS step at a time | Interactive, can take several hours, PPAs disabled during the run; two steps for 20.04 to 24.04; rollback means restore |
| Rebuild on a new LTS | Infrastructure as code, immutable images, containers, autoscaled fleets | Requires working automation; cleanest result and best moment to rotate identities |
| Attach Ubuntu Pro (ESM) | Hosts that cannot move before standard support ends; to cover Universe on supported releases | Subscription cost; fixes limited to critical, high and selected medium issues; a bridge, not a destination |
| Legacy add-on | Systems certified or embedded that cannot change for years | Further cost; pair with isolation and an exit date |
| Replace or retire | Unowned or low-value hosts, vendor appliances with a newer version | Needs an owner decision; often the cheapest option |
Decision guidance: small estates usually upgrade in place or rebuild within a quarter and use the free personal-use allowance only where it legitimately applies. Large estates should rebuild everything that is already automated, put Ubuntu Pro on the residue with an exit date per host, and fix the base image pipeline first, because one image change can move hundreds of services. Any host whose security-status shows a large share of Universe packages should have ESM even while in standard support, or should have those packages replaced.
Container base images
Treat the base tag as a dependency with its own end date. Pin to a supported LTS, rebuild on a schedule so fixes in the archive actually reach running images, fail builds whose base release is past standard support unless an exception exists, and check whether any Ubuntu Pro token used at build time is kept out of the final image layers.
Testing and rollback
- Back up and snapshot. The Ubuntu Server documentation calls a safe backup extremely important before a release upgrade. Take a VM or volume snapshot and a data backup you have restored at least once.
- Patch fully first. The upgrade requires all current updates installed on the existing release.
- Wait for the point release in production. LTS to LTS upgrades are offered only after the first point release; the -d flag forces earlier upgrades and is not recommended for production.
- Clear third-party sources. PPAs and external repositories are disabled during the upgrade and are the most common cause of problems; check each has a build for the target release before re-enabling.
- Pilot on clones. Upgrade a clone of each server role, run application tests, check services, kernel modules, configuration file prompts and authentication (PAM, SSSD, SSH) before touching production.
- Run supervised. The process is interactive and can take hours; schedule a window with console access, not only SSH.
- Roll back by restore. There is no supported downgrade. Rollback is reverting to the snapshot or redeploying the previous image, which is why rebuild patterns are safer than in-place upgrades.
- Verify after. Re-run pro security-status and your vulnerability scan; rotate credentials recorded in the inventory.
Risks of doing nothing
- Unpatched exposure: new vulnerabilities in OpenSSH, the kernel, OpenSSL and web stacks stay open, enabling MITRE ATT&CK T1190 Exploit Public-Facing Application and T1068 Exploitation for Privilege Escalation.
- False assurance: scanners and auditors see "LTS" and assume coverage while Universe packages have had no fixes.
- Compliance findings: NIST SP 800-53 SA-22 requires replacing unsupported components or documenting alternative support, and most audit regimes treat an unsupported OS as a finding.
- Harder upgrades later: each skipped LTS adds a sequential upgrade step and more configuration drift.
- Stale credentials: old hosts keep old keys and service accounts, so a compromise of one forgotten server can reach current systems.
Framework mapping and metrics
| Framework | Reference | What it asks for here |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SA-22 Unsupported System Components | Replace releases past support or document alternative support such as ESM |
| NIST SP 800-53 Rev. 5 | SI-2 Flaw Remediation; RA-5 Vulnerability Monitoring and Scanning | Apply fixes and scan for releases and packages without them |
| NIST SP 800-53 Rev. 5 | CM-8 System Component Inventory | Release, package origin and image inventory |
| NIST CSF 2.0 | ID.AM-02; PR.PS-02; ID.RA-01 | Software inventory; software maintained or replaced by risk; vulnerabilities identified and recorded |
Metrics to track: hosts and images per release (trend away from releases past standard support); percentage of hosts on 18.04 or 20.04 with Ubuntu Pro attached (target 100 until migrated); percentage of installed packages with no security coverage per security-status; images rebuilt in the last 30 days; exceptions past their exit date; credentials rotated at upgrade compared with credentials inventoried.
Practitioner checklist
- Record Canonical's release cycle dates for each release you run, with the date checked.
- Inventory release per host and per image, by environment and owner.
- Run pro security-status on every host and track Universe and unknown package counts.
- Attach Ubuntu Pro to any 18.04 or 20.04 host that cannot move this quarter, with an exit date.
- Plan 22.04 moves now; standard support ends in May 2027.
- Prefer rebuild on a new LTS; for in-place upgrades, back up, patch, clear PPAs and pilot on clones.
- Fail image builds on base releases past standard support unless an exception is recorded.
- Rotate service account passwords, SSH keys and embedded tokens at upgrade or replacement.
- Isolate hosts that remain unsupported and review exceptions monthly.
Standards and references
- Canonical: Ubuntu release cycle
- Canonical: Expanded Security Maintenance
- Canonical: Ubuntu Server, upgrade your release
- Canonical: pro(1) manual page
- Canonical: Ubuntu 20.04 LTS end of standard support
- Canonical: Ubuntu Pro
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Operating System End of Life and Extended Support Guide · Ubuntu 20.04 End of Standard Support · Ubuntu Server Security Hardening Guide · CentOS 7 End of Life