Operating-System Age Verification Requirements

California now has an operating-system age-signal law. It does not require Apple, Google, Microsoft, or an independent operating-system project to verify a legal identity. It requires an account holder to provide a birth date, age, or both so the system can send an age bracket to applications.

That distinction changes the privacy analysis. The law creates a device-level age signal, but the chaptered text of Assembly Bill 1043 does not mandate an ID upload, a face scan, or a permanent verified-identity credential.

What California enacted

Governor Gavin Newsom approved AB 1043 on October 13, 2025. The official bill status record lists it as Chapter 675 of the 2025 statutes. Its main requirements start on January 1, 2027.

At account setup, an operating-system provider must offer an accessible interface that asks the account holder to indicate the device user's birth date, age, or both. The system then derives one of at least four brackets:

• under 13;
• 13 to 15;
• 16 to 17; or
• 18 or older.

The statute calls that derived value "age bracket data" and defines it as nonpersonally identifiable. An application developer must request the signal when an application is downloaded and launched. A developer that receives it is treated as having actual knowledge of that user's age range across the application's platforms and access points.

Devices configured before 2027 are not outside the system. The provider must add an interface for those account holders before July 1, 2027. Certain applications downloaded before 2027 must also request a signal by that date.

The law limits the signal, not every inference

The text requires an operating-system provider to send only the minimum information needed to comply. It bars the provider from sharing the signal with a third party for another purpose. A developer may use the signal to comply with applicable law, may not request more data than necessary from the provider or app store, and may not share the signal for an unrelated purpose.

These limits matter. They contradict claims that AB 1043 itself requires an operating system to distribute a person's exact birth date or verified identity to every application. The signal carries a bracket, not the underlying date.

The remaining privacy concern is narrower. A bracket still changes what an app knows and how it treats an account. The statute gives the signal legal weight across the app's platforms. It also leaves the operating-system provider or covered app store in the middle of a new compliance exchange between the account holder and the developer.

Platform APIs show how age ranges can move without an ID

Apple already publishes Declared Age Range documentation. Its API lets an app request an age range while the person controls whether to share it. Apple's documentation is a product design, not proof that every AB 1043 requirement has been implemented.

Google documents a Play Age Signals API that returns age-related status information to an application. Google also describes regional and account requirements for that API. The existence of the API does not show that Google verified a user's legal identity, and it does not establish how California enforcement will treat Android distributions outside Google Play.

Both systems show that age-range exchange can be implemented without sending an identity document to each app. They also show why "OS-level age verification" is an imprecise label. The operating system or store can pass a declared or account-derived range even when no government ID was checked.

Shared devices remain a hard case

AB 1043 defines the user as a child who is the primary user of the device. It assigns the age-entry step to an adult account holder or a parent or guardian of a child associated with the device. That structure does not eliminate mismatches on devices used by several people.

The statute gives providers a good-faith safe harbor for an erroneous signal when they account for available technology and reasonable technical limits. A developer must normally treat the received signal as the primary indicator, unless the developer has clear and convincing internal information that the person falls in another bracket.

The public record reviewed for this article does not quantify how often shared-device signals will be wrong. It also does not support a claim that the law creates an indefinite app-by-app identity history. Those questions need implementation evidence after the system is operating.

Open-source operating systems face an unresolved enforcement question

The statutory definition of an operating-system provider is broad: a person or entity that develops, licenses, or controls operating-system software on a general-purpose computing device. The text does not name Linux distributions or GrapheneOS, and it does not explain how the Attorney General would apply the duties to volunteer projects, forks, or software maintained outside California.

The Electronic Frontier Foundation argues that the law will burden open-source developers and create barriers to access. That is an attributed civil-liberties assessment, not a statement found in the statute. No official source reviewed here establishes that GrapheneOS bypasses the law or that a Linux user is exempt.

What is established, and what is not

The enacted law establishes four material facts: an age or birth date is entered at the operating-system account layer, an age bracket is sent through an interface, developers must request and act on that signal, and the California Attorney General can seek civil penalties for violations.

It does not establish mandatory identity verification, biometric collection, a government database, indefinite retention, a GrapheneOS bypass, or a platform-wide record linking every application to a verified person. Those claims require separate technical or enforcement evidence.