Ubuntu Core Release History: Snaps, Updates, Encryption and Dates

Ubuntu Core is the all snap edition of Ubuntu for appliances and IoT devices. A new release ships every two years on top of an Ubuntu LTS base, and each one gets 10 years of standard security maintenance, extendable to 15 years with the Legacy add-on in Ubuntu Pro. As of 24 October 2026 the current release is Ubuntu Core 26 (14 May 2026), and Core 16 has left standard maintenance.

Everything on an Ubuntu Core device, including the kernel, the bootloader assets, the root filesystem and snapd itself, is delivered as a signed snap that updates automatically and can roll back. Since Core 20, devices with UEFI Secure Boot and a TPM 2.0 encrypt their writable partitions and tie the key to measured boot. This post covers every release with its dates, how the snap types and the model assertion fit together, how updates and rollback really work, how full disk encryption is built, how signing and stores shape supply chain trust, and a step by step routine for inventorying a device.

Key takeaways

• Six releases exist: Core 16, 18, 20, 22, 24 and 26, each built on the Ubuntu LTS of the same number and each treated by Canonical as an LTS release.
• Standard security maintenance is 10 years; the Legacy add-on adds 5. Core 16 left standard maintenance in June 2026; Core 18 follows in January 2028, Core 20 in February 2030, Core 22 in June 2032, Core 24 in June 2034 and Core 26 in May 2036.
• A signed model assertion defines the device: gadget, kernel and base snaps, store, grade (dangerous, signed or secured) and whether storage must be encrypted.
• Updates are automatic, four times a day by default. Device makers can schedule or hold them, pin revisions with validation sets, and install several snaps as one all or nothing transaction.
• Fixes arrive as new snap revisions, not necessarily new versions, so judge a device by installed revision.
• Application snaps carry their own dependencies. Canonical fixes the base, snapd, certified kernels and its own system snaps; the publisher of each app snap, usually you, fixes the rest.
• Full disk encryption needs UEFI Secure Boot, TPM 2.0 and an IOMMU, or an OP-TEE trusted application on Arm.

What Ubuntu Core is, and how it differs from Ubuntu Server

Canonical's release cycle page describes Ubuntu Core as "an all-snap edition designed for appliances and IoT," and sets it apart from "Classic" Ubuntu, which uses deb packages and supports snaps only for specific applications. That one sentence is the whole difference, but its consequences go all the way down the stack.

On Ubuntu Server, apt manages a writable root filesystem and an administrator upgrades and reboots by hand. On Ubuntu Core there is no apt and no writable root. Canonical's "Inside Ubuntu Core" explanation says the kernel, boot assets, runtime environment, applications and device enablement are all delivered as snaps controlled by snapd, which is itself a snap and exposes a REST API for device management. Board specific boot assets come from a gadget snap that Canonical says is typically issued and signed by the board OEM or ODM. The snap types are covered in detail below.

Canonical's product page calls Ubuntu Core "immutable and strictly confined," with kernel, OS image and applications each updated independently.

The practical differences that matter for security and operations:

If you already run Ubuntu Server, our Ubuntu 24.04 LTS release history covers the classic side of the same base. This post stays on Core.

Every Ubuntu Core release, with support dates

Canonical's release notes state the policy directly: "A new version of Ubuntu Core is released every two years, built on the foundations of a Ubuntu LTS release. Each Ubuntu Core release is considered an LTS release." Minor updates do not arrive as point releases. They arrive continuously as new revisions of snapd and of the gadget, base and kernel snaps.

The support duration reference gives one table for all six releases. The dates below are copied from it as published when this post was reviewed.

A few details are easy to miss:

• Core 16 standard maintenance has ended. It now gets fixes only under the Legacy add-on, with snapd held at the 2.61.x series. Canonical also notes that devices running the original core base from before November 2017 must update for their certificates to remain valid.
• Legacy covers fewer architectures. For Core 16 to 22 it lists only amd64 and arm64, so armhf devices on those releases should move before standard maintenance ends.
• End dates track the Ubuntu LTS base, not the Core release date. Core 18 shipped in January 2019 but standard maintenance ends in January 2028, about ten years after Ubuntu 18.04. Legacy end dates for Core 18 to 24 all fall in June. Take dates from the table, not from arithmetic.
• Support covers specific components: snapd, the kernel snap and the base. Your gadget and application snaps are your responsibility.

Canonical's pages describe the window differently. The Core 24 release notes say "12 years of Long Term Support," the Core 26 notes and product page say "up to 15 years," and the support reference says 10 plus 5 with Legacy. Plan against the table, and confirm any Ubuntu Pro or device contract terms in writing.

Dated timeline

What each release changed

Ubuntu Core 16 established the model, with the core snap acting as both base and carrier of snapd, which therefore could not be upgraded separately.

Ubuntu Core 18 split snapd into its own upgradeable snap; from core18 onward, bases do not include it. Canonical's announcement promised 10 years of security maintenance.

Ubuntu Core 20 was the big security release. Canonical's February 2021 announcement highlighted secure boot, full disk encryption and secure device recovery. The release notes list TPM based encryption, "currently x86-only with ARM to follow," new recovery and reinstall modes, and a recovery chooser. Core 20 also introduced the ubuntu-seed, ubuntu-boot, ubuntu-save and ubuntu-data partition layout and the model grades.

Ubuntu Core 22 added validation sets, migration from Core 20, factory reset, quota groups for CPU and memory, and initial cloud-init support.

Ubuntu Core 24 focused on device makers: a new factory installation system, improved GPU integration, fleet management integration with canary releases and remote remodeling, offline upgrades and remodeling, dynamic kernel boot parameters and Raspberry Pi 5 support, on Linux 6.8. Components, optional parts of a snap, were first tested here.

Ubuntu Core 26 is the current release. Its notes list:

• a Chisel based build system for base snaps, using release specific package slice definitions so that "every file in the filesystem can now be attributed to its originating slice and source package," and a 7% smaller base image;
• an updated snap delta format, with core base snap updates falling from 16 MB to 1.5 MB, and OTA update sizes reduced by up to 90%;
• CRA compliance support, under which Canonical says it assumes manufacturer responsibilities for the operating system release cycle, including security maintenance of core modules, CVE monitoring, coordinated disclosure and IEC 62443-4-1 compliance;
• Canonical Livepatch support, so critical kernel fixes can apply without a reboot;
• components generally available;
• an OpenAPI compliant snapd REST API with machine readable documentation;
• removal of the Python interpreter from the core base snap from core26 onward. Snaps that relied on the base's Python must now bundle their own through the Snapcraft Python plugin, and a separate track is planned for users who need cloud-init with its Python environment.

How snaps work in Ubuntu Core

The snap types

Canonical's "Snaps in Ubuntu Core" page lists the types that make up a device:

The base snap is chosen by the model and pins the release. A Core 24 image uses core24. Kernel and gadget tracks follow the same number, so the release notes show a Core 24 image picking a pc-kernel from a track such as 24/stable, 24-hwe/stable or 24-rt/stable. Canonical states that kernel snaps built on interim, non LTS Ubuntu releases are not supported in Ubuntu Core images.

Channels and revisions

Every snap is published into channels made of a track and a risk level, such as 22/stable. Each upload gets a store revision number that, per the snapcraft docs, only differentiates uploads and does not order releases; a device installs whatever revision the publisher released to its channel.

Canonical's CVE remediation page is blunt: "security fixes are delivered through new snap revisions, not necessarily through new snap versions." Tools that compare version strings can misjudge a device. Track revisions.

By default Ubuntu Core keeps three revisions of each snap on disk (classic Ubuntu keeps two), controlled by the refresh.retain system option, which accepts values from 2 to 20. Older revisions are what make rollback and snap revert possible.

Strict confinement and interfaces

The snapcraft documentation describes two confinement levels for published snaps. Strict confinement, used by most snaps, isolates the application so it cannot reach files, the network, processes or devices without an interface. Classic confinement gives access similar to a deb package and needs manual approval from the store. A third mode, devmode, is for development only: devmode snaps cannot be released to the stable channel and do not refresh automatically.

Canonical's security and sandboxing page explains what happens when an app starts: snapd gives it a security label of the form snap.<snap>.<app>, a private mount namespace and /tmp, a seccomp allowlist filter and a command specific AppArmor profile, plus device cgroup rules when an interface needs hardware.

Interfaces are the only way out of that sandbox. A snap declares plugs for what it needs and connects them to slots that provide it, automatically for some interfaces and manually or by store assertion for others. snap connections shows exactly which privileges each snap holds. Core 26 adds a system option for self service interface connections, so review your gadget defaults before shipping.

Classic confinement exists on Core only in narrow cases, and a product that depends on classic snaps gives up most of the isolation story. For a wider comparison of sandbox models, see our post on snap store and Flatpak security models.

The model assertion

An assertion, in the snapcraft documentation's words, is "a digitally signed document that either verifies the validity of a process, as attested by the signer, or carries policy information." The model assertion is the most important one on a device. Canonical's reference says it "contains the fundamental definition of a snap-based device" and is "signed by the brand account owning the device definition."

The fields that matter most for security:

The grade field sets the rules. Canonical's full disk encryption page defines them: dangerous relaxes constraints so unasserted, devmode or extra snaps can be used and is meant only for development; signed, the default, allows no unasserted snaps and no snaps outside the model in the recovery system; secured adds the requirement that the device uses full disk encryption and secure boot.

The model drives image creation through ubuntu-image, is verified at first boot, and is presented at registration so the store can decide who may issue the device's serial assertion.

Transactional updates, rollback and recovery

What a refresh does

snapd checks for updates four times a day by default. For an app snap, a refresh downloads the new revision, checks its assertions, mounts it beside the old one, copies revision specific data and switches over. If a step fails, snapd undoes the change.

Essential snaps get extra care. The release notes say that refreshing the base or kernel triggers an automatic reboot, and refreshing the gadget triggers one if boot assets change. Canonical's "Inside Ubuntu Core" page explains that snap-bootstrap, which runs in the initramfs, updates bootloader environment variables on kernel and base refreshes "to implement A/B or try-boot functionality." In practice: the system boots once into the new kernel or base in a trial state. If the boot does not complete and snapd does not mark it good, the next boot falls back to the previous revision, which is still on disk.

Transactional updates across several snaps

By default every snap in a refresh is its own transaction. The snapcraft documentation describes an option that changes this: --transaction=all-snaps on snap install or snap refresh makes the whole set succeed or fail together, and if even one snap fails, all snaps in the set revert, including those that had already updated. Canonical gives the example of updating a kernel and gadget snap together on Core. The documentation also notes a current gap: no message or log tells you the set was installed as a single transaction.

Holding and scheduling refreshes

Unattended updates are the point of Core, but device makers need a say in when they happen. The manage updates documentation lists four system options and a command:

• refresh.timer sets the schedule, with a lower bound of once every 20 minutes. For example mon,10:00,,fri,15:00 or fri5,23:00-01:00 for the last Friday of the month.
• refresh.hold delays the next refresh to an RFC 3339 date, up to 90 days, after which a refresh happens regardless.
• refresh.metered=hold pauses refreshes on connections NetworkManager reports as metered.
• refresh.retain sets how many revisions to keep.
• snap refresh --hold=<duration> (snapd 2.58 and later) holds auto refreshes for named snaps, or for everything, for a duration or forever.

A hold on named snaps blocks their auto refreshes and general snap refresh requests, but a targeted refresh still goes through. A hold with no snaps named covers only auto refreshes. A forever hold can stop security fixes reaching a device, so give every hold an end date in your change records.

Pinning exact revisions: gating and validation sets

Holding time is not the same as controlling content. Ubuntu Core has two mechanisms for deciding exactly which revisions a device may run.

Gating snaps are the older mechanism. The store team links a gating snap to the snaps it controls, and the gating snap's publisher signs validation assertions with a registered key (snapcraft validate) naming the approved revision of each gated snap. While the gating snap is installed, gated snaps refresh only to approved revisions, which Canonical says is useful for testing new base snap revisions before devices take them.

Validation sets, added in Core 22, are the more general mechanism. A validation-set assertion lists snaps (and components) with a presence of required, optional or invalid and, optionally, a fixed revision. It can be declared in the model with a mode of enforce or prefer-enforce, and with or without a fixed sequence number. An enforced set stops listed snaps from being removed. Validation sets are how you make "the tested combination of kernel, gadget, base and app revisions" a signed, enforceable fact rather than a hope.

Recovery modes

Core 20 introduced recovery modes that sit on top of the partition layout:

Warning: factory reset and install mode destroy data on the device. Before using either, confirm which device you are connected to (snap model and hostname), confirm that anything in ubuntu-data you need is backed up, and for install mode, record any configuration stored in ubuntu-save. Canonical notes that reinstalling can fail when the TPM is still assigned to a previous installation and that the TPM may need clearing from firmware settings first.

The ubuntu-seed partition holds the recovery systems, each with a model assertion, other assertions and a pool of snaps. Canonical says it must hold two recovery systems for remodeling to work, so size it for that from the first image.

Remodeling: moving to a new release

There is no do-release-upgrade on Core. Canonical's upgrade guide says a device can move to a later release by remodeling if it has a serial (from a serial assertion or the Snap Store), an unchanged storage layout and consistent base and system snaps. You edit the model to use the new base (for example core22 instead of core20) and the new kernel and gadget tracks, increment the revision field, sign it with the same brand key, copy it to the device and run sudo snap remodel <new-model>. The device reboots several times.

Two limits are important. First, "It is not currently possible to upgrade from releases earlier than UC20," and devices built from Canonical's reference images or reference model assertions cannot be remodeled this way. Second, Canonical's remodeling page says remodeling "can never downgrade the system's base snap." Remodeling also creates a new recovery system, which is why seed partition size matters.

For fleets still on Core 16 or 18, that first limit is the most important operational fact in this post. There is no in place path to Core 20 or later. The route is a new image and reinstallation, with data migrated through whatever mechanism your product supports.

Full disk encryption, Secure Boot and the TPM

Requirements

Canonical's full disk encryption page says Ubuntu Core encrypts "whenever the hardware allows," and that built in support needs UEFI Secure Boot, TPM 2.0 and an IOMMU to secure data transfers. External I2C or SPI attached TPM modules are not currently supported. For other platforms, such as a Raspberry Pi, the implementation is board specific and usually involves custom gadget and kernel snaps; Core 20 and 22 provide an fde-setup hook for this.

On Arm, Canonical documents a second route: an OP-TEE trusted application. snapd integrates with a Canonical provided trusted application that seals and unseals LUKS keys inside the Arm secure world. During installation snapd looks first for a kernel fde-setup hook, then for the OP-TEE trusted application, and finally falls back to TPM sealing. At boot it asks the trusted application to unseal the key, unlocks the partition and then locks the trusted application for the rest of the boot. The firmware must ship OP-TEE with that application built as an early trusted application, and the kernel must expose /dev/tee0 and /dev/teepriv0.

How the key is bound to the boot chain

Canonical describes the boot sequence in four steps:

1. Firmware verifies the bootloaders and kernel signatures through UEFI Secure Boot.
2. Those components and the kernel command line are measured into the TPM.
3. The snapd code in the initramfs measures the device's model assertion on top of that.
4. snapd then verifies other snaps against their assertions as needed.

The disk key is sealed to that full EFI state, including the kernel command line, and is unsealed by initramfs code inside the Secure Boot protected kernel.efi. Only the ubuntu-save and ubuntu-data partitions are encrypted. ubuntu-seed and ubuntu-boot stay readable because the firmware has to read them before anything can be unlocked, which is why they are read only and why ubuntu-save becomes mandatory on encrypted systems (Canonical recommends 32 MB).

If the measurements do not match, for example after a boot medium swap or a changed kernel command line, the TPM will not release the key and the device asks for a recovery key. Keep recovery keys for every device you ship somewhere you can find them.

Grade and storage safety together

The model's grade and storage-safety decide whether a device encrypts. Canonical publishes the full matrix. In short:

A production device that must never run unencrypted should use grade: secured, or at least storage-safety: encrypted, so that hardware or firmware misconfiguration fails at the factory instead of shipping a device in the clear.

Signing, stores and supply chain trust

Assertions all the way down

Snaps and stores rely on a chain of assertions. The snapcraft documentation lists the types: account, account-key, model, serial, snap-build, snap-declaration, snap-revision, store, system-user, validation and validation-set. On Core the important links are:

• the snap-revision assertion, the store's acknowledgement of a specific upload, which carries the snap's SHA3-384 hash;
• the snap-declaration, which ties the snap ID and name to a publisher and carries policy for privileged interfaces;
• the account-key, which carries the public key that signs assertions;
• the model and serial, which tie a physical device to a brand and a key the device holds.

Canonical's security page lists OpenPGP v4 signatures with RSA 4096 or 8192 bit keys for assertions, SHA3-384 for snap hashes and TLS 1.2 or later for store connections. Installing a downloaded snap needs snap ack on its assertion first, and a device on any grade but dangerous installs only code the store has signed for.

Public Snap Store, dedicated stores and the proxy

By default a Core device talks to Canonical's public Snap Store. Canonical documents two other options:

• A dedicated Snap Store (formerly called a brand store) is restricted to the brand's devices, with content curated by the owner, account delegation, proxy server support, a custom dashboard and API access. Canonical hosts and monitors it, as it does the public store. The model's store field points devices at it.
• The Enterprise Store is an on premises proxy and cache for air gapped or restricted networks.

What this means for supply chain trust

Signing proves origin and integrity, not the absence of known vulnerabilities. The assertion chain says nothing about the version of zlib or OpenSSL a publisher bundled. Canonical's CVE remediation page draws the lines:

• CVEs in base snaps, snapd and certified kernel snaps are fixed by Canonical through new revisions that devices pick up automatically.
• CVEs in application snaps "must be addressed by the snap publisher, who is responsible for rebuilding and releasing an updated snap."
• For gadget snaps, Canonical maintains GRUB on supported x86 platforms; for third party gadgets, the gadget publisher owns bootloader fixes such as U-Boot.

So Canonical vouches for the OS layers it publishes, the store vouches for who uploaded what, and you vouch for everything you built, often from npm, PyPI, Maven, Go or Cargo dependencies. Canonical publishes SBOMs for Core 20, 22 and 24, with Core 26's under review; SBOMs for your snaps are yours to produce.

Treat brand signing keys like code signing keys: few holders, hardware protection where possible, and a written recovery plan.

Ubuntu Core, Ubuntu Server, Raspberry Pi OS and Yocto compared

Device makers usually start from one of these four. Two are Canonical distributions, one is a Debian derivative for one family of boards, and one is a build system for making your own distribution.

For Raspberry Pi specifics, including bootloader EEPROM updates, see our Raspberry Pi OS release history. The Yocto dates come from the Yocto Project's releases page, which notes that future LTS releases are planned for four years.

No option removes the work. Ubuntu Core hands OS maintenance to Canonical for a long, published window; Yocto gives full control at the price of owning every CVE.

Walkthrough: inventory an Ubuntu Core device and control its updates

These steps work on Ubuntu Core 20 and later over SSH, and most work on Core 18. They read state and change refresh settings only. Nothing here erases data.

Step 1: confirm the release and the model

# Which Ubuntu Core release is this?
cat /etc/os-release

# Brand, model, grade and serial
snap model

# Full model details, including grade and storage-safety
snap model --verbose

# The signed model assertion itself, to archive
snap model --assertion > model.assert

# The device's serial assertion
snap model --serial --assertion > serial.assert

/etc/os-release gives NAME="Ubuntu Core" and VERSION_ID, for example "22". snap model --verbose shows the base (such as core22), the grade and, if set, the storage-safety. Record the brand ID: if it is Canonical's, the device runs a reference model and cannot be upgraded by remodeling until it is rebuilt on your own model.

Step 2: check whether the data partitions are encrypted

# Look for crypto_LUKS on the ubuntu-data and ubuntu-save partitions
lsblk -f

If ubuntu-data and ubuntu-save show as LUKS volumes, full disk encryption is active. If your model's grade is signed and the partitions are plain ext4, the hardware or firmware did not meet the requirements at install time and the device fell back to unencrypted storage, exactly as Canonical's matrix says it will.

Step 3: list every snap, revision and channel

# Installed snaps with revision, tracking channel and publisher
snap list

# Every revision on disk, including disabled ones kept for rollback
snap list --all

# Detail for one snap: channels available, installed revision, confinement
snap info --verbose core22

In the snap list --all output, disabled in the Notes column marks older revisions retained for rollback. held marks a snap with a refresh hold.

Step 4: export an inventory you can compare across devices

# On your workstation: pull the snap list and model from one device
ssh user@device 'snap model --verbose; echo; snap list --all' > device-001.txt

# Turn the snap table into CSV: name, version, revision, tracking, publisher, notes
ssh user@device 'snap list --all' \
  | awk 'NR>1 {notes=$6; print $1","$2","$3","$4","$5","notes}' > device-001-snaps.csv

Store the CSV with the assertions from step 1. It answers "which devices have revision N or later of snap X" without logging in again. If your fleet uses a device management service, use its inventory export and keep this as a spot check.

For the base snap, Canonical ships a ChangeLog that lists the package updates in each revision (Core 26 does not yet include one):

# Package changes rolled into the installed base snap
less /snap/core22/current/usr/share/doc/ChangeLog

Step 5: see what will change at the next refresh

# When the last refresh ran and when the next is due
snap refresh --time

# Which snaps have updates waiting
snap refresh --list

# History of changes, and the tasks inside one change
snap changes
snap tasks <change-id>

snap tasks shows each step of a refresh, including "Fetch and check assertions," which is the point where the store's signature on the new revision is verified.

Step 6: schedule or hold refreshes

# Refresh only on the second Monday through Wednesday, 23:00 to 24:00
sudo snap set system refresh.timer=mon2-wed,23:00-24:00

# Pause refreshes on metered links such as LTE
sudo snap set system refresh.metered=hold

# Hold auto refreshes of one snap for 72 hours while you test a new revision
sudo snap refresh --hold=72h my-app

# Remove the hold when testing is done
sudo snap refresh --unhold my-app

# Keep four revisions on disk instead of three
sudo snap set system refresh.retain=4

Use holds for short tests with an end date; for long term control use a validation set or gating snap, which are signed and visible.

Step 7: check validation sets and interface connections

# Validation sets known to the device and whether they are enforced
snap validate

# Validation set assertions present on the device
snap known validation-set

# Interfaces each snap uses, and whether each is connected
snap connections

Read the snap connections output with a security eye. Interfaces such as system-files, hardware-observe, raw-usb, network-control or block-devices grant real privilege.

Step 8: roll back a bad app refresh

# Return my-app to its previous revision (configuration reverts too)
sudo snap revert my-app

# Or to a specific retained revision
sudo snap revert my-app --revision 41

Canonical's documentation notes that reverting changes the snap revision and its configuration but not data stored in the snap's common directories, and that the device will not auto refresh back to the revision you reverted from. It will refresh again when the publisher releases a new, different revision. snapd itself must be reverted on its own with no other changes pending.

The EU Cyber Resilience Act and Ubuntu Core products

The CRA, Regulation (EU) 2024/2847, entered into force on 10 December 2024. According to the European Commission, its reporting obligations apply from 11 September 2026 and its main obligations from 11 December 2027. If you sell a device in the EU that runs Ubuntu Core, you are its manufacturer under the Act, and the Core release you pick shapes several duties.

Support period. The Commission's summary says the manufacturer must determine a support period during which vulnerabilities "are handled effectively," with its end month and year stated clearly at the time of purchase. Article 13 of the Regulation sets out how to choose it. The Core release you ship caps what you can promise without extra contracts: a device shipping on Core 24 in late 2026 has standard maintenance to June 2034, while one shipping on Core 22 has it only to June 2032.

Update delivery. Ubuntu Core's automatic refresh mechanism already delivers security fixes without user action. Your obligations still apply to your own snaps: if a dependency in your application snap has a vulnerability, the fix only reaches devices when you rebuild and publish a new revision.

Vulnerability handling and reporting. The Commission's summary sets out the reporting timeline for actively exploited vulnerabilities and severe incidents: an early warning within 24 hours, a main notification within 72 hours, and a final report within 14 days after a corrective measure is available for an exploited vulnerability, or within one month of the 72 hour notification for a severe incident. Notifications go to the national CSIRT of the manufacturer's main establishment and to ENISA. You need to know what is inside every snap you ship to meet those deadlines.

Component accountability. Ubuntu Core 26's release notes say Canonical "assumes Manufacturer responsibilities for the operating system release cycle," with security maintenance for core modules, continuous CVE monitoring, coordinated disclosure and IEC 62443-4-1 compliance. Canonical's CVE page draws the line at base snaps, snapd, certified kernels and its own system and gadget snaps. You cover your own gadget, any uncertified kernel and every application snap.

SBOMs. Canonical's SBOM page says "SBOMs are required under the EU Cyber Resilience Act" and links SBOMs for Core 20, 22 and 24. You still need SBOMs for your own snaps, generated from their source and lockfiles.

A practical CRA checklist:

This is not legal advice.

Common mistakes

• Shipping a production image with grade: dangerous. It allows unasserted and devmode snaps and extra snaps in the recovery system. Keep a separate development model, as Canonical suggests, and build production images from a signed or secured model.
• Building products on Canonical's reference model. Reference models are signed by Canonical's brand, and devices built from them cannot be upgraded by remodeling. Build on your own brand's model from day one.
• Judging patch status by version string. Canonical says security fixes arrive as new revisions and the version field "may not change." Compare revisions.
• Assuming Canonical patches your app snaps. It does not. Application snaps bundle their own dependencies, and their publisher owns their CVEs.
• Leaving holds in place. snap refresh --hold with no duration means forever. It is easy to set during an incident and forget for a year.
• Counting on Legacy for armhf devices on Core 22 or earlier. Canonical's table lists only amd64 and arm64 for Legacy on those releases.
• Expecting an in place path from Core 16 or 18. Remodeling starts at Core 20. Older fleets need a reimage plan.

FAQ

What is the latest version of Ubuntu Core?

Ubuntu Core 26, released on 14 May 2026 and built on Ubuntu 26.04 LTS. Its standard security maintenance runs to May 2036 and Legacy maintenance to May 2041, according to Canonical's support duration table. Core 24, released on 4 June 2024, remains supported to June 2034.

How long is Ubuntu Core supported?

Each release gets 10 years of standard security maintenance. The Legacy add-on, available through Ubuntu Pro, adds 5 years for 15 in total. Canonical's support covers snapd, the kernel snap and the base for each release, not your own gadget or application snaps.

Is Ubuntu Core 16 still supported?

Not under standard maintenance. Canonical's table shows standard security maintenance for Core 16 ended in June 2026. Legacy maintenance for amd64 and arm64 runs until June 2031 with snapd held at the 2.61.x series. Core 16 devices cannot be remodeled to a newer release.

What is the difference between Ubuntu Core and Ubuntu Server?

Ubuntu Server is classic Ubuntu with a writable filesystem and deb packages managed by apt. Ubuntu Core is immutable and built entirely from snaps, including the kernel and boot assets, with automatic transactional updates, strict confinement and a signed model assertion that fixes what may be installed.

Can I upgrade Ubuntu Core 20 to 22 or 24?

Yes, by remodeling. You sign a new model assertion with the newer base and kernel and gadget tracks, increment its revision, copy it to the device and run sudo snap remodel. The device needs a serial and an unchanged storage layout. Upgrades from releases earlier than Core 20, or from reference models, are not supported.

How do I stop Ubuntu Core from updating automatically?

Use snap refresh --hold=<duration> for named snaps or for the whole system, or set refresh.hold to a date up to 90 days ahead. Use refresh.timer to choose when refreshes happen. For production fleets, pin tested revisions with a validation set instead of turning updates off.

Does Ubuntu Core encrypt the disk?

Yes, when the hardware supports it. Built in full disk encryption needs UEFI Secure Boot, TPM 2.0 and an IOMMU. Arm devices can use an OP-TEE trusted application or a board specific hook. The model's grade and storage-safety settings decide whether encryption is required, preferred or skipped.

Who fixes vulnerabilities in snaps on Ubuntu Core?

Canonical fixes base snaps, snapd, certified kernel snaps and its own system and gadget snaps. The publisher of each application snap must fix CVEs in what that snap bundles, and the publisher of a third party gadget snap owns its bootloader fixes.

Canonical maintains the base, snapd and certified kernels for the whole support window, and nothing below changes that or replaces those updates. But almost every Ubuntu Core product also ships application snaps built from npm, PyPI, Maven, Go or Cargo dependencies, and Canonical's own CVE guidance says those fixes are the publisher's job, so they need their own inventory and their own fix path before you rebuild and publish the next revision.

Fix it without waiting for upstream

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.

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

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. For a Core based product, the useful place to run it is the build host or CI machine where your application snaps are built, scanning the source repositories and lockfiles that snapcraft pulls in, so you know what each snap revision bundles before it reaches the store.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant 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. The same flow applies to a Node.js service you package as a snap for Ubuntu Core: the fix lands in your repository, and you then rebuild the snap and release a new revision, which devices pick up on their next refresh.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once your snap source repositories are in Safeguard, that connection lets you ask which projects contain a given component and version, which is the first question when a CVE lands in a library your application snaps bundle and the CRA reporting clock may be running.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Ubuntu Core overview
• Ubuntu release cycle
• Ubuntu Core documentation
• Ubuntu Core support duration
• Ubuntu Core release notes
• Ubuntu Core 26 release notes
• Ubuntu Core software bill of materials
• Ubuntu Core: inside Ubuntu Core
• Ubuntu Core: snaps in Ubuntu Core
• Ubuntu Core: storage layout
• Ubuntu Core: full disk encryption
• Ubuntu Core: full disk encryption with OP-TEE
• Ubuntu Core: recovery modes
• Ubuntu Core: refresh control
• Ubuntu Core: CVE remediation
• Ubuntu Core: security and sandboxing
• Ubuntu Core: store overview
• Ubuntu Core: dedicated snap store
• Ubuntu Core: model assertion
• Ubuntu Core: validation-set assertion
• Ubuntu Core: upgrade Ubuntu Core
• Ubuntu Core: remodeling
• Snap documentation: manage updates
• Snap documentation: transactional updates
• Snap documentation: revisions
• Snap documentation: validation sets
• Snap documentation: snap confinement
• Snap documentation: all about interfaces
• Snap documentation: assertions
• Canonical: Ubuntu Core 18 released (22 January 2019)
• Canonical: Ubuntu Core 20 secures Linux for IoT (2 February 2021)
• European Commission: Cyber Resilience Act
• European Commission: Cyber Resilience Act summary
• Yocto Project releases

Last reviewed: 24 October 2026. Canonical updates the Ubuntu Core support table and release notes as new releases ship; check the support duration page before declaring a support period for a product.