Most of the coverage of California’s Digital Age Assurance Act has fixated on what it gives developers: a clean, device-level age signal from Apple and Google that you can request at launch and act on, without ever touching a government ID. That part is real, and it is a relief after two years of every state inventing its own verification mandate.
But the signal is not the interesting part of AB 1043. The interesting part is the sentence that governs when you are allowed to rely on it — and when you are not. The law tells developers to treat the operating system’s age signal as the “primary indicator” of a user’s age unless they have “clear and convincing” information that the age is different. That single clause is where compliance is won or lost. It quietly converts a passive obligation (“read the signal”) into an active one (“notice when the signal is wrong”), and it means the app store flag is only a defense for as long as you don’t know better.
If you are building toward the January 1, 2027 effective date, the question that should be driving your architecture is not “how do I read the age signal?” It’s “what happens in my product the moment I have reason to believe the signal is lying?”
What AB 1043 Actually Does
Governor Newsom signed AB 1043, the Digital Age Assurance Act, on October 13, 2025. It takes effect January 1, 2027, and it adopts a device-centric model that is deliberately different from the document-upload regimes other states have pursued.
The mechanics are straightforward. At account setup, operating system providers — practically, Apple and Google — must prompt the account holder to enter a birth date or age. The OS then exposes an age range, not a date, to developers who request it: under 13, 13 to under 16, 16 to under 18, or at least 18. Application developers must request that signal when their app is downloaded and launched, and must treat it as the primary indicator of the user’s age. For accounts created before the effective date, the OS providers have until July 1, 2027 to expose the interface, and developers of apps last updated on or after January 1, 2026 must request the signal by that same July 2027 date.
Enforcement has teeth. Violations carry civil penalties of up to $2,500 per affected child for negligent violations and up to $7,500 per affected child for intentional ones, plus injunctive relief. “Per affected child” is the phrase to sit with — in a consumer app with any meaningful minor population, those numbers compound into existential territory fast.
This is the same plumbing Apple’s Declared Age Range API and Google’s Play Age Signals API were built to serve. Google’s bands (0–12, 13–15, 16–17, 18+) and its practice of refreshing a cached signal two to eight weeks after a user’s birthday tell you something important: the signal is an estimate maintained by a third party on a lag, derived from a self-declared birth date the platform mostly did not verify. AB 1043 lets you lean on it. It does not let you stop thinking.
The “Primary Indicator” Safe Harbor — and Its Limit
The “primary indicator” language functions as a qualified safe harbor, and that is genuinely useful. If you request the signal, gate your experience to the returned age band, and otherwise behave reasonably, the law does not also demand that you collect IDs or run biometric checks on everyone. For the large majority of your users — the ones whose declared age is accurate and uncontested — the signal is the beginning and the end of your duty. That is a real reduction in friction and in data-collection liability, and it is why the app-store model is attractive.
The limit is structural. A safe harbor that evaporates the moment you acquire contradictory knowledge is not a safe harbor you can architect around passively. It is a conditional defense, and the condition is your own ignorance. The law is explicit that the signal governs unless clear and convincing information says otherwise — which means the protective value of the signal is inversely proportional to how much you actually know about your user. The better your product is at understanding its users, the more often you will cross into territory where the default no longer holds.
That is an uncomfortable inversion for any data-rich product. The teams most exposed to the override are not the careless ones. They are the sophisticated ones — the platforms with behavioral models, payment histories, self-service profile fields, and support transcripts — because they are the ones most likely to be holding the very evidence that legally obligates them to act.
What Counts as “Clear and Convincing”
“Clear and convincing” is a real evidentiary standard, not marketing language. It sits above “preponderance of the evidence” (more likely than not) and below “beyond a reasonable doubt.” In practice it means the contradictory information has to be substantially more probable than not — a single noisy data point won’t trip it, but a strong, coherent signal will.
The statute doesn’t enumerate what qualifies, which is exactly why you should treat the question as a product and risk decision rather than wait for a regulator to define it for you. The honest reading is that you are obligated to act when your own systems are holding evidence a reasonable person would find convincing. Concretely, that tends to come from a few places you already instrument:
Self-reported contradictions. A user whose OS signal says 18+ enters a birth date in your own profile flow that puts them at 15. You now hold a direct, first-party contradiction. This is the cleanest possible trigger, and “but the app store said 18” is not a credible answer to it.
Payment and identity artifacts. A card-issuer name, a billing record, a linked bank account, or a KYC step that surfaces a date of birth inconsistent with the age band. Financial data is high-quality evidence and hard to wave away.
Behavioral and content signals. School-schedule usage patterns, self-descriptions in profiles or messages (“I’m a sophomore”), or content that a reasonable reviewer would read as coming from a minor. These are softer individually but can aggregate into something convincing.
Support and trust-and-safety records. A parent reports that their child is using an adult account. A moderation flag identifies a likely minor. Once that information is in your ticketing system, the clock on your knowledge has started.
The unifying principle: the override is triggered by your knowledge, not the platform’s. The app store does not see your profile fields, your payment rails, or your support queue. You do. AB 1043 makes that asymmetry your problem.
Why This Forces a Step-Up Verification Capability
Here is the trap in operational terms. When you detect clear and convincing evidence that the signal is wrong, the law obligates you to act on the correct age — but you don’t actually know the correct age yet. You have evidence that the signal is wrong, which is not the same as having a defensible answer for what’s right. A user might be deliberately lying in either direction. A contradictory profile birth date could itself be the false one.
So the override doesn’t just demand that you ignore the signal. It demands that you resolve the contradiction, and resolving it requires a verification path you can invoke on demand — for one user, mid-session, without rebuilding your onboarding. That is step-up verification: the ability to escalate a specific user from “trusting the signal” to “establishing a defensible age decision” the instant your systems flag a conflict.
A product that only knows how to read the app store signal has no answer in that moment. It can either ignore its own evidence (negligence, and now arguably willful) or hard-block the user (a conversion and support disaster, frequently against a real adult). Neither is acceptable, and the gap between them is exactly the capability AB 1043 quietly requires you to have built.
A Decision Framework: Default, Detect, Escalate
The clean way to build for this is to treat the age signal as a default state that your own systems are continuously allowed to override, with verification as the escalation path. Three layers:
Default to the signal. Request the OS age signal at launch, gate the experience to the returned band, and let it stand for the ordinary case. Don’t over-collect. For the user with no contradictions, the signal is the whole story, and the law rewards you for not demanding more.
Detect contradictions continuously. Wire your first-party data — profile fields, payment events, KYC results, T&S flags, and meaningful behavioral signals — into a rule that asks one question: does this rise to clear and convincing evidence that the band is wrong? Crucially, this is not a one-time onboarding check. The override can be triggered weeks after signup, the day a parent files a report. Your detection has to live for the life of the account.
Escalate to verification only when triggered. When the threshold is met, route that single user into a real age-assurance step that produces a defensible decision and an audit record — not a friction tax on your whole base, just a targeted resolution for the contested case. Then bind the result so you’re not re-litigating it every session.
This is also the difference between negligent and intentional in the penalty structure. A documented “detect and escalate” pipeline is your evidence that, once you knew, you acted. Its absence is what turns a $2,500 negligent violation into a $7,500 intentional one — because a regulator looking at a product that held the contradicting data and shipped no mechanism to act on it will not read that as an accident.
The Web Gap AB 1043 Leaves Open
One more thing the signal model doesn’t solve: it stops at the edge of the app store. AB 1043’s machinery runs through operating systems and the apps distributed on them. Your website, your mobile web experience, your API surface, and any flow a user reaches in a browser get no OS age signal at all. For multi-surface products — and almost everything regulated is multi-surface — “we use the app store signal” covers one channel and leaves the others to whatever obligations apply there, including California’s other youth-safety statutes and the dozen states with their own web-facing mandates. A verification capability you own is the only thing that spans both the in-app contradiction and the no-signal-at-all web session.
Where Xident Fits
This is the precise problem Xident is built to absorb. We give you an age-assurance layer you own and can invoke on demand — so the app store signal can be your default while you retain a real answer for the moment it stops being trustworthy.
In practice that means consuming the OS age signal where it exists, and exposing a single step-up verification call you can trigger the instant your own systems detect a clear and convincing contradiction. That call runs a privacy-preserving waterfall: light, on-device estimation for the easy cases, escalating to document or credential checks only for the genuinely contested band around each threshold, and never forcing a government ID where a lighter method will do. The decision binds to a reusable, token-based credential, so once a contested user is resolved you are not re-verifying them every session — and you hold a durable, timestamped audit record showing exactly when you knew, what you did, and what method established the age. That record is the difference between a documented good-faith response and an intentional violation.
Because the same flow runs on web as in your app, it also closes the surface gap the OS model leaves open. One integration covers the in-app override and the browser session the app store never sees.
The Bottom Line
AB 1043 is not really a “read the signal” law. It is a “notice when the signal is wrong, and be able to do something about it” law, and the “clear and convincing” clause is the part that will actually generate enforcement. The platforms hand you a convenient default; the statute makes your own knowledge the thing that voids it. The teams that treat the app store signal as the finish line will find that the better they understand their users, the more often they are sitting on evidence the law says they were obligated to act on. The teams that build a detect-and-escalate path now — signal as default, verification as escalation, audit trail throughout — will have an answer ready when the contradiction shows up. And in a data-rich product, it always does.
Building toward the January 1, 2027 AB 1043 deadline and need a step-up verification path you can trigger when the app store signal isn’t enough? Talk to our team about a developer-owned age-assurance layer that defaults to the signal and escalates only when your data says it should.
