What Is ChromeOS Auto Update Expiration (AUE)?

Google states that ChromeOS improvements provide enhanced security and stability for ten years from the platform release date. A platform, in Google's usage, is the set of hardware components — processor, wireless chipset and so on — that a manufacturer selects for a device. Several different retail models from several different manufacturers can share one platform, which is why two Chromebooks with different names and different chassis can share an identical expiration date.

Because the clock starts when the platform is released, the remaining life of a device is the ten-year window minus however long that platform has already existed. A device built on a platform released four years ago arrives with roughly six years of automatic updates remaining, however new the individual unit is. Buying that device new in its fourth or fifth year is not a mistake in itself — closeout stock at the right price can be entirely rational for a two-year stopgap — but it is only rational if the shortened window is the reason for the discount rather than a surprise discovered afterwards.

This is also why refurbished and donated Chromebooks need the same check as new ones. A device with years of physical life left can have very little supported life left, and the two are unrelated. The expiration date belongs on the receiving checklist for any ChromeOS hardware entering a district, regardless of how it arrived.

Google extended the update window to a full ten years from platform release, and the way that extension reaches devices differs by age. Google's documentation states that all ChromeOS devices released in 2021 or later automatically receive extended updates. For those devices there is nothing to enable and nothing to decide: the ten-year window applies by default.

For a subset of older hardware, an administrator has to opt in. Google marks the devices that require opt-in with an asterisk in its published Auto Update policy tables, and the opt-in is made through an Admin console policy named Extended Auto-update, found under Devices, then Chrome, then Settings, then Device settings, then Device update settings. Without that action, an eligible pre-2021 device stops at its original expiration date even though extended updates exist for it.

For a district running a mixed-age fleet, this is a real and easily missed piece of work. Devices bought in different years sit in different categories, the tables are published per manufacturer and model, and nothing prompts an administrator to act. Auditing which enrolled platforms carry the asterisk — and therefore need the policy turned on — is a one-off task that can add years of supported life to hardware already in service.

Opting a device into extended updates is not cost-free, and Google is direct about the consequence. Its documentation states that all Android related data is erased from the devices and cannot be recovered, and that the Google Play Store is removed from the devices, with Android apps no longer installable remotely by an administrator. That is why the extension requires an explicit opt-in rather than arriving automatically for those older devices.

Whether that is an acceptable trade depends entirely on how the device is used. A fleet whose curriculum runs in the browser — web-based learning platforms, a cloud productivity suite, a browser-delivered assessment tool — loses very little and gains years of security updates, which is a straightforward decision. A fleet that depends on specific Android applications for a subject area, an accessibility tool or an assessment client faces a genuine choice between those applications and continued update support.

Google's published guidance does not state whether the opt-in can subsequently be reversed, so the honest planning assumption is to treat it as a one-way decision until you have confirmed otherwise. Test it on a small group of devices in a non-critical organizational unit before applying it fleet-wide, and inventory the Android applications in active use first — the answer to whether the trade is acceptable is usually sitting in that inventory.

The device does not stop working. It boots, signs in, opens the browser and runs. Google notes that after final updates a device retains its secure mode with automatic self-checks at startup, so the verified-boot integrity check continues to operate. What ends is the flow of new fixes: no new security patches, no new features, and no assurance that newly discovered vulnerabilities will be addressed on that platform.

Two consequences matter more to an administrator than the security headline. Google states that existing and future policies may not work as intended on an expired device, which means the machine drifts out of your management model — a policy you set today may simply not apply to it. And Google states that technical support will not be provided, so a problem on that platform has no escalation path.

Web compatibility then erodes on its own schedule. As the browser stops advancing, sites and applications built against newer standards begin to behave oddly or refuse to load, and the failures are rarely clean — a testing platform that will not launch on the morning of an assessment is the classic version of this. That unpredictability, rather than any single dramatic breach, is what usually forces expired devices out of service.

Work the arithmetic before comparing prices. A device on a platform released this year arrives with roughly ten years of automatic updates ahead of it. A device on a platform released five years ago arrives with roughly five. If a district plans a five-year refresh cycle, the first device comfortably clears two cycles' worth of support while the second expires at the exact moment the cycle ends — assuming the platform release date and the purchase date happen to align, which they rarely do.

That is the honest case against buying the cheapest available Chromebook, and it occasionally costs us a sale. A discounted older-platform unit that has to be replaced in year three, in a program sized for a five-year cycle, is the more expensive purchase — not because the device fails, but because the replacement, the re-enrollment, the redeployment and the staff time all arrive early and unbudgeted. The purchase price is the smallest term in that expression.

The corollary is that the expiration date should appear on the quote, not just in the research. Ask for it alongside the specification of any ChromeOS device you are evaluating, and record it in the asset system at receipt. A district that knows the expiration date of every platform in its fleet can plan a refresh; one that does not is reacting to devices as they fall over.

On an individual device, Google's documented path is: at the bottom right, select the time and then Settings; at the bottom left, select About ChromeOS; select Additional details; in the Update schedule section you will find when the Chromebook will receive its last update. That is the quickest check for a single machine already in your hands, and it is worth teaching to whoever receives hardware.

For purchasing decisions, Google publishes its Auto Update policy as tables organized by manufacturer, listing the expiration date for each model and platform, with an asterisk marking the older devices that need an administrator to opt in to extended updates. Check the model on that table before an order is placed rather than after it lands, and be careful with model naming — manufacturers reuse family names across platforms, so match the exact model designation rather than the marketing name.

For a fleet, the Admin console device list is the practical instrument: it is where enrolled devices, their platforms and their management state come together, and it is the right place to build an audit of which enrolled platforms are approaching expiration or are carrying an asterisk. Running that audit once a year, ahead of budget season, is what turns AUE from a surprise into a line in a refresh plan.