Answers for district IT
How should districts plan around ChromeOS auto-update expiration (AUE)?
Auto-update expiration is the date Google stops shipping ChromeOS updates and security patches to a device platform. It is not a device failure and nothing stops working the morning after, but it is a hard security boundary, and for most districts it is the single largest driver of the replacement budget. The planning problem is that AUE is set by the platform, not by your purchase date, so the useful life you actually get depends on how old the model already was when you bought it. Districts that track AUE at the asset level can turn a replacement cliff into a schedule; districts that track it on a spreadsheet of purchase orders find out in June.
How AUE dates are actually assigned
The AUE date attaches to the hardware platform — the board a manufacturer built the device on — not to the individual unit and not to your purchase order. Google publishes a support policy giving ChromeOS devices ten years of automatic updates measured from the platform's release date, with that ten-year window applying automatically to devices released from 2021 onward and available as an admin opt-in extension for older devices still in service.
The consequence that surprises people is that two devices bought on the same day can expire on different dates, and a device bought new can have considerably less than ten years left. If a manufacturer is still selling a platform that was released three years ago — which is normal, especially through refurbishers and closeout channels — you are buying seven years of updates at full price. The date is public before you buy, which makes it a legitimate bid evaluation criterion rather than a surprise.
This is why the purchase order is the wrong place to store the date. Your record needs the platform's AUE on each asset, populated at receipt, because the model mix inside a single PO is frequently not uniform. Districts that buy through state contracts or take donated and grant-funded devices see this constantly.
One more wrinkle worth knowing: the extension to ten years for pre-2021 devices is an option an administrator enables, not something that happens silently. If your fleet includes older units you intend to keep, confirm the extension is actually in effect for them rather than assuming the published policy applies.
Building the AUE inventory, and keeping it current
The practical first step is boring and unavoidable: get an accurate count of devices by model, with the AUE date for each model, and the building each device sits in. Most districts can pull the model and serial from the Google Admin console, which knows every enrolled device, and the AUE date from Google's published model list. Joining those two gives you a device-level expiration.
Assign the date to the asset record rather than recomputing the join each time. A date that lives on the device travels with it — through a repair, a building transfer, a reassignment to a different student — and shows up at the moment someone is making a decision about that specific machine. A join you re-run quarterly does not.
Keep it current by populating AUE at intake. When a new model enters the fleet, its expiration should be recorded once, at the point the model is first received, and inherited by every unit of that model afterward. This is a small amount of work done once instead of a large amount of work done annually under pressure.
The output you want from this inventory is a runway: how many devices fall out of update coverage in each quarter or school year going forward, broken out by building. That single view converts an abstract worry into a fundable number, and it is the artifact your business office and your board actually need.
Smoothing the cliff instead of riding it
The failure mode is buying a large 1:1 fleet in one grant-funded year, which produces a fleet that expires in one year. ESSER-era purchasing did this to a very large number of districts at once. The fix is not clever — it is deliberately staggering replacement so that a roughly constant fraction of the fleet is replaced annually, which turns an unfundable spike into a recurring line item.
Getting from a spiky fleet to a smooth one takes a few years of intentional over- and under-buying. If your expiring cohort is far larger than your sustainable annual replacement volume, you replace part of it early and part of it late, accepting that some devices run a little past their ideal life and some are retired a little before. The devices you replace early should be the ones with the worst repair history; the ones you hold should be the healthiest units in the least demanding roles.
Grade-band assignment is the most useful lever here. A device with two years of updates left is fine in a cart used for testing and occasional research in an elementary building; it is a poor choice for a high school student who takes it home daily. Retiring a cohort out of 1:1 and into shared carts buys you real time without extending a device past its expiration.
When you build the schedule, plan on the replacement being triggered by the AUE date rather than by an age-in-years rule. Age rules and AUE dates diverge exactly when it matters, because a device bought mid-platform-life is older than its receipt date suggests.
What actually happens after AUE, and what your policy should say
A post-AUE Chromebook keeps working. It boots, it signs in, it runs the apps it ran yesterday. What it stops receiving is security patches and new browser versions, and over time that produces two compounding problems: unpatched vulnerabilities in a browser that is the entire attack surface of the device, and web applications that begin requiring a Chrome version the device can no longer reach. The second one is what parents and teachers notice — a state testing platform or a courseware vendor announces a minimum browser version and a block of your fleet is suddenly out.
Write the policy before you are under pressure. Most districts land on some version of: devices past AUE are not issued to students for take-home use, are not permitted on the network segment that reaches student data, and are removed from the testing device pool. Whether they remain usable for anything at all is a local risk decision, and it should be made by someone with the authority to own it rather than by the technician holding the cart.
Be explicit about the compliance angle. Districts operating under state student data privacy law, or under an insurance policy or cyber-liability requirement, frequently have language about maintaining supported and patched systems. An unpatched fleet segment is a finding waiting to happen, and "the devices still turn on" is not a defense.
Communicate the schedule to principals a year ahead, not a month ahead. Building leaders plan instructional models around device availability, and the difference between a year of notice and a summer of notice is the difference between a plan and a crisis.
Disposition: harvesting, ChromeOS Flex, and honest disposal
Retired devices have three plausible destinations, and the right split depends on your repair operation. Units with intact screens, keyboards, batteries, and charging ports are worth stripping for parts if you self-repair the models still in service — a harvested screen that enters stock at zero cost makes your effective repair costs genuinely better, and it is the highest-value outcome for a machine you cannot keep in production.
ChromeOS Flex is a real option for some hardware, but it is worth being precise about what it does and does not solve. Flex is Google's ChromeOS build for PCs and Macs, and installing it on hardware is a way to give aging non-Chromebook devices a supported browser-based life; it is not a mechanism for extending updates on an expired Chromebook, which is generally locked down. If you are looking at Flex, look at it for your old Windows laptops, not for your expired Chromebooks.
Resale and buyback through refurbishers recovers some value, and residual value is highest before AUE rather than after, which is an argument for replacing on a schedule instead of running devices to the absolute end. Get the numbers before you decide — for low-end models the recovery is often small enough that harvesting parts is worth more.
Whatever the destination, the disposition needs to land back in the asset record. Deprovision the device from the Google Admin console, record the outcome and date, and keep the record rather than deleting it. Districts using federal or grant funds usually have a disposal documentation requirement, and an asset that simply disappears from the inventory looks identical to an asset that was lost.
Common questions
What is ChromeOS auto-update expiration?
AUE is the date Google stops delivering ChromeOS updates and security patches to a device platform. The device keeps working, but it no longer receives security fixes or new browser versions, which eventually causes both security exposure and compatibility failures with web applications that require a newer Chrome.
How long do Chromebooks receive updates?
Google's policy provides ten years of automatic updates from the platform's release date. That applies automatically to devices released from 2021 onward; for older devices still in service, administrators have an opt-in option to extend updates to ten years from platform release. Because the clock starts at platform release rather than at purchase, a newly bought device can have well under ten years remaining.
Can we keep using Chromebooks after their AUE date?
Technically yes — they boot and run. Most districts nonetheless stop issuing post-AUE devices for take-home 1:1 use, remove them from testing pools, and keep them off network segments that reach student data, because an unpatched browser is the device's entire attack surface. Check your state privacy law and cyber-liability coverage for language about supported systems before deciding.
How do we find the AUE date for our Chromebooks?
Pull model and serial for every enrolled device from the Google Admin console, then join that against Google's published AUE list by model. Store the resulting date on each asset record rather than re-running the join, so the date travels with the device through repairs, transfers, and reassignment.
How do we avoid replacing the whole fleet in one year?
Stagger deliberately: replace a roughly constant fraction of the fleet each year, and get there by retiring your worst-repair-history devices early and holding the healthiest ones a little longer. Moving an expiring cohort out of take-home 1:1 and into shared carts in lower grade bands buys time without running devices past expiration.
Does ChromeOS Flex extend a Chromebook's update life?
Generally no. Flex is intended for PC and Mac hardware, giving aging non-Chromebook devices a supported browser-based life; Chromebooks themselves are typically locked down against it. Consider Flex for your old Windows laptops, and plan Chromebook replacement around AUE.
Should AUE affect purchasing decisions?
Yes, and it is a legitimate bid criterion because the date is public before you buy. Two devices at the same price can carry very different remaining update life if one is built on a platform released three years earlier. Evaluate cost per year of supported life rather than unit price.
How Chalk approaches this
Chalk keeps AUE on the device record alongside warranty and repair history, and reports an AUE runway showing how many devices fall out of coverage by quarter and by building — the view that turns replacement into a fundable schedule. Because ChromeOS devices are ingested from the Google Admin SDK and matched to assets by serial, the dates populate from the fleet you actually have rather than from a spreadsheet. Repair decisions surface the same date, so a device a few months from expiration does not quietly get a new screen.