AB 1043 creates a standardized, system‑level mechanism for indicating a device user’s age range to applications and app stores. It requires operating system providers to collect a device user’s birth date or age during account setup (or via a later interface for older devices) and to expose a real‑time, secure “age bracket” signal to developers and covered application stores that request it.
The signal is limited to four non‑PII categories: under 13, 13–15, 16–17, and 18 and over.
The bill matters because it shifts age verification from ad‑hoc developer checks to an OS/app‑store managed signal, making compliance with child‑protection rules more uniform while imposing technical and legal obligations on operating system providers, covered application stores, and developers. It includes transition deadlines, penalties for violations, a limited safe harbor for good‑faith technical errors, and explicit nondiscrimination and antitrust safeguards.
At a Glance
What It Does
Requires operating system providers to collect a device user’s age or birth date at setup (or via an accessible interface) and to provide a secure, real‑time API that sends a minimal age‑bracket signal to developers and covered application stores that request it. Developers must request the signal when an app is downloaded and launched and treat the signal as the primary indicator of a user’s age unless they have clear and convincing internal evidence otherwise.
Who It Affects
Operating system providers (the entities that control device OSes), covered application stores and platforms that distribute third‑party apps, and app developers who must request, receive, and rely on the signal. Parents or legal guardians acting as account holders and child users are directly implicated by the data collection and signaling rules.
Why It Matters
The bill centralizes age‑classification at the OS/store level, creating a single, standardized signal that could simplify developer compliance with laws protecting children while concentrating responsibility and sensitive tradeoffs at platform operators. It also sets civil penalties, a transition timetable, and a non‑use/competition rule aimed at limiting platform leverage.
More articles like this one.
A weekly email with all the latest developments on this topic.
What This Bill Actually Does
AB 1043 defines a compact age‑verification system that lives at the operating system and app store level. At account setup an account holder must indicate the device user’s birth date or age; that information is transformed into an age bracket and exposed only as a non‑PII signal.
The law limits bracket choices to four bands (under 13; 13–15; 16–17; 18 and over) and requires the operating system to deliver that bracket via a reasonably consistent, secure, real‑time API to any developer or covered application store that requests it.
Developers are required to request the signal when an application is downloaded and launched. When a developer receives a signal, the law deems the developer to have actual knowledge of the user’s age range across all platforms and access points for that application; therefore developers must use the signal as the primary indicator for age‑based decisions unless they possess internal, clear and convincing evidence that the signal is wrong.
The statute also bars developers, operating system providers, and covered stores from requesting or sharing more information than needed to supply the bracket signal and prohibits sharing the signal for purposes not required by the law.The bill phases in the requirements: for devices set up before January 1, 2027, operating system providers must add an interface by July 1, 2027; developers must request signals for qualifying app installs by that same July 1, 2027 deadline. Enforcement is by the California Attorney General, with civil penalties up to $2,500 per affected child for negligent violations and up to $7,500 per affected child for intentional violations.
The law provides a limited safe harbor for operating system providers and covered app stores that make good‑faith compliance efforts given technical limits or outages, and it expressly excludes broadband, telecom services, and physical products from its scope.
The Five Things You Need to Know
Operating system providers must collect a user’s birth date or age at account setup (or through a later accessible interface) and expose a secure age‑bracket signal in four categories: <13, 13–15, 16–17, and 18+.
Developers must request the signal when an app is downloaded and launched; upon receipt they are legally deemed to have actual knowledge of that user’s age bracket across all platforms of the app.
If developers have internal ‘clear and convincing’ evidence the signal is wrong, they may treat that evidence as primary; otherwise the signal controls age‑based handling.
Deadlines: OS providers must provide the interface for pre‑existing accounts by July 1, 2027; developers must request signals for qualifying pre‑2027 app installs by July 1, 2027.
Enforcement and penalties: the Attorney General may seek injunctions and civil fines up to $2,500 per affected child for negligent violations and $7,500 per affected child for intentional violations; OS/providers/stores receive a limited good‑faith safe harbor for erroneous signals.
Section-by-Section Breakdown
Every bill we cover gets an analysis of its key sections.
Definitions and scope
This section sets the vocabulary: who counts as an account holder, what 'age bracket data' means (the four non‑PII categories), what constitutes a covered application store, developer, operating system provider, and who the 'user' is. The definitions narrow coverage in important ways—e.g., account holder excludes parents not associated with a user’s device and emancipated minors’ parents—and carve out plug‑ins/extensions that run entirely inside host applications.
Operating system obligations and developer reliance rules
This is the operational core: OS providers must present an accessible interface for capturing birth date/age and must provide a secure, reasonably consistent real‑time API or equivalent to send only the minimal age‑bracket signal to developers who request it. Developers must request the signal at download/launch, are deemed to have actual knowledge of the age bracket across all app access points once they receive it, and must use the signal as the primary age indicator unless they possess clear and convincing internal evidence to the contrary. The section also forbids requesting or sharing more information than necessary.
Transition rules and retroactive installs
This section creates implementation deadlines: for devices set up before Jan 1, 2027, OS providers must add the account interface by July 1, 2027. It also requires developers to request signals for apps that were last updated on or after Jan 1, 2026 but were installed before Jan 1, 2027, if they have not already requested a signal—also by July 1, 2027. These timing rules aim to accelerate coverage while giving legacy devices a grace period.
Enforcement, penalties, and safe harbor
The Attorney General enforces the title via civil suits and injunctions; penalties run up to $2,500 per affected child for negligent violations and up to $7,500 per affected child for intentional violations. The statute creates a good‑faith safe harbor for operating system providers and covered app stores that make reasonable efforts to comply, taking into account available technology and outages; that safe harbor explicitly does not shield developers’ downstream misuse of signals.
Antitrust, nondiscrimination, and exclusions
This section prevents the law from being read to alter antitrust rules, limits required data collection to only what’s necessary, and requires OS providers and covered stores to treat first‑party and third‑party apps equally with respect to restrictions and distribution. It also bars using data collected under the law to compete against third‑party apps or prefer the platform’s own services. The title lists exclusions (broadband, telecom, physical products) and includes severability and a non‑liability clause for mismatched users.
Effective date
The statute becomes operative January 1, 2027, establishing the baseline for the transition timelines in Section 1798.502. Practically, this gives vendors a short runway to implement interface changes, API endpoints, and developer workflows before the July 1, 2027 compliance milestones.
This bill is one of many.
Codify tracks hundreds of bills on Technology across all five countries.
Explore Technology in Codify Search →Who Benefits and Who Bears the Cost
Every bill creates winners and losers. Here's who stands to gain and who bears the cost.
Who Benefits
- Children and guardians: The law standardizes age signals so apps can more reliably apply age‑appropriate safeguards (content restrictions, default privacy settings) without bespoke age checks.
- Compliance teams at app developers: A uniform OS/store signal reduces the need to build and maintain proprietary age verification systems and can lower legal risk when the signal is used as the primary indicator.
- Child‑safety regulators and advocates: Centralized signals make it easier to assess whether platforms are applying age‑based protections and to hold parties accountable under child‑protection statutes.
Who Bears the Cost
- Operating system providers: Must add account‑setup interfaces, implement secure real‑time APIs, and maintain availability—requiring engineering resources, UX work, and potential privacy and security audits.
- Covered application stores and large platforms: Need to support API endpoints and request/relay signals, plus update developer documentation, terms, and compliance tooling.
- Developers (especially small teams): Must change install/launch flows to request signals, treat signals as authoritative in most cases, and potentially redesign features or content gating to comply, increasing development and QA burden.
Key Issues
The Core Tension
The bill balances two legitimate goals—protecting children online by creating a reliable, system‑level age indicator and protecting user privacy by limiting data shared to non‑PII brackets—but centralizing that function at OS and store operators concentrates technical responsibility and commercial power, creating a trade‑off between ease of compliance and risks of platform leverage, accuracy failures, and edge‑case harms that the statute only partially resolves.
The bill centralizes age classification at OS and app‑store operators, which reduces duplicated verification efforts but concentrates sensitive functionality and power. That concentration raises questions about whether OS providers and stores, even with nondiscrimination clauses, will be able to resist incentives to leverage age data in product‑placement or ranking decisions—an outcome the statute attempts to prohibit but does not fully eliminate technically or commercially.
The nondiscrimination language targets obvious misuse, but proving competitive harm or covert preference will be fact‑intensive and likely hinge on implementation details and access to internal platform logs.
Accuracy, privacy, and multi‑user device realities collide in operation. The law requires only minimal, non‑PII brackets, which reduces privacy risk, but turning a birth date entered at account setup into a systemwide signal may cause mismatches on shared family devices, devices used by babysitters, or situations with emancipated minors (whose parents are excluded).
The safe harbor for OS providers for erroneous signals limits liability for technical mistakes but leaves developers exposed to AG enforcement if they ignore signals or misapply them. Finally, the 'deemed actual knowledge' rule simplifies enforcement but increases developers' legal exposure: even inadvertent reliance on an incorrect bracket can trigger penalties if a violation is framed as negligent or intentional, raising the question of how much verification burden developers must bear beyond the signal.
Try it yourself.
Ask a question in plain English, or pick a topic below. Results in seconds.