On 23 September Google published a support page for IT administrators titled “What the Googlebook announcement means for your ChromeOS devices”. It contains one sentence that quietly reprices every Chromebook fleet in every school and office: “ChromeOS devices will continue to receive regular updates and security patches through mid-2034.” Google’s Auto Update policy page, unchanged, promises something else: ten years of updates “from the platform release date”. We pulled that page on 29 September and counted what it still promises. For 97 device models, the two pages give different answers.
TL;DR
- Google’s Googlebook FAQ (last updated 23 September 2026) caps ChromeOS updates at “mid-2034”. The Auto Update policy page still promises “10 years from the platform release date”.
- We parsed all 816 models Google lists, across 71 manufacturers. 97 carry a published update date later than mid-2034: 59 at June 2035, 28 at June 2036, 10 at January 2036. A further 14 sit exactly on June 2034.
- 129 models (15.8%) are already past their date. 63 more expire within twelve months, and 58 of those fall in a single month: June 2027.
- An expiry date is a browser version. A Chromebook whose last update landed in August 2023 is frozen on Chrome 116, which cannot run 85 of the 771 Baseline features in the web-features dataset, 17 of them Baseline Widely available.
The same page says both
Google’s summary of priorities on the new page says the Chromebooks you own “will continue to receive updates through their supported lifetime”, as set out in the Auto Update policy. Four paragraphs later, answering a question about hardware purchasing and refresh plans, the same page says updates run “through mid-2034”, and adds this: “For qualifying devices purchased today whose 10-year support lifecycle extends beyond 2034, Google is committed to supporting your transition to Googlebook OS, with many devices offering direct migration paths.”
It concedes that some devices have a documented support lifecycle running past 2034, and it offers a different operating system rather than the updates. The remedy for a shortened support promise is a migration, and on the same page: “Details on migration paths and device eligibility will be shared at a later date.”
The reporting on this has settled on “eight years, not ten”, which is what you get if you buy today. That framing understates it, because Google’s clock never started at purchase. It starts at platform release, which is why a Chromebook bought in 2026 can carry a 2031 date on a shelf edge. The devices actually squeezed by mid-2034 are the ones already sold.
Counting the gap
Google’s Auto Update policy page lists every approved ChromeOS device with the month its updates stop. We parsed all of it: 816 models across 71 manufacturers.
Ninety-seven models are published with a date after mid-2034. Asus accounts for 33 of them, Lenovo 17, Acer 16, HP 11, Dell 7. These are not exotic units; they are current commercial and education stock, and they are the exact population the FAQ acknowledges and then hands to a migration path that has no date, no eligibility list and no price.
The near end of the list is the more urgent half. 129 models, 15.8% of everything Google lists, have already stopped receiving updates. Then there is a three-year hole: no model on the page expires in 2024 or 2025, and exactly one in 2026. Then a cliff. Fifty-eight models reach their final update in June 2027, five more in August 2027. If your organisation buys Chromebooks on a rolling refresh, your risk is not spread across quarters. It is concentrated in one month, twenty-one months out. Separately, 82 of the 816 are marked as needing an explicit opt-in to receive extended updates at all, which means somebody has to go and click something before the promise applies.
An expiry date is a browser version
When a ChromeOS device reaches Auto Update Expiration it does not stop working. It stops moving. It keeps the last build it received, which means it keeps the Chrome milestone that was stable on that date, permanently. Every one of those devices continues to load your site, and it continues to report a Chrome user agent that looks entirely normal in analytics.
So Google’s hardware calendar is an input into your browser support matrix, and almost nobody treats it as one. “Evergreen browser” is an assumption with an expiry date attached, published by a third party, on a page your team has never read.
What Chrome 116 cannot render
Take the most recent real cohort. The last models to expire without an extended-updates opt-in did so in August 2023. Chrome 116 reached stable on 15 August 2023 (confirmed against the stable_date field on Chromium Dash, not the later late_stable_date). Those devices are on 116 and will be forever. Chrome 154 shipped on 22 September 2026, and 156 is due on 20 October.
We took the web-features dataset, which is the data behind Baseline, and counted the features a frozen Chrome 116 cannot run. Of the 771 Baseline features carrying a Chrome version, 85 (11.0%) require a milestone newer than 116. Seventeen of those 85 are not merely Baseline Newly available; they are Baseline Widely available, the status teams use as their green light to delete fallbacks:
- CSS Nesting, Subgrid, Masks and the
capunit :user-validand:user-invalid,:dir(),paint-order, clip-path boxes,rect()andxywh()Promise.withResolvers(),Array.fromAsync(), array grouping,URL.canParse()- The Storage Access API and the
scriptingmedia query
Ship a layout on Subgrid with no fallback, which Baseline currently tells you is safe, and it does not degrade on those machines. It collapses. The same goes for a form that signals validation state through :user-invalid: the user sees nothing, fills the field wrong, and calls you.
It gets worse the further back you go. A device frozen in June 2021 sits on Chrome 91 and misses 175 Baseline features, 22.7% of the set.
The licence does not travel
The commercial detail is buried in the FAQ’s answer about upgrade licences. Your existing Chrome Enterprise Upgrade and Chrome Education Upgrade licences stay valid for managing Chromebooks. But: “When you purchase new Googlebooks, or choose to migrate eligible Chromebooks to Googlebook OS, management will operate under a new licensing structure.”
A migration that requires re-licensing is not a migration, it is a repurchase with a discount attached. And the management layer that would justify it is not ready: Google says a comprehensive management experience for Googlebooks “will start rolling out in the second half of 2027”, and the 2026 launch “does not yet support domain enrollment or centralized fleet management”. So the guidance for a fleet buyer today is to keep buying a platform with a shortened clock, and wait for management tooling that arrives after more than a fifth of the current fleet has already gone dark. We have written before about maintenance agreements being the line nobody budgets for. This is the same failure at platform scale.
What to do before your next refresh
- Get the real dates for your own models. Not the warranty, not the lease term. The Auto Update Expiration month from Google’s policy page, per model, in a spreadsheet, today.
- Check whether you are in the June 2027 cohort. Fifty-eight models land in that one month. If any are yours, the budget conversation starts now, not in 2027.
- Put a browser floor in your support matrix. Take your oldest expired cohort, resolve it to a Chrome milestone, and make that milestone an explicit target rather than a discovery. Analytics will not tell you, because a frozen Chrome looks like a supported one.
- Audit against Baseline, not vibes. The
web-featuresdata is free and machine-readable. Run your dependency and CSS surface against it and produce the list of features your floor cannot reach. - Price the licence, not the laptop. Any Googlebook OS plan should carry a line for new management licences, because the old ones do not transfer.
Our view
Google has not broken a promise so much as published two of them and left customers to work out which one is load-bearing. That is a reasonable thing to be annoyed about, and a bad thing to plan around. The defensible move is to stop treating a vendor’s support calendar as background and start treating it as a dependency with a version number, because that is exactly what it is. At REPTILEHAUS we build browser support floors from measured data rather than assumptions, and we audit front ends against Baseline instead of guessing. If your support matrix is a paragraph in an old proposal, get in touch and we will replace it with something you can test.
Figures verified on 29 September 2026 against Google’s Auto Update policy page, Google’s Googlebook support article, Chromium Dash and the web-features dataset. Model counts and milestone numbers will move; re-run them before quoting.
📷 Photo by John Cardamone on Unsplash
