California is moving age checks from the website to the phone

The Digital Age Assurance Act takes effect on 1 January 2027. It makes the operating system the thing that knows how old you are, and gives apps a real-time interface to ask. AB 1856, which refines it, passed the legislature on 27 August 2026 and awaits the Governor.

The short version

• California's Digital Age Assurance Act is already law, chaptered on 13 October 2025 as Chapter 675, Statutes of 2025. Its duties begin on 1 January 2027.
• An operating system provider must present an interface at account setup asking the account holder for the birth date or age of the device's user.
• Apps get that answer as a bracket through "a reasonably consistent real-time application programming interface", not as a date of birth.
• There are four brackets: under 13, 13 to under 16, 16 to under 18, and 18 or over. The statute calls this "nonpersonally identifiable data".
• AB 1856 passed the Senate 39-0 on 26 August 2026 and the Assembly concurred 69-0 on 27 August. It is enrolled and not yet signed.

Checking every visitor at every site is expensive and collects a great deal of data

Ofcom's statutory report of 15 July 2026 counted 69 million age checks across 32 online services in six months, a 23-fold increase on the previous half year. That is the service-side model working: each site is responsible for establishing the age of each visitor, and the volume of checks scales with the number of services a person uses.

The model has a cost that grows with its success. Every check is a moment where a person hands a document or a face to a company they may have no other relationship with, and every service has to build or buy the capability. A teenager visiting ten regulated services performs ten checks with ten counterparties.

California has legislated a different answer. Rather than asking each service to establish age, it asks the device to hold the answer once and tell services what they need to know. The instrument is the Digital Age Assurance Act, enacted as AB 1043 and chaptered on 13 October 2025 as Chapter 675, Statutes of 2025, with duties beginning on 1 January 2027.

The bill refining it, AB 1856, cleared the legislature four days before this was written.

The operating system asks once and answers a bracket question through an API

From 1 January 2027 the Digital Age Assurance Act requires an operating system provider to present "an accessible interface at account setup". It must require an account holder "to indicate the birth date, age, or both, of the user of that device". The point of asking is to produce a signal about that user's age bracket for applications in a covered application store.

An account holder is defined as someone at least 18, or the parent or legal guardian of a user under 18. So the answer at setup comes from an adult, which is the mechanism's assumption about who configures a child's device.

What reaches an app is deliberately thin. A developer who requests it gets "a digital signal via a reasonably consistent real-time application programming interface regarding whether a user is in any of several age brackets". The statute defines age bracket data as "nonpersonally identifiable data derived from a user's birth date or age". It sets four brackets as a minimum: under 13; at least 13 and under 16; at least 16 and under 18; and at least 18.

Those boundaries are not arbitrary. Under 13 is the line American federal privacy law for children already runs on, and 16 and 18 are the thresholds most platform policies and state statutes use. An app receives a position on that ladder rather than a date of birth, which is the privacy argument for the whole design.

A covered application store is "a publicly available internet website, software application, online service, or platform that distributes and facilitates the download of applications from third-party developers". Stores distributing only extensions, plug-ins or add-ons that run inside a host application are excluded.

The service-side model

Each site checks each visitor

Who establishes age · the online service
What the user gives · a document, a face, or an estimate
Evidence strength · high, and auditable per check
Reach · only the services that implement it
Data collected · a new disclosure at every service
Seen in · the UK Online Safety Act regime

The device-side model

The phone answers for every app

Who establishes age · the account holder at setup
What the app gets · a bracket, described as nonpersonally identifiable
Evidence strength · an assertion passed on, not a verification
Reach · every app on the device, through one API
Data collected · one entry, reused
Seen in · California's Digital Age Assurance Act

AB 1856 widens who is covered and forbids asking without a reason

The California Senate passed AB 1856 on 26 August 2026 by 39 votes to nil, and the Assembly concurred in the Senate's amendments on 27 August by 69 to nil. The legislature's own history records the bill as engrossed and enrolled. No Governor action is recorded as of 31 August 2026, so it has passed but is not yet law.

Its most consequential change is a deletion. The Act had defined a "user" as a child who is the primary user of a device, which limited the whole apparatus to devices identifiably belonging to children. AB 1856 deletes that definition, and instead specifies that the interface duty applies where an operating system provider's system "operates on a device and has an account setup feature". The obligation attaches to the setup flow rather than to a judgement about whose device it is.

The bill also requires the signal to be provided "to a covered application store or application developer", naming both recipients rather than leaving the route implicit.

The third change is the one worth dwelling on, because it anticipates a problem the rest of the design creates. AB 1856 "would prohibit a person from requesting a signal with respect to a particular user from an operating system provider or a covered application store if not required to do so by the DAAA or any other applicable law".

Read plainly: you may not ask how old someone is simply because the interface makes it easy. A universal, real-time age API is useful to advertisers, analytics firms and anyone building a profile, none of whom the Act is written for. The prohibition confines the question to parties a law has actually obliged to ask it.

Reach and privacy go up, evidential strength goes down

California's design, operative from 1 January 2027, reaches every application on a device through one interface and moves far less personal data than a document check, because what travels is a bracket the statute calls nonpersonally identifiable. Those are real advantages, and they are the reason the model is attractive.

The cost sits in what the signal actually is. A bracket derived from what an account holder typed at setup is an assertion the operating system relays. Nothing in the mechanism tests whether the person now holding the device is the person described at setup, and a determined teenager configuring their own device supplies their own answer.

That is not a flaw so much as a different objective. A regime aimed at making the ordinary case work well, at scale, with minimal data, will not produce the same evidence as a regime aimed at proving a specific person's age to a regulator. The United Kingdom's approach, which we covered when Ofcom published its statutory report on age assurance, is built for the second and measures itself accordingly.

The two are not mutually exclusive, and the interesting question is what happens where they meet. A service operating in both jurisdictions could take the device signal as a first filter and verify properly only where the bracket is contested or the risk is high. Nothing in either regime forbids that, and it is the shape a sensible implementation is likely to take.

What a product team should not assume is that an age bracket satisfies an obligation written in terms of assurance. Where a law asks for confidence that a user is over a threshold, an assertion relayed by a phone is a starting point. The pressure on that distinction will only grow as the tools for defeating checks improve, which is the trend the Gambling Commission described when it found AI on both sides of the identity check.

Key takeaways

The Act is already law.

AB 1043 was chaptered on 13 October 2025 as Chapter 675, Statutes of 2025, and its duties begin on 1 January 2027.

The device answers, not the site.

An operating system provider collects a birth date or age at account setup and exposes an age bracket to apps through a real-time API.

Four brackets, described as nonpersonally identifiable.

Under 13, 13 to under 16, 16 to under 18, and 18 or over, as a statutory minimum.

AB 1856 has passed but is not signed.

Senate 39-0 on 26 August 2026, Assembly concurrence 69-0 on 27 August, then engrossing and enrolling. No Governor action recorded as of 31 August.

Asking without a legal reason is prohibited.

AB 1856 would bar requesting a signal about a particular user unless the Act or another law requires it.

Using Didit where a device signal is not enough

An age bracket from an operating system is an assertion. It reports what an account holder typed at device setup, and the statute itself calls it nonpersonally identifiable. That is enough to tailor an experience. It is not evidence that the person now holding the device is over a threshold, and a service under a legal duty to be confident still has to establish that itself.

That gap is the work. Age Estimation at $0.10 per check reads an approximate age from a selfie, which is the cheapest independent check when a signal is missing, when a device is shared, or when behaviour does not match the reported bracket. Where a law asks for assurance rather than an assertion, ID Verification at $0.15 per check establishes age from a document and Passive Liveness at $0.10 per check confirms a live person is presenting it. A service operating in both California and the United Kingdom can treat the device signal as a first filter and put a real check behind it. Current prices are on the pricing page.

Three limits. Didit is not an operating system provider and cannot emit a Digital Age Assurance Act signal, so that part of the mechanism comes from the platform. The Act is not yet operative and AB 1856 is unsigned, so nothing here is a compliance requirement today. And deciding when a bracket suffices is a legal judgement about the obligations your service is under, which sits with you and your counsel.

Frequently asked questions

What is California's Digital Age Assurance Act?

A law enacted as AB 1043, chaptered on 13 October 2025 as Chapter 675, Statutes of 2025. From 1 January 2027 it requires an operating system provider to present an interface at account setup asking an account holder to indicate the birth date or age of the device's user, and to provide a signal about that user's age bracket to applications available in a covered application store.

What age brackets does the signal use?

Four, at a minimum: whether a user is under 13; at least 13 and under 16; at least 16 and under 18; and at least 18. The statute defines age bracket data as "nonpersonally identifiable data derived from a user's birth date or age".

What did AB 1856 change on 27 August 2026?

It deletes the definition of "user" as a child who is the primary user of a device, specifies that the interface requirement applies where the operating system runs on a device and has an account setup feature, requires the signal to go to a covered application store or application developer, and prohibits requesting the signal for a particular user unless required to do so by the Act or another law.

Is AB 1856 law?

Not yet. The Senate passed it on 26 August 2026 by 39 votes to nil and the Assembly concurred in Senate amendments on 27 August by 69 to nil. The bill history records it as engrossed and enrolled, with no Governor action recorded as of 31 August 2026.

Does the age signal replace identity verification?

No. The signal reports a bracket derived from what an account holder entered at device setup, and the statute describes it as nonpersonally identifiable. It is a claim passed on by the operating system rather than a verified identity, so services that need assurance rather than an assertion will still verify separately.

Related reading

• AI is now on both sides of the gambling identity check — Why the gap between an assertion and a verification keeps widening.
• Europe's deepfake rule is now in force — Another regulator legislating at the platform rather than the service.

Sources

1. California AB 1856, Age verification signals: software applications — California Legislature · 2025-2026 session · Wicks · every definition quoted in this post
2. AB 1856 bill history — California Legislature · Senate passage 26 August 2026, Assembly concurrence 27 August 2026, engrossing and enrolling
3. California AB 1043, Digital Age Assurance Act — California Legislature · chaptered 13 October 2025 as Chapter 675, Statutes of 2025 · operative 1 January 2027

Who wrote this

Tuan Nguyen — Growth · Didit

Writes about identity verification, fraud and compliance at Didit.

Last reviewed 31 Aug 2026 against the sources above