On 26 August the California Senate passed Assembly Bill 1856 by 39 votes to nil, the Assembly concurred the following day, and the bill went to Governor Newsom. Almost all the coverage framed it as a win for Linux, which it is: Debian, Fedora, Ubuntu, Arch and the BSDs are now carved out of California’s Digital Age Assurance Act four months before it takes effect.
That framing buries the more useful story. AB 1856 is the clearest map anyone has published of where the platform age signal will exist, where it will not, and what your product must do in each case. If you build consumer software that reaches California, that map is a specification with a deadline of 1 January 2027.
TL;DR
- California’s Digital Age Assurance Act (AB 1043) becomes operative on 1 January 2027, moving age determination out of your signup form and into the operating system: OS providers collect a birth date at account setup and expose an age bracket over a real-time API.
- Developers must request that signal when an application is downloaded and launched, and must treat it as the primary indicator of a user’s age.
- Receiving a signal is deemed actual knowledge of that user’s age range across every platform and point of access your application has. Age state belongs to the account, not to the client.
- AB 1856 exempts open-source operating systems, package managers and browser-extension stores. Web applications were never in scope. Those gaps are where your fallback design lives, and they are not small.
- Civil penalties reach $2,500 per affected child for a negligent violation and $7,500 for an intentional one, enforced by the Attorney General. There is no private right of action.
What the law actually does
The act adds Title 1.81.9 to the California Civil Code and is refreshingly short. An operating system provider must present an interface at account setup requiring the account holder to give the birth date or age of the device’s user, and must expose a real-time API telling a requesting developer which of four brackets that user falls into: under 13, 13 to 15, 16 to 17, or 18 and over. That is the entire payload. The statute calls it “age bracket data”, explicitly non-personally identifiable, and requires that only the minimum necessary is sent.
Then the part aimed at you: a developer shall request a signal when the application is downloaded and launched, and shall treat it as the primary indicator of that user’s age range.
The dates carry a trap. Beyond the OS providers’ 1 July 2027 backfill for older devices, there is a separate developer deadline: if your application received an update on or after 1 January 2026 and was downloaded to a device before 2027 without a signal request, you must request one from the app store before 1 July 2027. In practice that is every actively maintained application, because you have almost certainly shipped an update this year.
The clause that will catch teams out
Section 1798.501(b)(2)(A) is forty words long and will reshape more architectures than anything else in the bill. A developer that receives a signal is deemed to have actual knowledge of the user’s age range across all platforms of the application and all points of access, even if the developer wilfully disregards the signal.
Read that as an engineer rather than a lawyer. If your iOS client requests a signal and gets back “under 13”, you now have actual knowledge of that user’s age range on your web app, on your Android build and at your API. Not the device. The user. Knowledge follows the account across every surface you operate.
Most teams will implement this the obvious way: a platform-specific call gating a few features in the mobile client. That is a compliance failure waiting to be found, because the obligation is account-wide and so is the enforcement. The correct shape is an age bracket attribute on the account record, written once from whichever surface obtains it first, read by every service making an age-dependent decision, with provenance recorded. Ordinary identity architecture, and much cheaper now than as a retrofit.
The exemptions are a coverage map
Here is where AB 1856 earns its attention. It redefines “operating system provider” to exclude anyone distributing software under licence terms permitting recipients to copy, redistribute and modify it. GPL, MIT, BSD and Apache all satisfy that test, removing the mainstream Linux distributions, the BSD family and GrapheneOS from scope entirely. A second carve-out excludes software not offered as a stand-alone executable through a covered application store, taking libraries shipped through apt and pacman out of the definition of an application. A third removes storefronts distributing extensions that run inside a host application, so browser extension stores are out. It also deletes the original definition of “user”, which classified every device owner in California as a child and so made it impossible for anyone to be flagged as an adult.
Now assemble those exclusions into a coverage statement. The signal exists on Windows, macOS, iOS and Android, for applications distributed through a covered app store. It does not exist on open-source operating systems. It does not exist for anything installed through a package manager. It does not exist for browser extensions. And it has never existed for the web, because a website is not distributed through an application store and a browser is not an operating system provider.
For most companies we work with, that last sentence is the whole engagement. The web product is the primary product, the signal will not be there, and the fallback is not a degraded mode to sketch in later. It is the main path.
The signal is not a data source
Once a trustworthy age attribute starts arriving from the operating system, the temptation is to route it into the warehouse with everything else. Resist it. Developers may not request more than the minimum necessary to comply, and may not share the signal with a third party for any purpose the title does not require. AB 1856 goes further and prohibits requesting a signal at all unless doing so is required by law, which shuts off the age API as a general-purpose demographic enrichment channel. The amendment also extends good-faith protection so platforms and developers are not liable for an erroneous signal, taking with one hand and giving with the other.
So: age bracket data should not reach your analytics pipeline, your advertising tags or your CDP, and it should not be persisted as a birth date. A bracket is what you were given and a bracket is all you may hold.
“Clear and convincing information” cuts both ways
The signal is the primary indicator of age, except where a developer holds clear and convincing internal information that contradicts it, in which case the internal information governs. The same section forbids wilfully disregarding such information, which turns data you already hold into a legal obligation. A self-declared date of birth, a school email domain, a parental consent record: any of these might qualify, and the moment one conflicts with the signal you are expected to notice and act. Teams that have quietly collected self-declared ages for years without reconciling them carry more exposure here than teams that collected nothing.
Europe is solving this differently
Utah and Texas have taken California’s route. The EU is heading towards credentials instead: DSA Article 28 guidance on protection of minors, the Commission’s age-verification blueprint, and the EUDI Wallet. Ireland’s Online Safety Code already imposes age assurance duties on video-sharing platforms under Coimisiún na Meán.
A platform signal and a verifiable credential are not the same primitive: one is a bracket pushed by the device vendor, the other a cryptographic proof presented by the user. Build directly against either and you will build twice. The durable design is a single internal age assurance abstraction, expressed in brackets rather than dates, with adapters underneath for each.
What to do before January
- Find every age-dependent decision in your codebase. Content gating, advertising, recommendations, messaging, retention, privacy defaults.
- Move age to the account. One attribute, one writer, many readers, with provenance and timestamp.
- Design the no-signal path first. Web, Linux, extensions and side-loads produce nothing, and it will still be most of your traffic.
- Audit where age could leak. Analytics, tag managers, session replay, advertising SDKs, support tooling. Add the bracket to your data map.
- Reconcile what you already hold. Decide in writing what counts as clear and convincing information, and what your systems do on conflict.
- Check the retroactive clause against your release history. Shipped an update after 1 January 2026? It applies to you.
None of this is exotic engineering. It is identity architecture, data lineage and fallback design, exactly the sort of unglamorous work deferred until a deadline makes it expensive. Sixteen months of notice was generous. Four is not.
At REPTILEHAUS we build identity, consent and compliance plumbing into products that work across web, mobile and API surfaces without duplicating the rules in each one. If you are working out what the age signal means for an application you already run, get in touch.
📷 Photo by Jin-Woo Lee (@shipduck) on Unsplash
