Ubuntu 20.04 LTS "Focal Fossa" was released on 23 April 2020 with Linux kernel 5.4 and GNOME 3.36, and its standard security maintenance ended in May 2025 on Canonical's release cycle page (the release notes say April 2025), with Expanded Security Maintenance through Ubuntu Pro running to May 2030 and the Legacy add-on to May 2035.
If your question is "is 20.04 still safe to run", our post on whether Ubuntu 20.04 is end of life, and the ESM and upgrade options covers that decision. This post is about the release itself: what Canonical shipped in April 2020, what changed compared with 18.04 LTS "Bionic Beaver" and the three interim releases in between, and which defaults matter for security. Every release fact links to the official page it came from, and every command comes from Canonical's own documentation.
Key takeaways
- Released 23 April 2020, codename Focal Fossa. The first point release, 20.04.1, was announced on 6 August 2020, and that is when 18.04 users started to be offered the upgrade.
- Kernel 5.4 is the GA kernel. Ubuntu Desktop tracks the hardware enablement (HWE) kernel by default; the last 20.04 HWE kernel on the kernel lifecycle page is 5.15, from 20.04.5.
- GNOME 3.36 on Ubuntu Desktop, with a new lock screen, a refreshed Yaru theme and light and dark theme switching.
- Support: standard security maintenance to May 2025 (release cycle page) or April 2025 (release notes), ESM to May 2030, Legacy add-on to May 2035. Flavours other than Desktop, Server, Cloud and Core got 3 years.
- Security relevant kernel changes: WireGuard built in, kernel lockdown in integrity mode enabled, fs-verity support.
- Python 2.7 moved to universe and is not installed on new systems.
/usr/bin/pythondoes not exist on a fresh install. - Snap Store replaced Ubuntu Software as the default app for finding software, in 20.04 itself, not in 20.10.
- ufw ships disabled, as on every Ubuntu release. Secure Boot gained a Microsoft-signed shim for arm64 as of 20.04.
- 20.04 is the first LTS built with the stack clash and control flow protection compiler defaults that arrived in 19.10.
- FIPS 140-2 shows as "Expired" for 20.04 on the release cycle page on 23 October 2026, while DISA-STIG and CIS show "Achieved".
What are the Ubuntu 20.04 LTS release facts?
| Fact | Ubuntu 20.04 LTS | Source |
|---|---|---|
| Codename | Focal Fossa | 20.04 release notes |
| Release date | 23 April 2020 (release cycle page: "Apr 2020") | Release candidate announcement; Release cycle |
| First point release | 20.04.1, announced 6 August 2020 | 20.04.1 announcement |
| Last point release | 20.04.6 (release notes link its change summary) | 20.04 release notes |
| GA kernel | Linux 5.4 | 20.04 release notes; Release cycle |
| HWE kernels | 5.8 named in the release notes; 5.15 as 20.04.5 HWE on the lifecycle page | 20.04 release notes; Kernel lifecycle |
| Default desktop | GNOME 3.36 | 20.04 release notes |
| Standard security maintenance | May 2025 (release cycle); "until April 2025" (release notes) | Release cycle; 20.04 release notes |
| Expanded Security Maintenance | May 2030 | Release cycle; ESM |
| Break/bug support | May 2030 | Release cycle |
| Legacy add-on | May 2035 | Release cycle; ESM |
| Flavour support | 3 years for flavours other than Desktop, Server, Cloud and Core | 20.04 release notes |
| Architectures | amd64, armhf, arm64, s390x, riscv64, ppc64el-p8 | Release cycle |
| Upgrade in | From 18.04 LTS or 19.10 | 20.04 release notes |
| Upgrade path out | 22.04 LTS | Release cycle |
| Compliance status (23 Oct 2026) | FIPS 140-2: Expired; DISA-STIG: Achieved; CIS: Achieved | Release cycle |
The release notes do not state the exact release day. The day comes from the release team's release candidate post on Ubuntu Discourse, which asked testers to help reach "a final image for the release on Thursday 23rd April 2020." The release cycle page only says "Apr 2020."
The 20.04 notes link flavour release notes for Lubuntu, Kubuntu, Ubuntu Budgie, Ubuntu MATE, Ubuntu Studio, Xubuntu and Ubuntu Kylin. The 20.04.1 announcement lists the same seven flavours at their 20.04.1 point release.
How long was Ubuntu 20.04 LTS supported?
In short: five years of standard security maintenance for packages in main, then ESM through Ubuntu Pro to May 2030, then the paid Legacy add-on to May 2035. The detail, and what it means for a machine still running 20.04 today, is in our 20.04 end of life post.
Two official pages disagree on the month standard support ended. The 20.04 release notes say maintenance updates "will be provided for 5 years until April 2025." The release cycle page, the kernel lifecycle page and the ESM page all say May 2025. This post uses May 2025, because three current Canonical pages agree on it, and notes the April wording where it appears.
The flavour rule matters for anyone who ran Kubuntu, Xubuntu, Lubuntu or another flavour as a desktop. The release notes give those flavours 3 years, not 5, so a flavour desktop on 20.04 lost its flavour-specific support long before May 2025, even though the shared packages in main kept getting fixes.
What ESM covers is defined on the ESM page: the "esm-infra" stream covers main packages after the standard five years end, and the "esm-apps" stream covers universe packages "for ten years from the release of the LTS." Ubuntu Pro is free for personal use on up to 5 physical machines (50 for official Ubuntu Community members), according to the Pro page. The release cycle page phrases it as "up to five machines."
What kernel does Ubuntu 20.04 use?
Ubuntu 20.04 is "based on the long-term supported Linux release series 5.4," according to the release notes. The release cycle page lists 5.4 for 20.04 LTS.
The notes list these changes in 5.4 since 5.3, the 19.10 kernel:
- Support for Intel Comet Lake and initial Tiger Lake platforms, AMD Navi 12 and 14 GPUs, and Arcturus and Renoir APUs.
- exFAT support, virtio-fs for sharing filesystems with virtual machine guests, and fs-verity for detecting file modifications.
- Built in support for the WireGuard VPN.
- Enablement of lockdown in integrity mode.
Compared with 4.15 in 18.04 LTS, the notes add support for AMD Rome CPUs, Raspberry Pi models from the Pi 2B to the Pi 4B, "a new mount API, the io_uring interface, KVM support for AMD Secure Encrypted Virtualization and pidfd support," and boot speed work that changed the default kernel compression to lz4 in 19.10 on most architectures and the default initramfs compression to lz4 on all of them.
HWE: which kernel a 20.04 machine actually runs
The answer depends on how the machine was installed. The kernel lifecycle page says "Desktop installations of 20.04 default to tracking the HWE stack. Server installations will default to the GA kernel and provide the enablement kernel as optional." Some desktop machines are on a separate OEM kernel track instead.
The release notes say that from January 2021 Ubuntu Desktop would "gain new major kernel versions every 6 months through to summer of 2022," and still name 5.8 as the HWE series, which reflects an earlier point release. The kernel lifecycle page is more current: it lists kernel 5.15 as the 20.04.5 HWE kernel, released July 2022, with standard maintenance to May 2025, ESM to May 2030 and Legacy to May 2035. It lists 5.4 for both 20.04.0 and 20.04.1.
A Discourse post from the Ubuntu team, Improvements for hardware support in Ubuntu Desktop installation media, explains the reasoning. Before 20.04, installs from .0 and .1 media behaved differently from .2 and later media. For 20.04, "the best kernel for your hardware is chosen and installed automatically." The same post is candid that the in-archive switch from 5.4 to 5.8 "coincided with a CRD (coordinated release date) for several security vulnerabilities," that three driver tests had returned false positives, and that rolling back was not an option because of the security fixes. That is a useful reminder that kernel moves on an LTS can be tied to security deadlines, not just new hardware.
Starting with Ubuntu Server 20.04.2, the release notes say server ISOs could optionally boot the installer with the HWE kernel, in which case the installed system uses the HWE stack automatically.
What desktop does Ubuntu 20.04 ship?
Ubuntu Desktop 20.04 ships GNOME 3.36, according to the release notes. The notes list:
- a new lock screen design, a new system menu design and a new app folder design;
- smoother performance and lower CPU use for animations, JavaScript execution, mouse movement and window movement;
- 10-bit deep colour support and X11 fractional scaling;
- a new graphical boot splash that integrates with the system BIOS logo;
- a refreshed Yaru theme with light and dark theme switching;
- Mesa 20.0, BlueZ 5.53, PulseAudio 14.0 (prerelease), Firefox 75.0, Thunderbird 68.7.0 and LibreOffice 6.4.
The 20.04 notes do not say which display server is the default. The 18.04 release notes had said Wayland was a technical preview "expected to be the default display server in 20.04 LTS," but the 20.04 notes do not confirm that this happened, and they describe fractional scaling for X11. We have left the default display server as "not stated in the official release notes."
Which new features are security relevant?
Three features are often cited for 20.04: WireGuard, ZFS on root and fingerprint login. Here is what the official notes say about each, plus the other changes that affect security posture.
WireGuard in the kernel: yes, relevant
The 5.4 kernel in 20.04 has "built in support for the WireGuard VPN" (release notes). A VPN in the distribution kernel gets its fixes through the normal kernel update stream, covered by the same maintenance, ESM and Livepatch arrangements as the rest of the kernel, and a 20.04 host can run a tunnel without an out of tree module to track.
Kernel lockdown in integrity mode: yes, relevant
The release notes list "enablement of lockdown in integrity mode" among the 5.4 changes. Lockdown restricts ways a privileged user can modify the running kernel. The notes do not explain the details or which conditions turn it on, so we will not go beyond that one line here. Pair it with the Secure Boot section below.
fs-verity: relevant for integrity, but opt in
The notes add "fs-verity for detecting file modifications." It is a kernel capability, not a default policy, so nothing on a stock 20.04 system uses it unless you set it up.
ZFS on root: relevant mainly for encryption
ZFS on root as an installer option is a 19.10 story. The 19.10 release notes say "Support for ZFS as the root filesystem is added as an experimental feature in 19.10," with the installer creating the ZFS layout automatically. The 20.04 notes do not repeat that sentence, and they do not say whether the option was still labelled experimental. They do show it was present: the known issues list says "ZFS installation fails to boot if there are existing pools named bpool or rpool on a second drive."
What the 20.04 notes do say is that Focal ships ZFS 0.8.3, with native encryption "with hardware acceleration enabled in Focal," device removal, pool TRIM, and sequential scrub and resilver. Native encryption is the security relevant part. The notes do not say whether the installer's ZFS option turned on native encryption, so treat that as "not stated in the official release notes" and check your own pools.
Fingerprint login: a known issue, not a new feature
Fingerprint unlocking was not new in 20.04. The 18.10 release notes say "Fingerprint libraries promoted to main to allow unlocking with fingerprints." The 20.04 notes mention fingerprints only as a known issue: "Due to database format changes fprintd will remove all saved fingerprints, please ensure you have another mechanism for logging in." The security lesson is about availability, not attack surface: anyone who upgraded a laptop from 18.04 needed a password that still worked.
OpenSSH 8.2 with FIDO hardware keys: yes, relevant
The release notes say OpenSSH 8.2 "added support for U2F/FIDO hardware devices to allow easy hardware-based two factor authentication," with ecdsa-sk keys. They also note that the system sshd configuration now includes files under /etc/ssh/sshd_config.d/*.conf, and that for each keyword "the first obtained value will be used." Cloud images on Google Compute Engine and Azure moved their sshd overrides into /etc/ssh/sshd_config.d/50-cloudimg-settings.conf. The notes give one command to see the effective configuration:
sudo sshd -T
That first-value-wins rule is worth knowing during an audit. A hardening line you add at the bottom of /etc/ssh/sshd_config can be silently overridden by an earlier included file.
Other security relevant defaults in the notes
- Samba 4.11: "SMB1 disabled by default," which can be re-enabled in
/etc/samba/smb.conf. - AWS images: Amazon Machine Images "have the ec2-instance-connect package installed and enabled by default starting in Focal," so SSH access can be controlled through the cloud provider's identity policies.
- nginx: nginx-core no longer ships the legacy geoip module enabled by default, part of deprecating legacy GeoIP support. Bind 9.16 also removed legacy geoip support.
- useradd: starting with 20.04.3, fully numeric usernames are not allowed, because they cause problems in components such as systemd.
What happened to Python 2 in Ubuntu 20.04?
Python 2 left the default install one LTS earlier. The 18.04 release notes say "Python 2 is no longer installed by default" and that 18.04 "is the last LTS release to include Python 2 in main."
20.04 finished the move. According to the 20.04 release notes:
- The Python in the base system is Python 3.8 (3.8.2 at release).
- "Python 2.7 has been moved to universe and is not included by default in any new installs."
- Packages that still need 2.7 now use
/usr/bin/python2as their interpreter. /usr/bin/python"is not present by default on any new installs." On upgraded systems it keeps pointing to python2.- New installs that need
/usr/bin/pythonshould installpython-is-python3. - During an upgrade, the legacy
pythonandpython-minimalpackages may be removed and replaced bypython2andpython2-minimalas dependencies ofpython-is-python2.
The effect on old tooling
Three practical effects follow from those notes.
First, scripts with a #!/usr/bin/python line fail on a fresh install, because the file does not exist, but still run under Python 2 on an upgraded machine.
Second, other packages dropped Python 2 at the same time. The notes list "Drop python2 support" among the cloud-init changes, and say Samba 4.11 has "python2 no longer supported."
Third, and most important for security, moving Python 2.7 to universe changed who patches it. The release cycle page says LTS releases are "security maintained for 5 years with CVE patches for packages in the Main repository." Universe packages get Canonical's security maintenance through the esm-apps stream of ESM, which is part of Ubuntu Pro. If an old internal tool still depends on Python 2.7 on 20.04, it depends on a universe package, and whether that interpreter gets fixes depends on whether the machine has esm-apps enabled. Our explainer on whether Ubuntu patches universe packages goes deeper on that split.
What were the security defaults at release?
AppArmor
AppArmor is Ubuntu's default mandatory access control system. The Ubuntu security documentation says "AppArmor provides Mandatory Access Control (MAC) by default," and that SELinux support is compiled into the kernel but "AppArmor takes precedence as the enabled security module at boot time."
The 20.04 release notes mention AppArmor only for virtualisation. libvirt gained "a new local include AppArmor to the libvirt-qemu profile that allows local overrides for special devices or paths," so admins can add exceptions without carrying a modified configuration file through every upgrade. GL enabled graphics and mediated devices can also be configured "while still being guarded by custom apparmor profiles generated per guest."
The AppArmor documentation now describes AppArmor restrictions on unprivileged user namespaces. Nothing in the 20.04 release notes mentions that restriction, so do not assume a 20.04 machine has it. For the choice between the two MAC systems, see SELinux or AppArmor for a server, and for tuning profiles on a workstation, AppArmor complain or enforce on Ubuntu dev machines.
Firewall: ufw installed, disabled
The Ubuntu Server firewall guide says "The default firewall configuration tool for Ubuntu is ufw" and "ufw by default is initially disabled." The 20.04 notes do not change that.
One backend detail is release specific. The Ubuntu security documentation on firewalls says the nftables backend for the iptables tools "has been the default since Ubuntu 20.10 (Groovy Gorilla)," and the 20.10 release notes say "nftables is now the default backend for the firewall." Read together, 20.04 is the last LTS before that switch. If you write raw rules on 20.04, check which backend your tools use before you copy rules from a newer release. For first steps with ufw, see ufw on an Ubuntu developer laptop.
Secure Boot and shim
The Ubuntu Secure Boot documentation gives the history. Secure Boot arrived in 12.04 LTS with the kernel in non-enforcing mode. "Starting with Ubuntu 18.04 LTS (Bionic Beaver), Secure Boot verifies all critical components: bootloader, kernel, and kernel modules." For 20.04 specifically, the same page says that on arm64, "As of Ubuntu 20.04 LTS (Focal Fossa), a shim binary signed by Microsoft and a GRUB binary signed by Canonical are provided in the Ubuntu main archive."
Firmware validates a Microsoft-signed shim, shim uses Canonical's embedded certificate to validate GRUB and the kernel, and MokManager lets the owner enrol extra keys for custom kernels or modules. Our post on Secure Boot, trusted boot and measured boot explains how these pieces differ.
Full disk encryption and TPM
The 20.04 notes do not announce TPM-backed full disk encryption. The only encryption statements are that the live server installer had "many other fixes under the hood to make using encryption easier," ZFS 0.8.3 brought native encryption, and QEMU 4.2 has "many speed improvements for LUKS backend." TPM-backed FDE as a desktop install option is not stated in the 20.04 release notes.
Updates: unattended-upgrades and Livepatch
The Ubuntu Server automatic updates guide says security updates are applied "via the unattended-upgrades package, which is installed by default," that automatic installation of security updates is enabled "right after installation, including Expanded Security Maintenance (ESM) if that is available on the system," and that it runs once per day. That is why a 20.04 machine with an attached Pro token keeps pulling ESM fixes without further setup. For reboot settings, see Ubuntu unattended-upgrades: enable and reboot settings.
Kernel Livepatch is part of Ubuntu Pro. The Pro page describes it as "rebootless security patching automation to address high and critical kernel vulnerabilities." It does not remove the need to reboot into new kernels eventually; our post on what Livepatch fixes and what still needs a reboot covers that.
Compiler hardening flags
20.04 is the first LTS to carry two hardening defaults introduced in 19.10. The 19.10 release notes say it "comes with additional default hardening options enabled in GCC, including support for both stack clash protection and control-flow integrity protection," and that all packages in main were rebuilt with them, with a few exceptions. The Ubuntu compiler flags documentation describes -fstack-clash-protection as turning a possible code execution attack "into a denial of service," and covers -fcf-protection for Intel's control flow enforcement.
18.04 had already made position independent executables and immediate binding the default; its release notes say gcc defaults to PIE "as well as with immediate binding, to make more effective use of Address Space Layout Randomization." 20.04 builds with GCC 9.3.
sudo and root
The 20.04 release notes do not describe any change to sudo or to the root account. Not stated in the official release notes.
Package signing and archive keys
The 20.04 notes do not describe changes to archive signing keys. Not stated in the official release notes. For how APT verifies the archive in general, see Linux distribution package signing.
Snap Store as the default software app, and its trust model
This was a 20.04 change. The 20.04 release notes say: "The Snap Store (snap-store) replaces ubuntu-software as the default tool for finding and installing packages and snaps." The 20.10 release notes do not introduce it again.
The trust model shifts with it. Debian packages from the Ubuntu archive are built by Ubuntu, signed with archive keys and patched by Canonical's security team for packages in main, and for universe through ESM. Snaps come from the Snap Store and are confined by AppArmor and related kernel features, as the AppArmor documentation notes when it calls AppArmor a core technology "for Snaps in Ubuntu Core." The update responsibility for a third-party snap sits with its publisher, not with the Ubuntu security team. In practice that means two inventories on a 20.04 desktop. The Pro Client docs describe pro security-status output as counts "for the apt packages installed in the system," and snaps are not apt packages, so they need their own check. Our comparison of Snap Store and Flatpak security models goes further.
What changed from Ubuntu 18.04 LTS to 20.04 LTS?
| Area | 18.04 LTS "Bionic Beaver" | 20.04 LTS "Focal Fossa" | Sources |
|---|---|---|---|
| Released | Apr 2018 | 23 April 2020 | Release cycle; RC post |
| GA kernel | 4.15 | 5.4 | Release cycle; 20.04 notes |
| Last HWE kernel | 5.4 (18.04.5 HWE) | 5.15 (20.04.5 HWE) | Kernel lifecycle |
| GNOME | 3.28 | 3.36 | 18.04 notes; 20.04 notes |
| Default Python | Python 3.6; Python 2 not installed by default but in main | Python 3.8; Python 2.7 in universe, no /usr/bin/python on new installs | 18.04 notes; 20.04 notes |
| GCC | PIE and immediate binding by default | GCC 9.3, plus stack clash and control flow protection (from 19.10) | 18.04 notes; 19.10 notes |
| PHP | 7.2 | 7.4 | 20.04 notes |
| Ruby / Rails | 2.5 / 4.2.10 | 2.7 / 5.2.3 | 20.04 notes |
| Software app | Ubuntu Software | Snap Store | 20.04 notes |
| Secure Boot | Verifies bootloader, kernel and modules | Same, plus Microsoft-signed shim on arm64 | Secure Boot docs |
| Kernel lockdown | Not stated | Integrity mode enabled | 20.04 notes |
| VPN in kernel | Not stated | WireGuard built in | 20.04 notes |
| ZFS | Experimental ZFS on root support listed for curtin and MAAS | ZFS 0.8.3 with native encryption; ZFS installer option present (known issue) | 18.04 notes; 20.04 notes |
| ufw | Installed, disabled | Installed, disabled | Server firewall guide |
| i386 | Supported architecture | No upgrade offered; i386 host support dropped in 19.10 | Release cycle; 20.04 notes |
| Virtualisation | QEMU and libvirt of the 18.04 era | QEMU 4.2, libvirt 6.0, OpenStack Ussuri, Ceph 15.2.1 | 20.04 notes |
| Standard support end | May 2023 (release cycle); April 2023 (18.04 notes) | May 2025 (release cycle); April 2025 (20.04 notes) | Release cycle; release notes |
| ESM / Legacy end | May 2028 / May 2033 | May 2030 / May 2035 | ESM |
| FIPS 140-2 status (Oct 2026) | Expired | Expired | Release cycle |
The 20.04 notes also list OpenSSH 8.2, Samba 4.11, the live server installer, QEMU 4.2 and libvirt 6.0 as changes, covered in the sections above. For 18.04 itself, see our Ubuntu release history overview.
The interim releases between 18.04 and 20.04
Three interim releases sat between the two LTS versions, each supported for nine months. Their release notes explain where many 20.04 "changes" actually started.
| Release | Kernel | Desktop | Supported until | Notable changes carried into 20.04 | Source |
|---|---|---|---|---|---|
| 18.10 Cosmic Cuttlefish | 4.18 | GNOME version not stated in the release notes | July 2019 | OpenSSL 1.1.1 with TLSv1.3; fingerprint libraries in main; GCC 8.2; Python 3.6.7 | 18.10 notes |
| 19.04 Disco Dingo | 5.0 | GNOME 3.32 | January 2020 | GCC 8.3, glibc 2.29, Python 3.7.3; Samba and dependencies Python 3 only | 19.04 notes |
| 19.10 Eoan Ermine | 5.3 | GNOME 3.34 | July 2020 | ZFS on root (experimental) in the installer; stack clash and control flow protection in GCC; i386 host support dropped; lz4 kernel compression; GCC 9.2 | 19.10 notes |
| 20.10 Groovy Gorilla (after) | 5.8 | GNOME 3.38 | July 2021 | nftables default firewall backend; GCC 10, glibc 2.32 | 20.10 notes |
Two things stand out. Many security relevant defaults people associate with 20.04, such as ZFS on root, the new GCC hardening and the end of i386 as a host architecture, arrived in 19.10, so anyone who skipped the interims met them all at once when they moved from 18.04. And both 18.10 and 19.04 refused upgrades on i386 "as dropping support for that architecture is being evaluated," which the 19.10 notes then confirmed.
Where does FIPS stand for 20.04?
On 23 October 2026 the release cycle page shows 20.04 LTS with "FIPS 140-2: Expired," "DISA-STIG: Achieved" and "CIS: Achieved." 18.04 LTS shows the same three values.
The page does not define "Expired." Read it as the 20.04 FIPS 140-2 status no longer being an active certification, and confirm the exact certificate status with Canonical before you rely on 20.04 for any FIPS claim in an audit or a contract. That is our reading of the label, not a statement from the page. We tried to fetch Canonical's main FIPS page at ubuntu.com/security/fips on 23 October 2026 and it returned a server error, so we could not check what it says about 20.04 modules.
What the FIPS documentation that did load says:
- The FIPS for Ubuntu docs say Ubuntu ships cryptographic packages that are "not configured to adhere to any national standard" by default, and FIPS mode is a switch delivered through Ubuntu Pro. The core set "includes the Linux kernel and OpenSSL."
- The FIPS 140-2 modules FAQ gives two options:
pro enable fips-updatesto install the validated packages and keep receiving security updates, orpro enable fipsto install validated packages that "will not be updated until the next recertification." The FIPS enablement page recommends the fips-updates option. - The same FAQ answers "Why did TLS connections stop working with Focal (20.04 LTS)'s FIPS OpenSSL?" Newer NIST requirements in SP800-56A revision 3 limit Diffie-Hellman group negotiation, so "any TLS server configured with custom DH group information (typically via a dhparam file) will not work."
If you need a FIPS claim, the release cycle page shows 22.04 LTS with all three standards "Achieved," which makes it the cleaner target.
How do you check and upgrade a 20.04 system?
These steps use only commands from Canonical's documentation. They read state first and change nothing until the final steps.
Step 1: Confirm the release
The Ubuntu Desktop documentation uses this command to show which release is installed:
lsb_release --description
On a 20.04 machine the description names Ubuntu 20.04 and its point release.
Step 2: Check the kernel and HWE status
uname -r prints the running kernel; the Ubuntu NVIDIA driver docs use it the same way. The kernel lifecycle page gives the support check and the OEM check:
uname -r
hwe-support-status --verbose
ubuntu-drivers list-oem
A 5.4 kernel means the GA track, which is normal for a server. A 5.15 kernel means the 20.04.5 HWE track. If ubuntu-drivers list-oem prints anything, the lifecycle page says the machine is on the OEM cadence instead of HWE. To move a server to the HWE kernel, the lifecycle page gives:
sudo apt-get install --install-recommends linux-generic-hwe-20.04
Step 3: Check Ubuntu Pro and security coverage
Since standard maintenance ended in May 2025, this is the step that matters most on 20.04. The Pro Client docs explain pro security-status, which counts installed packages by main and restricted, universe and multiverse, third party, and "no longer available for download," and says whether the machine is receiving patches. The status columns explainer covers pro status.
pro security-status
pro security-status --esm-apps
sudo pro status
If the machine is not attached, the attach guide and the esm-infra guide give:
sudo pro attach
sudo pro enable esm-infra
sudo pro enable esm-apps
The attach guide says that by default the Free Personal Token is selected; paid subscribers can attach to a different token.
Step 4: Check the firewall and AppArmor
From the Server firewall guide and the Server AppArmor guide:
sudo ufw status verbose
sudo aa-status
On a stock 20.04 install, expect ufw to report inactive until you enable it.
Step 5: Check automatic updates
The automatic updates guide gives a dry run that shows what unattended-upgrades would do without installing anything:
sudo unattended-upgrade -v --dry-run
Step 6: Prepare and run the upgrade to 22.04
The release cycle page lists 22.04 LTS as the upgrade path from 20.04. The Server upgrade guide says you can only upgrade from one LTS to the next, and you cannot skip releases, so a 20.04 machine bound for 24.04 goes through 22.04 first. Before you start, the guide asks you to bring the system fully up to date, including phased updates:
sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
Then reboot if /run/reboot-required exists, check free disk space, back up your data, and expect third party repositories and PPAs to be disabled during the upgrade. Start the upgrade with:
sudo do-release-upgrade
The same guide says LTS to LTS upgrades are offered only after the first point release of the new LTS, which for 22.04 has long since happened. It also says the -d flag targets a development release and is not recommended for production. If a service cannot move yet, our guide to whether to upgrade, extend, isolate or retire end of life software covers the options.
Common mistakes
- Quoting April 2025 and May 2025 as if they were different events. They describe the same end of standard maintenance. The release notes say April; the release cycle, kernel lifecycle and ESM pages say May. Pick one, cite it, and be consistent across your inventory.
- Assuming a 20.04 desktop runs kernel 5.4. Desktop installs track HWE by default and should be on 5.15 by now. Servers default to 5.4. Check with
uname -randhwe-support-status --verboserather than assuming. - Treating Python 2.7 on 20.04 as covered by standard support. It moved to universe, so its fixes depend on esm-apps. An internal tool still on Python 2.7 is a supply chain dependency on a package that needs Ubuntu Pro to stay patched.
- Leaving ufw off on an internet facing host because "Ubuntu has a firewall". The tool is installed; the policy is not enabled.
- Copying nftables rules from a newer release onto 20.04 without checking the backend. The nftables backend became the default in 20.10.
- Stating that 20.04 is FIPS certified. The release cycle page shows FIPS 140-2 as "Expired" for 20.04 on 23 October 2026.
- Forgetting snaps in the inventory.
pro security-statuscovers apt packages. Snaps from the Snap Store are updated by their publishers. - Forgetting base images. A container built
FROM ubuntu:20.04carries the same support status as a 20.04 host, and no host-level Pro attach changes what is inside the image. See how to check if your base image operating system is end of life.
FAQ
When was Ubuntu 20.04 LTS released?
On 23 April 2020, according to the release team's release candidate post on Ubuntu Discourse. The release cycle page lists "Apr 2020," and the 20.04 release notes do not state the day.
What kernel does Ubuntu 20.04 use?
The GA kernel is Linux 5.4. Desktop installs track the HWE kernel by default, and the last 20.04 HWE kernel on the kernel lifecycle page is 5.15, from 20.04.5. Server installs stay on 5.4 unless you install linux-generic-hwe-20.04.
What version of GNOME does Ubuntu 20.04 have?
GNOME 3.36, per the 20.04 release notes.
Is Ubuntu 20.04 still supported?
Only through Ubuntu Pro. Standard security maintenance ended in May 2025 (April 2025 in the release notes). ESM runs to May 2030 and the Legacy add-on to May 2035. See Is Ubuntu 20.04 end of life? for the options.
Does Ubuntu 20.04 include Python 2?
Not on new installs. Python 2.7 moved to universe and is not installed by default; Python 3.8 is the base Python. Systems upgraded from 18.04 may still have Python 2 and a /usr/bin/python that points to it.
Did Snap Store become the default in Ubuntu 20.04 or 20.10?
In 20.04. The 20.04 release notes say the Snap Store replaces ubuntu-software as the default tool for finding and installing packages and snaps.
Does Ubuntu 20.04 have WireGuard?
Yes. The 5.4 kernel in 20.04 has WireGuard built in, according to the release notes.
Is Ubuntu 20.04 FIPS certified?
On 23 October 2026 the release cycle page shows FIPS 140-2 as "Expired" for 20.04, with DISA-STIG and CIS "Achieved." Confirm current certificate status with Canonical before making any FIPS claim about a 20.04 system.
Can I upgrade Ubuntu 20.04 directly to 24.04?
No. The Ubuntu Server upgrade guide says you cannot skip LTS releases. Upgrade to 22.04 first, then to 24.04.
Does Ubuntu 20.04 have a firewall enabled by default?
No. ufw is the default firewall tool and is installed, but it starts disabled. Enable it with the commands in the Ubuntu Server firewall guide.
Fix it without waiting for upstream
A 20.04 host on ESM still gets fixes for the Ubuntu packages Canonical covers. The application dependencies you build on top of it, and the language packages inside images built FROM ubuntu:20.04, are a different matter: Canonical does not patch those, and many upstream projects have long stopped testing against the toolchain versions 20.04 shipped.
Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.
1. Autonomous remediation: pull requests, not tickets
When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.
2. Gold Open Source: the safe version in seconds, free
gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.
3. Gold Registry: start from components that are already fixed
registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.
When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.
| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | The Gold scan GitHub Action in CI, plus Safeguard policies and gates |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch (early access) |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |
One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.
See how Safeguard would help
Safeguard scans repositories, container images and SBOM files and matches the components it finds against vulnerability databases. An image built on ubuntu:20.04 therefore shows which OS packages and versions it carries next to your application dependencies, which is how you find the services still sitting on the old base:
safeguard scan --dir .
safeguard scan --image your-image:tag
safeguard scan --sbom sbom.json
Results are written as JSON under ./output, and the platform shows every project that contains a given component and version. Safeguard does not patch the host kernel or the Ubuntu archive for you; on 20.04 that stays with Canonical's ESM and Livepatch.
In this Safeguard CLI session you install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. Before you rebuild a service from a 20.04 base onto 22.04, this is how you bring its own dependencies to fixed versions in the same change.
Click through it at your own pace, or open it full screen.
This demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. Running it inside your network lets you scan the repositories and images that still build on 20.04 without sending them anywhere else. Our guide to how the local runner and offline mode work covers the details.
Click through it at your own pace, or open it full screen.
This demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, you can ask Claude which of your projects still carry a component version you are tracking, for example a Python 2.7 era library that came along with a 20.04 base image.
Click through it at your own pace, or open it full screen.
To try it yourself, download Safeguard from safeguard.sh/download and follow the CLI docs.
Quick check
Two Ubuntu 20.04 servers were built from the same playbook. A script with a #!/usr/bin/python line runs on one and fails on the other. Why?
The 20.04 release notes say /usr/bin/python is not present on new installs, but on systems upgraded from earlier releases it keeps pointing to python2. The server where the script runs was most likely upgraded from 18.04; the other was installed fresh. Installing python-is-python3 gives a fresh install a /usr/bin/python that points to Python 3, which may still break a Python 2 script.
Which 20.04 security defaults actually started in 19.10?
The 19.10 release notes record ZFS on root as an experimental installer option, GCC defaults for stack clash protection and control flow protection with main rebuilt to use them, and the end of i386 as a host architecture. 20.04 is the first LTS to carry them, so a team moving straight from 18.04 met all of them at once.
Sources
- Ubuntu release notes: Ubuntu 20.04 LTS
- Ubuntu release notes: Ubuntu 18.04 LTS
- Ubuntu release notes: Ubuntu 18.10
- Ubuntu release notes: Ubuntu 19.04
- Ubuntu release notes: Ubuntu 19.10
- Ubuntu release notes: Ubuntu 20.10
- Ubuntu Discourse: 20.04 release candidate ISOs ready for testing
- Ubuntu Discourse: Ubuntu 20.04.1 LTS (Focal Fossa) released
- Ubuntu Discourse: Improvements for hardware support in Ubuntu Desktop installation media
- Ubuntu wiki: Releases
- Ubuntu: Release cycle
- Ubuntu: Kernel lifecycle and enablement stack
- Ubuntu: Expanded Security Maintenance
- Ubuntu: Ubuntu Pro
- Ubuntu: FIPS for Ubuntu
- Ubuntu: FIPS 140-2 modules FAQ
- Ubuntu: Enabling FIPS
- Ubuntu Security documentation: Privilege restriction
- Ubuntu Security documentation: AppArmor
- Ubuntu Security documentation: Firewall
- Ubuntu Security documentation: UEFI Secure Boot
- Ubuntu Security documentation: Default compiler and linker flags
- Ubuntu Server documentation: Firewalls
- Ubuntu Server documentation: AppArmor
- Ubuntu Server documentation: Automatic updates
- Ubuntu Server documentation: How to upgrade your Ubuntu release
- Ubuntu Desktop documentation: Switch between an LTS and interim release
- Ubuntu Desktop documentation: Install NVIDIA drivers
- Ubuntu Pro Client documentation: What does security-status do?
- Ubuntu Pro Client documentation: The pro status output explained
- Ubuntu Pro Client documentation: How to attach
- Ubuntu Pro Client documentation: Enable esm-infra
Last reviewed: 23 October 2026.