For two years the age-verification argument was about your onboarding screen: which vendor, which method, how much friction, how many users you lose at the ID upload. In 2026 the argument moved down the stack. Four states have now decided that the operating system should determine a user’s age and hand it to your app as a signal — no ID upload on your site, no selfie in your flow, just an age category arriving over an API.
If you run a platform, this sounds like relief. The device does the hard part; you read a field. It is not relief. The laws don’t agree with each other on what the signal means, when it fires, or what it obligates you to do once you have it — and in most of them the “signal” is a birthdate the user typed into a setup screen. You are being handed a fragmented, low-assurance input and told it is your problem now. This is the playbook for what to actually build.
What Actually Passed: The 2026 Device-Signal Map
Start with the facts, because the coverage blurs them together and the differences are the whole story.
California — AB 1043, the Digital Age Assurance Act. Enacted, effective January 1, 2027. At device setup the OS asks for the user’s age or date of birth, uses that declared age to curate the app store, and shares an age signal with developers on request. We covered its step-up mechanics in the AB 1043 teardown; the mechanism to keep in mind here is that the age is declared, not proven.
Colorado — SB26-051, Age Attestation on Computing Devices. Signed by Governor Polis on June 3, 2026, effective January 1, 2028. OS providers offer a setup interface for the user to self-report a birthdate or age, generate a broad age-bracket signal, and expose it to applications via a real-time API on download or launch. The statute is honest enough to call the goal attestation.
Illinois — HB 5511, the Children’s Online Social Media Safety Act. Given final passage on June 1, 2026 by a 57-0 Senate vote and 113-0 House concurrence, awaiting a signature Governor Pritzker has already pledged. Two obligations, and the second is the one people miss. By January 1, 2028, OS providers must offer a setup interface for a birthdate or age and return an age-category signal on request, minimum data only. Separately, operators — the platforms — may not offer a covered platform in Illinois without conducting age verification, and for any user they have actual knowledge is a minor they must apply default settings: no algorithmic feed, restricted profile visibility, limited media, location sharing off, notifications suppressed overnight. Enforcement runs through the Attorney General at up to $2,500 per child for negligent violations and $7,500 per child for intentional ones. The EFF urged a veto; the votes suggest that isn’t coming.
New York — S8102A. Still in the Consumer Protection Committee, not enacted, and the most aggressive of the four. It requires manufacturers of internet-enabled devices to conduct “commercially reasonable age assurance” — assurance, not attestation — and expose a user’s age category (under 13, 13 to under 16, 16 to under 18, or 18 and over) to every website, service, app, and app store on the device through a real-time API, on activation or within 180 days for existing devices.
Two accelerants sit behind these. The federal Parents Decide Act (HR 8250) would mandate OS-level age checks nationally, and the Supreme Court on July 6, 2026 cleared Texas to enforce its app-store law while litigation continues, on the heels of the app-store accountability acts going live. The direction is settled: the age decision is being pushed toward the device. The details are anything but.
The Signals Don’t Agree With Each Other
Here is the trap inside the good news. If all four laws produced the same signal, the device layer would genuinely simplify your life — one integration, one field, done. They don’t.
The assurance level differs. California, Colorado, and Illinois accept a self-declared birthdate. New York demands “commercially reasonable age assurance,” which is a materially higher bar — a typed birthday does not satisfy it. So “the OS says this user is 18+” means one thing in Denver and a stronger thing in Albany, and your code receives both through similar-looking APIs.
The age brackets differ. New York enumerates four categories. Illinois speaks of an “age-category signal” without New York’s exact cut points. California’s declared-age model curates around app-store ratings. If you want a single internal policy, you are the one reconciling “under 16” against “under 18” against “16 to under 18” against an app-store maturity tier.
The trigger differs. California curates at the app-store layer and shares on request. Colorado exposes the signal on download or launch. New York wants a real-time API answer to any app or site, continuously. Illinois returns a category on request and layers separate operator duties on top.
And the obligation the signal creates differs most of all. In California and Colorado, consuming the signal and delivering an age-appropriate experience is roughly the extent of it. In Illinois, receiving a minor signal triggers a specific list of default settings you must enforce inside the product, or you are the one the Attorney General fines — the OS emitting the signal does not discharge that duty, you do. This is the fragmentation the US compliance patchwork has been trending toward, now expressed at the device layer instead of the website layer.
A Declared Age Is a Prior, Not a Proof
The quiet part, said plainly: in three of these four regimes, the mandated “age verification” is not verification. It is a dropdown at device setup. As the Fedora Project’s Jef Spaleta noted of AB 1043, “a simple dropdown interface may suffice,” which means “the effectiveness of such a system appears to be based on an honour system.” Biometric Update’s assessment was blunter still: the law “does not mandate age verification at all. Technically, it’s not even age assurance.”
For a relying party this is the single most important design fact in the entire wave. The signal you receive is a prior — a cheap, useful, often-correct hint about how old someone probably is — not a proof. Treating “OS reports 18+” as dispositive is the same category error as treating a credit card as proof of age or accepting self-declaration — the mistake that earned Reddit an ICO fine.
The error gets expensive precisely where the stakes are highest. If your product also falls under the UK Online Safety Act, Texas’s adult-content statute, a gambling regulator, or DSA Article 28, those regimes demand highly effective age assurance, and a state device attestation does not clear that bar. A minor who typed “1990” into a phone setup screen will present to your app as a verified adult under a California signal and as an unverified user under a UK obligation — simultaneously, on the same session. The device signal reduces how often you need a hard check. It never removes the obligation to have one.
The Burden Didn’t Move — It Split
The comforting story is that these laws shift the cost to Apple, Google, and Microsoft. Partly true, and partly the point: the largest platforms helped shape statutes they can absorb, while the integration lands on everyone downstream. The OS now has to emit a signal. But the operator — you — still owns everything that happens after the signal arrives.
You still decide whether to trust it. You still apply the minor-account defaults Illinois enumerates, or eat the per-child penalty. You still deliver the age-appropriate experience California expects, which means mapping the signal onto your own tiered experiences and communication defaults. And you still run actual verification wherever a stronger regime demands it. The device signal is an input to your decision, not a substitute for making one. Anyone scoping this as “read the OS field and we’re compliant” has mistaken the easiest 20% for the whole job — the same scoping error we flagged in the platform implementation guide.
Where the Signal Isn’t There
Even if you trusted the signal completely, you cannot rely on its presence. Every one of these gaps needs a fallback you build yourself.
There is no OS signal on the desktop web, where a large share of traffic still lives. Older devices predate the mandates and never prompt for age. Self-built and open-source operating systems don’t play — the AB 1043 fight already produced a Linux calculator project that chose to geoblock California rather than implement a check it considers incompatible with its principles, and Fedora and Ubuntu are still consulting lawyers. Shared and borrowed devices break the model at its root: a thirteen-year-old on a parent’s phone inherits an adult signal, which is the shared-device circumvention problem with a legal veneer. And because three of the four regimes accept self-declaration, the signal is trivially spoofable by anyone willing to type a false birthday once at setup.
The device signal is best understood as covering the easy majority on modern, single-user, mobile devices in states that have gone live. That is a real and valuable slice. It is not the population, and the residual is exactly where your risk concentrates.
What Relying Parties Should Actually Build
The architecture that survives this wave treats the device signal as the first input to a risk decision, not the decision itself. Five moves.
First, consume the signal as a scored input, not a gate. Attach a trust weight to it — high for New York’s assured signal, low for a California declared age, zero when it is absent — and let that weight drive what happens next rather than opening the door outright.
Second, normalize the fragments into one internal age-band policy. Reconcile the states’ differing brackets and semantics once, centrally, into a single set of thresholds your product reasons about, so a new state law is a config change rather than a re-architecture.
Third, escalate by risk, not by default. When the signal is strong and the stakes are low, accept it and move on — that is where the friction savings are real, and where you protect conversion. When the signal is weak, missing, or the context is high-stakes, step up to real assurance: on-device facial age estimation for a fast band, an NFC chip or document check for the edge cases that need identity-grade proof.
Fourth, keep an evidence record. Illinois, California, and Colorado enforce through civil penalties. When a regulator asks, you need to show that you received a signal, how much you trusted it, and what you did about it — which is the prove-it-works discipline applied to a signal you didn’t generate.
Fifth, keep the decision, not the data. The device model’s one genuine gift is a smaller data footprint; don’t squander it by hoarding birthdates and document images to answer a yes/no question. Store the age-band decision and discard the inputs, the way a privacy-first architecture should.
How Xident Fits
Xident was built for exactly this shape of problem, because we concluded a while ago that the device signal was coming and that it would arrive fragmented and low-assurance. Xident consumes the OS age signal as one weighted input in a risk-based flow, not as a gate. Where the signal is strong it clears the user; where it is weak, missing, or the context demands identity-grade proof, the same SDK escalates to on-device facial age estimation returning an age band (+12, +15, +18, +21, +25), with document and NFC checks behind it for the residual — and token-based returning users skip the check entirely next time.
The normalization is the part that turns four laws into one integration. Xident maps California’s declared age, Colorado’s attestation, New York’s assured age categories, and Illinois’s age-category-plus-operator-duties onto a single internal age-band policy, so you reason about one decision instead of four statutes. Every check emits an exportable, session-level evidence record of the signal received, the trust assigned, and the action taken — the artifact you hand an Attorney General instead of reconstructing one. And because the face is classified on the device and never reaches your servers, what you retain is the decision, not a biometric cache. If you want the criteria to demand from any provider, including us, the vendor security checklist lays them out.
The Real Takeaway
The age gate is moving down the stack, and on balance that is a good thing: less friction for the honest majority, a smaller pile of sensitive data, a check the user meets once at setup instead of on every site. But “the operating system will handle it” is the trap of 2026. You are not being handed an answer. You are being handed a fragmented, mostly self-declared, jurisdiction-specific hint that you still have to weigh, normalize, act on, and prove you acted on — while your other regulators keep demanding real assurance the hint can’t provide.
The teams that come out ahead treat the device signal as the first step of a risk decision, not the last. If you want to see what that looks like as something you integrate rather than build across four state statutes, start here.
