For most of the platforms we work with, the last two years of age-assurance law have been a scramble to answer one question: whose job is it to check. Websites blamed app stores. App stores blamed operating systems. Every new state bill redrew the line a little. In late July 2026 a bipartisan group of senators tried to settle the argument at the lowest layer of the stack. Senators Andy Kim, Adam Schiff, Cynthia Lummis, and John Barrasso introduced the Digital Age Assurance Act of 2026 (S.5090), which would make the operating system the primary source of a user’s age and push that age out to apps, browsers, and covered websites through a secure, real-time API (sponsor announcement).
The privacy instinct behind it is right, and it is worth saying so before the criticism starts. The bill explicitly keeps government IDs and facial scans out of the required path, names verifiable credentials and zero-knowledge proofs as the preferred transport, and forbids selling or profiling on the age data it creates. That is a better default than the document-upload gate most of the internet reached for in 2025. But the part almost nobody has read closely is the taxonomy, and the taxonomy is the whole story. The API does not return an age. It returns one of four brackets: under 13, 13 to 15, 16, and 17 or older. There is no 18 bracket. There is no 21 bracket. The ladder stops one rung below every threshold that actually carries an age-restriction fine.
What the bill actually mandates
Strip the framing and the mechanics are specific. An operating system provider collects a user’s date of birth during account setup, or from existing account holders, and converts it into one of the four brackets rather than storing or sharing the exact date (Biometric Update). That bracket becomes a signal delivered over a secure real-time API. Apps, browsers, app stores, and covered websites must request it and treat it as the primary indicator of the user’s age. Accounts for anyone under 17 generally have to be linked to a parent or guardian account.
Two provisions do most of the legal work. First, the browser obligation is narrow: it applies only to websites already required by federal or state law to verify age before granting access, not to the whole web, so this is not a login wall bolted onto every page. Second, and this is the one to underline, once a developer or covered website receives the signal it is “deemed to have actual knowledge of the user’s age bracket across every platform and point of access.” From that moment it is unlawful to let that user reach anything your own policies classify as inappropriate for their bracket. The signal is not advisory. It is a knowledge event with liability attached.
The rest is guardrails. The initial registration is based on what the user types, not documentary proof, and a provider or platform acting in good faith is not liable when a user lies. Developers and websites also get liability protection for acting on an erroneous signal from the OS or app store. Data-minimization rules bar collecting more than the signal, combining it with other data, or using it for profiling, engagement optimization, or targeted advertising. Enforcement runs through the FTC and state attorneys general, with civil penalties up to $2,500 per negligent violation and $7,500 per knowing one, multiplied by the number of children affected. There is no private right of action. The Act would take effect 18 months after enactment, with the FTC given a year to write the rules, and it is not law yet: it sits in the Senate Commerce Committee.
The brackets are the tell
Look again at the four bands, because they are not evenly spaced and they were not meant to be. Under 13 is the COPPA line. The 13-to-15 band maps to the teen protections spreading through state privacy law. The lone bracket for 16 exists because several 2026 social-media laws set their threshold there, a line we have argued breaks the age-estimation playbook precisely because the buffer disappears. And then everything from 17 upward collapses into a single bucket: “17 or older.”
That top bracket is the problem, and it is a design decision, not an oversight. The bill is a child-safety instrument. Every rung on its ladder exists to sort minors into the right protective regime, so it stops sorting the moment a user is plausibly not a minor. For the purpose the drafters cared about, seventeen-and-up is one undifferentiated group, because none of the child protections apply to any of them.
Now hold that against the flows that generate actual enforcement risk. Alcohol, tobacco and vape, gambling, firearms and ammunition, cannabis, and adult content are not gated at 17. They are gated at 18 or 21. A signal whose highest resolution is “17 or older” cannot express either line. Handed a “17+” bracket, an alcohol retailer knows only that the user is probably not a child. It does not know whether the user is a 17-year-old who cannot legally buy, a 19-year-old who cannot buy in a 21 jurisdiction, or a 40-year-old who can. The federal signal is built to tell you someone is a kid. It is structurally incapable of telling you someone is old enough. Those are different questions, and the highest-risk half of the internet only cares about the second one.
Declared, not verified
Even inside its own age range the signal is soft, because of where the number comes from. The date of birth is typed into a settings screen at OS setup. No document, no liveness, no check. The bill is candid about this: registration rests on user-entered information, and good faith absolves everyone in the chain when the user lies.
We have made this argument before about store-level signals, and the federal bill inherits the same weakness at a larger scale. A Play age signal or an Apple declared age range is one input, not a system of record, and a device or OS mandate does not become verification just because a statute names it as the default. What S.5090 adds is a legal fiction stacked on top of a self-declared field: receiving the bracket is “actual knowledge,” even though the bracket itself was never verified. You are deemed to know something the system took on trust.
The bill half-admits this in its conflict-resolution path, which is lifted almost directly from California’s approach. When a platform obtains “clear and convincing information” that a user’s real age differs from the bracket, it must temporarily rely on the conflicting information, notify the user or a linked parent, and route the discrepancy back to the OS provider, which is supposed to verify and redistribute an updated signal within a correction window. California’s version of that step-up is the subject of its own analysis, the clear-and-convincing standard behind AB 1043. The federal draft borrows the mechanism and then punts on the hard part: it never says how the OS provider actually verifies. The one moment the framework needs real assurance, it delegates to an unspecified process at a company that started with a typed-in birthday.
Two federal frameworks, one delegation
S.5090 is not the first attempt to push age down to the operating system. The Parents Decide Act (HR 8250) already proposed an OS-level federal regime aimed at app developers. So Congress now has at least two competing federal designs for the same idea, sitting on top of the state App Store Accountability Acts already in force in Texas, Utah, Louisiana, and beyond, and none of them has displaced the others.
The Digital Age Assurance Act’s distinguishing move is what it refuses to require. It bars mandating government ID, biometrics, other sensitive personal information, or facial age estimation as the price of a signal, which makes it the lighter, declared-signal model rather than a verification mandate. It also carries real competition rules: Apple, Google, and Microsoft cannot impose stricter age requirements on third-party apps than on their own, and cannot force proprietary dependencies without a genuine security reason, with violations treated as antitrust matters. On preemption it is deliberately weak. It overrides only conflicting state laws and expressly preserves any state or federal rule that is at least as strong, and it leaves COPPA untouched.
For a relying party, the takeaway is not “wait and see which bill wins.” It is that none of these frameworks removes your obligation, and the strongest applicable rule still governs. If a state draws a harder line, that line survives. If COPPA already binds you, it still binds you. The US compliance patchwork does not get simpler under S.5090. It gets a new, coarse, federally blessed input on top of everything that was already there.
What it delegates, and what it leaves on your plate
Read cynically, the bill hands relying parties one genuinely useful capability and quietly keeps the expensive one on their books.
The useful capability is a cheap, privacy-clean way to segment minors. On every session, on hardware where the signal exists, you can learn “under 13,” “13 to 15,” “16,” or “not a child,” without collecting anything, storing a document, or running a face model. For deciding whether to show a teen experience, suppress a feature, or keep the contextual-ad default that the 2026 targeting rules now demand for minors, that is exactly the right instrument. This is a Check: fast, low-assurance, ambient, disposable.
What the bill leaves on your plate is everything above the top rung. When the decision is a real age-restricted purchase or an adult account, the “17+” bracket does not authorize it, and the declared-then-deemed nature of the number means it would not survive a challenge even if the line were 18. You still own that decision, and you still own it under whichever of the overlapping regimes is strongest for your product.
Then there are the coverage gaps the API model creates. The signal is missing or wrong on shared and family devices, where one logged-in account does not describe the person actually holding the phone, a failure mode we have written about as the binding problem on shared hardware. It is absent for users with no OS account, on older OS versions that never shipped the API, on the desktop web, on kiosks, and on the long tail of platforms the four named vendors do not control. A gate of record cannot depend on an input that is silent for a material slice of your traffic. And the same data-minimization rules that make the signal privacy-clean also make it radioactive to your existing stacks: you cannot combine the bracket with other data or feed it to profiling and ad systems, which means the analytics and monetization plumbing that touches every other user attribute has to route around this one or inherit its restrictions. Treating a bracket like any other data point is how a compliance win becomes a retention-and-breach liability.
The build that survives whichever bill passes
The architecture that holds up under S.5090, the Parents Decide Act, the state app-store laws, or nothing at all is the same one, because it does not bet on any single statute or signal source. It sorts the two jobs the law keeps conflating and uses the right tool for each.
- Consume the OS bracket as a first-pass Check, never as the gate of record. Take the signal where it exists and let it route the clearly-under-age population and set experience by band. Treat “17 or older” as “not a child,” which is all it means. Never read it as “old enough to buy.”
- Keep a real Verification at the narrow chokepoint. For any 18 or 21 flow, step up to a document plus liveness check, because the federal signal structurally cannot express those thresholds and the typed-in birthday behind it will not carry the fine. This is the same Check-versus-Verification split we apply everywhere, pointed at the one decision the bracket cannot make.
- Make the step-up one-time, not one-per-site. If the adult who verifies once can carry a reusable credential and prove it everywhere after, the cost of doing real verification where it is genuinely required stops being a funnel-killer and becomes a lookup.
- Stay signal-agnostic. Consume the OS signal, wallet-based digital credentials from Apple and Google, and zero-knowledge age proofs through one resolution layer. The bill itself refuses to mandate a single method, so hard-coding one source is a bet the statute declines to make.
- Retain the decision, not the identity. Store the resolved band or the pass or fail, the timestamp, and the method. Do not warehouse the ID image or the biometric, and do not let the bracket leak into profiling or ad targeting. The bill punishes that directly, and the breach wave punishes it separately.
- Wire the conflict path now. Build the clear-and-convincing step-up, the parent or user notice, and the correction-and-redistribution loop, so a wrong bracket has a defined route to being fixed rather than becoming your defense in an enforcement action.
The drafters of S.5090 made our central point for us when they ended the ladder at seventeen. A federal age signal that refuses IDs and face scans is the right tool for the job it was designed to do, which is keeping children out of experiences built for adults. It was never designed to authorize the adult, and the missing 18 and 21 rungs are the proof. Consume it as the cheap Check it is, keep a real Verification on the door that carries the penalty, and the question of which age bill becomes law stops being an architecture decision and becomes a footnote.
