ChromeOS Release History: Channels, Verified Boot and Update Expiration

ChromeOS is versioned by Chrome milestone (M156 is current stable as of 23 October 2026) plus a platform build number (16836.19.0), and it ships through Canary, Dev, Beta and Stable channels, with Long Term Support Candidate (LTC) and Long Term Support (LTS) channels for managed fleets. Every boot is verified from a read-only firmware root key down to the kernel and a dm-verity protected root file system. Each device stops getting updates on its auto update expiration date, which for platforms released from 2021 onward is 10 years after the platform's release.

Key takeaways

• Two version numbers matter. The Chrome milestone (for example 156) tells you the feature set. The platform version (for example 16836.19.0) identifies the exact signed OS image. Chrome Releases posts list both for every channel update.
• Stable takes a new milestone about every four weeks. Chrome on other platforms moved to a two week milestone cadence in autumn 2026 according to the public Chromium schedule, but ChromeOS Stable went from M152 to M154 to M156, so ChromeOS still takes roughly one milestone a month.
• LTS is a six month feature train with security fixes every two weeks. LTS-150 replaced LTS-144 on 6 October 2026. Google warns that some fixes can take up to nine months to reach LTS when the code has diverged.
• Verified boot is a chain of signatures, not a single check. Read-only firmware holds the root key, verifies read-write firmware, which verifies the kernel, which then checks every 4 KB root file system block on read through dm-verity.
• Write protection is the anchor. The read-only firmware is protected by a hardware write protect signal, historically a screw and now a Google security chip. Disabling it needs physical access.
• Updates use A/B slots. The updater writes the inactive kernel and root partitions, then flips GPT priority bits. A new slot gets a limited number of tries; if it never boots successfully, the device falls back to the previous slot.
• Auto update expiration is per platform, not per purchase. A device bought late in its platform's life gets fewer years. Check Settings, About ChromeOS, Additional details, Update schedule.
• ChromeOS Flex is not the same security model. Flex on PCs and Macs has no Google security chip, so ChromeOS verified boot is not available; Google recommends UEFI Secure Boot instead, and firmware updates come from the PC maker.

This post goes one level deeper than our general boot security posts. For the difference between secure, trusted and measured boot, see secure boot, trusted boot and measured boot compared. For the firmware project that most Chromebooks boot, see coreboot explained. For the phone side of Google's boot chain, see Android Verified Boot and the chain of trust, and for Android's own version history, see Android release history from 10 to 16.

How ChromeOS versioning and the release cycle work

Milestones and platform versions

ChromeOS shares its milestone number with the Chrome browser. When Chrome Releases announces a ChromeOS Stable update, the post gives three identifiers. On 20 October 2026, for example, the Stable post read "M-156, ChromeOS version 16836.19.0 (Browser version 156.0.8078.42)". The milestone (156) is the feature release. The ChromeOS version, which LTS posts call the "Platform Version", is the signed OS image built from a branch. The browser version is the Chrome build bundled into that image.

The platform version's first number moves with each branch. Looking across Chrome Releases posts from July to October 2026, M150 images were 16700.x, M151 were 16733.x, M152 were 16765.x, M154 were 16805.x, M155 (on Beta) were 16820.x, M156 were 16836.x and M157 (on Beta and Dev) are 16852.x. The second number climbs as the branch takes fixes: M152 went through 16765.41.0, 16765.49.0 and 16765.51.0 on Stable in September 2026. That is the number to compare when someone asks whether two Chromebooks are on the same build.

How the cadence has changed

ChromeOS has changed its rhythm several times; these are the changes worth knowing about.

In June 2021 the Chromium blog announced that "Chrome OS will move to a 4-week stable channel starting with M96 in Q4", following Chrome's own move to four week milestones from Chrome 94. To bridge the gap, ChromeOS skipped M95. The same post promised a new channel "with a 6-month update cadence by M96" for enterprise and education, which became LTS. The current LTS admin guide still says it applies "for ChromeOS version 96 and later".

In March 2020, Chrome and Chrome OS releases were paused and then resumed on an adjusted schedule, which the Chromium blog announced on 26 March 2020. It is a reminder that the calendar is a plan, not a contract.

In 2026, the public Chromium milestone schedule (the data behind the Chromium Dash schedule page) shows Chrome milestones landing two weeks apart from M153 onward: M153 Stable on 8 September 2026, M154 on 22 September, M155 on 6 October and M156 on 20 October. ChromeOS did not follow every step. Its Stable channel went from M152 to M154 on 9 October 2026 and then to M156 on 20 October 2026. Google's Chromebook help page still describes major Stable changes "every 4 weeks". We could not find a Google post that announces the ChromeOS side of the 2026 change, so treat the alternating pattern as observed behavior, and check Chrome Releases before you plan around it.

The channels

Two switching details matter. On an unmanaged Chromebook, Google warns that moving to a more stable channel "will delete everything from your Chromebook" through a powerwash. On a managed device, a move from Dev to Beta or Beta to Stable waits until the more stable channel catches up to the installed version, and apps, data and settings are kept.

Long Term Support in detail

The LTS guide describes three stages. A device on LTC gets the next LTS feature set three months before it reaches LTS, then automatically moves to the next LTC every six months. A device on LTS gets the next LTS version every six months and security updates every two weeks in between. Devices left on LTC when LTS becomes available keep taking security updates until the next LTC begins.

The real world rhythm in 2026 looked like this, based on Chrome Releases and the Chromium schedule data:

Notice the jump from 150 to 160. Under the older four week cadence, six months was about six milestones (138, 144, 150). With Chrome milestones now two weeks apart, the next LTS in the schedule data is ten milestones later. The LTS guide's own worked example still uses 138 and 144.

The security trade off is stated plainly in Google's guide: only targeted security fixes go into LTS, "some critical security fixes might not be possible in LTS due to divergence in the code base", and there "could, however, be a 9 month delay in a security fix deploying to LTS". The guide recommends LTS for cases such as unattended devices, standardized school assessments and healthcare deployments, while still recommending the latest Stable for most devices. There is also a switching trap: a device already on Stable 139 cannot join LTC-138; it effectively sits pinned on 139 without updates until 144 reaches both Stable and LTC, which the guide warns means missed security updates.

Timeline: key ChromeOS milestones

Every date below was checked against a Google or Chromium page that we fetched. Where we could not confirm a date on a primary source, the event is described in the text instead of placed in the table.

The Linux development environment, Chromebook Plus and the Google security chip are milestones too, but we could not fetch a primary source launch date for them, so they are left out of the table.

How ChromeOS verified boot works

The design goal

The Chromium OS verified boot design document sets a narrow, honest goal. Verified boot "is focused on stopping the opportunistic attacker", and it is not expected to catch every attack. The aim is that a compromise cannot persist: if malware gets in through the browser and modifies the root partition or read-write firmware, the next boot detects the change and offers recovery. The same document says restricting the device to Google code "is not a goal", that there is no dependence on remote attestation, and that "Users will always own their computers." That philosophy explains why developer mode exists and why write protection can be removed with physical access.

The Chromium OS security overview frames it the same way. Its first principle is "The perfect is the enemy of the good", and its second is defense in depth. Verified boot is one layer; sandboxing, process isolation and per-user encrypted storage are others.

The chain, stage by stage

The firmware boot and recovery design document explains the first step. A small read-only stub computes a SHA-2 hash of the read-write firmware, and an RSA signature over that hash is checked with the root key. The root key's private half is never on the device. The read-write firmware then carries its own subkey and the hashes needed for the next stage, signed by that subkey, so that updates do not need the write protected key for every release. There are two copies of read-write firmware so that one corrupt copy does not leave the device unbootable.

The verified boot data structures document describes how those signatures are packaged. Firmware and kernel images both begin with a key block that holds the subkey for the rest of the image. The key block is either signed by Google, or for self-signed developer images only checksummed. A firmware image is a key block, a firmware preamble and a firmware body; the preamble holds the signature of the body and the subkey used to validate the kernel. A kernel image is a key block, a kernel preamble and a kernel body. Keys carry their own key version and algorithm, so firmware can refuse an older image even when its signature is valid, which is how ChromeOS resists rollback to a vulnerable but genuinely signed build.

dm-verity and the root file system

Checking a whole root partition before boot would be slow. The original design document estimated that full verification by firmware "would add at least 5 seconds to the boot-time on current netbooks". Instead, the verified kernel sets up a transparent block device between the file system and every process. Each block that is read is checked against a cryptographic hash stored in a central hash collection, either in its own partition or after the file system.

The design document's early numbers make the cost concrete: 4 KB blocks, about 19,200 SHA-1 hashes for a 75 MB root file system, and 0.2 to 0.5 milliseconds per 4 KB hash on netbooks of that era. Today the upstream Linux kernel's device-mapper "verity" target, documented on docs.kernel.org, provides "transparent integrity checking of block devices using a cryptographic digest provided by the kernel crypto API", with a hash tree, a salt and a configurable hash algorithm. The idea Chromium OS designed is now a standard kernel feature that Android and many embedded systems also use.

The consequence for updates is important. Because every block of the root file system is covered by a signed hash tree, an update has to produce a partition that is identical bit for bit to what Google signed. That requirement shapes the whole update system described below.

Write protection: the physical anchor

The ChromeOS write protection reference says "the entire system security hinges upon" the integrity of the read-only firmware, and that integrity is guaranteed by a write protect (WP) signal wired to the flash chip. With WP asserted, the flash chip itself rejects writes to the protected range, so even code running with full privileges on the CPU cannot change the read-only firmware.

How WP is controlled has changed over time:

• Write protect screw. Older Chromebooks used a physical screw on the motherboard. Removing it needs the case opened, which the document calls "a non-trivial amount of effort and time".
• Google security chip. Newer devices route WP through a separate secure element whose firmware is called Cr50 in the reference. Disabling WP still takes physical presence and time, and can be limited to device owners.
• Battery disconnect. On some devices with the security chip, opening the case and disconnecting the battery disables WP. The document points to a separate guide for devices from 2023 onward where this alone may not be enough.
• Software write protect. On top of the hardware signal, the flash status register's SRWD and block protect bits define which range is protected. Software WP cannot be disabled while hardware WP is on.

The reference also explains why the protection can be removed at all: the ChromeOS team "strongly believes that when someone buys a device, they own it fully", including the right to run other operating systems.

Recovery and developer mode

The firmware design keeps recovery firmware in the same read-only region as the boot stub, so a firmware update or a software attack cannot corrupt it. Recovery boots a signed image from USB or SD media, which contains a clean copy of firmware and root file system. Newer disk layouts (version 3 and later) also reserve two MiniOS recovery partitions on the internal disk, according to the disk format reference. Developer mode accepts self-signed images and shows a warning screen at boot, which the design keeps visible so that a device running unofficial code is obvious to its user.

How this maps to NIST firmware guidance

NIST SP 800-147, BIOS Protection Guidelines (April 2011), is about "preventing the unauthorized modification" of PC firmware: authenticated updates, integrity protection and making sure the protections cannot be bypassed. NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018), adds the expectation that platforms detect corruption and recover to a known good state. ChromeOS meets the spirit of both through design rather than add-on tooling. Firmware updates are signed and verified by firmware that cannot itself be rewritten in software. Corruption of read-write firmware, kernel or root file system is detected at boot. Recovery comes from read-only firmware and signed media. If you write security requirements that cite these NIST documents, the Chromium OS design pages are a clear reference implementation to point at.

How A/B partitions and background updates work

The disk layout

The Chromium OS disk format reference lists the partitions on a ChromeOS disk:

The file system and autoupdate design document states the key rules. The root file system is mounted read-only. "Not even the autoupdater will edit the currently-booted root file system." All state lives on the stateful partition. Only the updater, and processes running as root, can write the inactive system partition.

What the updater does

The autoupdate details document describes an update as an ordered list of operations applied to the inactive "install partition". The original operation types were copy (move blocks within the partition), bsdiff (read old blocks, apply a binary patch in memory and write the result), replace (write a data blob) and replace with bzip2 decompression. Updates are usually deltas, so only changed blocks are downloaded. Because they are applied in place, a device that is still running version N when N+2 ships can apply N+1 to N+2 on top of an already installed N+1 without rebooting in between. The design requires that the end result be bit for bit identical to the server's image, because the root file system's block hashes are signed.

The design document also covers transport. Updates are downloaded over HTTPS, and the client requires a server certificate from the one certification authority that issues the OS provider's update server certificate. Payloads are hashed and checksummed, so a corrupted download is caught before it is applied.

What happens on failure

Each kernel partition's GPT entry carries three attribute fields that the firmware reads at boot:

The disk format reference defines four states. The active kernel has priority A, zero tries and the successful flag set. A backup kernel has a lower priority and has also booted successfully before. A newly updated kernel has a higher priority than the active one, some tries remaining and no successful flag, so the firmware attempts it on the next boot. A not bootable kernel has priority 0, either because it is mid-update, ran out of tries or failed its signature check.

The autoupdate design defines success as the update process launching. A freshly updated partition gets a fixed number of attempts (the original design used 6); the firmware decrements the count on each try. If the new slot never reaches a successful boot, its tries run out and the firmware goes back to the other slot, which still holds the previous working version. The design also promises that the system "never requires more than one reboot for an update". The practical result is the behavior Chromebook users see: updates download in the background, a restart prompt appears, and a bad update usually means one extra reboot back to the old version rather than a dead machine.

Admins have a separate, deliberate rollback path for managed devices, described in Google's "Roll back ChromeOS to a previous version" admin guide. Google's Flex documentation says that rollback is currently not supported on ChromeOS Flex and recommends the LTS channel there instead.

Auto update expiration: what it is and how to find yours

The policy

Google's Auto Update policy page now opens with a short statement: "ChromeOS devices receive 10 years of updates." The clock starts at the platform release date, not the purchase date. Google defines a platform as "a series of components that are designed to work together", which a manufacturer selects for a device, and says that "every 2 weeks" it works with the component makers in each platform to develop and test software for every ChromeOS device. That dependence on component suppliers is the reason the date is per platform.

The page also states what ends. After a device's final automatic update, "existing and future policies may not work as intended, and technical support will not be provided", and the device stops receiving ChromeOS and browser security fixes. Google's Chromebook help page on the update schedule adds that support for some apps that need newer ChromeOS or browser versions may stop. Verified boot keeps working, so a device past its date still checks itself at startup, but it checks against an image that no longer receives fixes.

How it went from short dates to ten years

On 14 September 2023, Google announced on its Keyword blog that "all Chromebook platforms will get regular automatic updates for 10 years". The rules had two parts:

• Starting in 2024, Chromebooks released from 2021 onward get 10 years automatically.
• For Chromebooks released before 2021 and still in use, users and IT admins can opt in to extend updates to 10 years from the platform release, after the device receives its last regular update. Google warns that some features and services may not be supported on those extended devices.

The policy table shows the effect on Google's own hardware:

Devices in the current table from 2023 to 2025 platforms commonly show dates from June 2032 to June 2035, with at least one January 2036 entry. Many dates fall in June because they track the platform, not the individual model.

A worked example

Suppose a school buys 400 identical Chromebooks in September 2026, and the table lists the model's platform date as June 2033. That fleet has about six years and nine months of updates left, not ten. If the same model had been bought in its launch year, it would have had close to ten. Google's help page makes the point directly: "The 'End of Sale' date is controlled by the device manufacturer and isn't related to a device's eligibility for Google updates." The procurement lesson is simple: compare the update date of each candidate model, not the price alone, and write the date into the asset record when the devices arrive.

Finding the date on one device and across a fleet

On a single device, Google's help page gives the path: select the time, then Settings, About ChromeOS, Additional details, and look at the "Update schedule" section. A device that has reached its end shows a "Final software update" notification. For a fleet, the 2023 announcement says extended update information is shown in the Help Center, the Admin console and Settings, and the Auto Update policy page publishes the date for each approved model once the platform has been released.

What changes with ChromeOS Flex

ChromeOS Flex is ChromeOS for existing Windows, Mac and Linux computers. Google's own comparison page lists the differences, and the security ones are significant.

The certified models list is the Flex equivalent of the update expiration table. Each row gives a model, a status (Certified, Minor issues expected, Major issues expected or Decertified), the ChromeOS version from which it was certified and an end of support year. Google's note says support "ends on the 31st December of the given year". In the list we fetched on 23 October 2026, about 780 rows across many tables included roughly 670 certified models and 47 decertified ones, with end of support years from 2025 to 2033. Many models list ChromeOS 103 as the version they were certified from, which fits the Flex general availability announcement in July 2022.

The practical reading: Flex gives retired hardware a maintained, managed operating system, but its boot integrity is only as good as the PC's Secure Boot setup and its firmware only as current as the PC maker keeps it. Give Flex firmware its own update owner.

What ChromeOS is built from, and how fixes ship

The open source layers

ChromeOS is the product built from the Chromium OS open source project, which Google released in November 2009. The main layers are:

• Firmware. Chromebook firmware is built on coreboot with Google's vboot library. The coreboot documentation describes vboot as verifying firmware and placing measurements in the TPM, with the read-only part of the SPI flash as the root of trust.
• Linux kernel. The Chromium OS kernel design document says the project ran a 2.6.32 Ubuntu based kernel for its first releases, then moved to "track the upstream mainline kernel directly". All platforms build from one kernel source tree, and backports carry tags such as UPSTREAM so reviewers can see where each change came from.
• Build system. Chromium OS is built with Gentoo's Portage tooling inside an SDK chroot. The developer guide walks through repo init against the Chromium OS manifest, entering the SDK with cros_sdk, then building packages and an image for a specific board. Source tarballs land in Portage distfiles before they are built.
• Chrome browser. The same Chromium codebase as Chrome on other platforms, bundled into each OS image.
• Android and Linux guests. Android apps run in a container or virtual machine based runtime, and the Linux development environment is a Debian container. Google's help page notes that all Linux apps share one sandbox, so "a harmful Linux app can affect other Linux apps, but not the rest of your Chromebook".
• The Android stack. Google's June 2024 announcement says ChromeOS will move onto large portions of the Android stack, "like the Android Linux kernel and Android frameworks", with Bluetooth already unified as of ChromeOS 122. Google said consumers would not see this "for quite some time".

How fixes reach devices

ChromeOS Stable and LTS posts on Chrome Releases are the security bulletin. Each Stable post has three sections: ChromeOS Vulnerability Rewards Program reported fixes, "Other 3rd Party Security Fixes Included", and the Chrome browser security fixes with their CVE identifiers, plus a pointer to Android security fixes. In autumn 2026, the third party sections listed fixes in GPU kernel drivers, the Android runtime's virtual machine plumbing, KVM, the printing service and the Linux kernel itself. LTS posts list "selected security fixes" backported to the long term branch.

That structure is the answer to "how are open source fixes shipped". Google does not ask users to update the kernel, the print server or the GPU driver separately. It rebuilds the whole signed image with the fixed upstream components and delivers it as a single A/B update. The cost of that model is the one this post keeps coming back to: once a device passes its update expiration date, every one of those components stops moving.

Step by step: check version, channel, write protect status and update expiration

The first four steps work on any Chromebook in normal mode. Steps 5 to 7 need developer mode, which turns off part of verified boot and should only be used on a device you own and can afford to wipe.

Step 1: read the version

Select the time at the bottom right, then Settings, then About ChromeOS. The version shown (for example 156.0.8078.42) is the browser milestone build. For the platform version, open a browser tab and enter:

chrome://version

The page lists the Google Chrome version and the platform version. Compare the platform version with the latest Chrome Releases post for your channel.

Step 2: read the channel

On the About ChromeOS page, select Additional details. The "Channel" line shows Stable, Beta, Dev, Canary, or for managed devices a long term support channel. Google's help page notes that on a non-stable channel the channel label also appears next to the clock and in Quick Settings.

Step 3: read the update expiration date

On the same Additional details page, find the "Update schedule" section. Write the month and year into your asset record. Check the model in the Auto Update policy table too, because the table is what Google commits to publicly.

Step 4: check for and apply updates

On About ChromeOS, select Check for updates. If an update has already been staged in the inactive slot, you will be asked to restart. One restart switches slots.

Step 5: open a shell (developer mode only)

Warning. Entering developer mode is a firmware level change. It disables the signature requirement for the kernel and root file system and shows a warning screen at every boot. Do not use it on managed or shared devices. Never run commands that write to disks or firmware unless you have confirmed the device path and have a recovery image ready.

In developer mode you get a root capable shell on the device. First, read the OS release file, a standard Chromium OS file:

cat /etc/lsb-release

Look for the release version and the release track (the channel) lines.

Step 6: check firmware write protect status (read-only commands)

Hardware write protect, as shown in the ChromeOS write protection reference:

crossystem | grep wpsw
# wpsw_cur = 1 means hardware write protect is enabled

Software write protect and the protected range on the main (AP) firmware, run as root:

futility flash --wp-status

On devices with a Google security chip, the reference uses gsctool to read the security chip's view of write protection:

gsctool -a --wp
# look for the "Flash WP" line

These three commands only read state. The same reference documents commands that disable write protection; do not run them unless you intend to replace the firmware, and only after reading the full reference for your device.

Step 7: see which A/B slot you booted (read-only)

These use rootdev and cgpt, standard Chromium OS tools (cgpt ships with Google's vboot tooling). First confirm the device path. Do not guess it:

rootdev -s
# prints the root device, for example /dev/mmcblk0p3 or /dev/nvme0n1p3

Then print the partition table of the parent disk, read-only, replacing the device with what rootdev -s showed minus the partition suffix:

sudo cgpt show /dev/nvme0n1

Compare the priority, tries and successful fields on partitions 2 and 4 with the state table above. The partition with the highest priority and the successful flag set is your active kernel. Do not use cgpt add or any command that changes attributes; a mistake there can leave the device needing recovery media.

Step 8: record it across a fleet

For managed fleets, use the Admin console and the Auto Update policy table rather than per device checks. Record model, platform version, channel, update expiration month and, for Flex, firmware version and Secure Boot state, and "which devices are past support" becomes a one minute query.

Common mistakes

• Reading the purchase date as the support start. Update expiration follows the platform. A device bought in its platform's sixth year has about four years left.
• Treating "End of Sale" as end of support. Google says the manufacturer's End of Sale date is unrelated to update eligibility.
• Pinning a device to an old milestone and forgetting it. A pinned device does not get Stable security updates. The LTS guide's own example shows a device stranded on 139 until 144 arrives.
• Assuming LTS is as patched as Stable. Google says some fixes may never be possible on LTS and others can take up to nine months.
• Switching an unmanaged device to a more stable channel without a backup. The help page says this powerwashes the device.
• Assuming Flex has Chromebook boot security. It does not. Turn on UEFI Secure Boot, set a firmware admin password, disable external boot and give someone ownership of the PC maker's firmware updates.
• Disabling write protect to "try something" and leaving it off. With write protect off, the read-only root key is no longer protected from software.
• Ignoring the Linux container. The Debian environment is isolated from ChromeOS, but packages inside it are your responsibility and follow Debian's updates, not ChromeOS's.

FAQ

What is the latest version of ChromeOS?

As of 23 October 2026, ChromeOS Stable is M156, platform version 16836.19.0 with browser 156.0.8078.42, released on 20 October 2026. Beta and Dev are on M157 (16852.x). The LTS channel is LTS-150, platform 16700.66.0. Check Chrome Releases for anything newer.

How often does ChromeOS update?

Google's help page says the Stable channel gets minor changes roughly every 2 to 3 weeks and major changes every 4 weeks. LTS gets a new feature version every 6 months and security fixes every 2 weeks.

How long do Chromebooks get updates?

Ten years from the platform's release date for platforms released from 2021 onward. Older platforms still in use could opt in to extended updates to reach ten years, with some features possibly unsupported. Check the Auto Update policy table for your model.

How do I find my Chromebook's auto update expiration date?

Settings, About ChromeOS, Additional details, Update schedule. The Auto Update policy page also lists the date for each approved model.

What happens when a Chromebook reaches its auto update expiration?

It stops getting ChromeOS and browser security updates, bug fixes and features. Admin policies may not work as intended and Google stops technical support. Verified boot still runs at startup.

What is the difference between ChromeOS LTS and LTC?

LTC is the candidate: it gets the next long term feature set three months before LTS does. LTS is the six month train that most long term fleets sit on. Both get security fixes every two weeks, chosen and backported by Google.

Does ChromeOS Flex have verified boot?

No. Google says the ChromeOS verified boot procedure is not available on Flex because PCs and Macs do not have a Google security chip. Google recommends turning on UEFI Secure Boot, which the Flex bootloader supports.

Is ChromeOS based on Linux?

Yes. ChromeOS uses a Linux kernel that tracks upstream mainline, is built with Gentoo's Portage tooling from the Chromium OS project, and Google announced in 2024 that it will move onto large parts of the Android stack, including the Android Linux kernel.

How do I check if Chromebook firmware write protect is enabled?

In developer mode, crossystem | grep wpsw shows wpsw_cur = 1 when hardware write protect is on. The futility and gsctool status commands in Step 6 above show software write protect, the protected range and the security chip's view. All three only read state.

Why did my Chromebook go back to an older version after an update?

The new slot did not complete a successful boot within its allowed tries, so the firmware fell back to the other A/B slot, which still held the previous working image. The device will try again with a later update.

Why software supply chain hygiene still matters here

ChromeOS shows a vendor owning its open source supply chain end to end: Google rebuilds the kernel, firmware, printing, graphics and browser components into one signed image that you cannot patch yourself. The web apps, Android apps, extensions and Linux development environment projects your team builds on or for Chromebooks are different, because their npm, PyPI, Maven and container dependencies are yours to track and fix.

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

To be plain about the fit: Safeguard does not manage Chromebooks, read a device's update expiration date, check firmware write protection or scan ChromeOS images. Google ships those fixes, and the steps above are how you confirm they arrived. What Safeguard covers is the code your team builds, including on a Chromebook.

The first 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 web app or extension project a developer keeps in the Linux development environment, where npm and pip pull dependencies exactly as they do on any other Linux machine.

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

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. That is the route for scanning a repository on the workstation where it is built, so the dependency picture comes from the same machine that produces the release.

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 lets you choose which tools Claude can use. For a team that already works in Claude, it is a way to ask about vulnerable components in your own projects without leaving that workflow, with the tool permissions set by you.

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

• Chromium OS design docs: Verified Boot
• Chromium OS design docs: Firmware Boot and Recovery
• Chromium OS design docs: Verified Boot Data Structures
• Chromium OS design docs: File System/Autoupdate
• Chromium OS design docs: Autoupdate Details
• Chromium OS developer library: Disk Format
• Chromium OS developer library: Write Protection
• Chromium OS developer library: Developer Guide
• Chromium OS design docs: Kernel Design
• Chromium OS design docs: Security Overview
• Chrome Enterprise and Education Help: Auto Update policy
• Chrome Enterprise and Education Help: Long-term Support (LTS) on ChromeOS
• Chromebook Help: Switch between stable, beta and dev software
• Chromebook Help: Check your Chromebook's update schedule
• Chromebook Help: Set up Linux on your Chromebook
• ChromeOS Flex Help: Differences between ChromeOS Flex and ChromeOS
• ChromeOS Flex Help: Certified models list
• Chrome Releases: Stable Channel Update for ChromeOS, M156 (20 October 2026)
• Chrome Releases: Stable Channel Update for ChromeOS, M154 (9 October 2026)
• Chrome Releases: Stable Channel Update for ChromeOS, M152 (8 September 2026)
• Chrome Releases: LTS channel major update from 144 to 150 (6 October 2026)
• Chrome Releases: ChromeOS label feed
• Chromium Dash: release schedule
• Chromium blog: Changes to Chrome OS's release cycle (11 June 2021)
• Chromium blog: Speeding up Chrome's release cycle (4 March 2021)
• Chromium blog: Chrome and Chrome OS release updates (26 March 2020)
• Chromium blog: Building a faster, smarter Chromebook experience (12 June 2024)
• Official Google Blog: Introducing the Google Chrome OS (7 July 2009)
• Official Google Blog: Releasing the Chromium OS open source project (19 November 2009)
• Official Google Blog: An update on Chrome, the Web Store and Chrome OS (7 December 2010)
• Google Chrome blog: The Google Play store, coming to a Chromebook near you (19 May 2016)
• Google Cloud blog: Early access to Chrome OS Flex (15 February 2022)
• Google Cloud blog: ChromeOS Flex is now ready to scale (14 July 2022)
• Google Keyword blog: Chromebooks will get 10 years of automatic updates (14 September 2023)
• coreboot documentation: vboot, Verified Boot Support
• Linux kernel documentation: dm-verity
• NIST SP 800-147: BIOS Protection Guidelines
• NIST SP 800-193: Platform Firmware Resiliency Guidelines

Last reviewed: 23 October 2026. ChromeOS release dates and channel versions change every few weeks; check Chrome Releases and Google's Auto Update policy page for the latest.