Microsoft has confirmed that Windows 11 will soon carry age signals for every signed-in user, starting with Teams Free. The operating system will tell registered apps which age bracket you fall into, without handing over your birth date. The federal Parents Decide Act would make that collection mandatory at setup. When the OS starts asserting your age, the enforcement chokepoint drops one layer down the stack, and platforms inherit a signal they never collected themselves.
This is the latest chapter in the age verification and the identity-verification crisis. By the end you can map the rulebook onto OS-level enforcement: which bar applies where, and how to route your platform to the right threshold.
How do OS-level age signals (Windows 11, the Parents Decide Act) shift enforcement to the platform chokepoint?
When the operating system asserts a user’s age, enforcement moves from websites and app stores down to the device, and the receiving platform inherits a legal duty it did not volunteer for.
Microsoft has documented the mechanics. Windows 11 will expose APIs like GetUserAgeRangeAsync and GetAgeVerificationStatusAsync that tell a registered app which bracket a signed-in user falls into and whether that age is verified or opted out. The app gets a coarse band, not a birth date, and the APIs are not live yet.
What matters is the “actual knowledge” trigger. Under COPPA, California’s AB 1043 and the Digital Age Assurance Act, receiving that bracket deems a developer to know the user’s age range. The “we didn’t know” defence disappears, and a user flagged under 13 activates the full children’s-privacy regime automatically.
Compare the app-store model, where Google ships Play Integrity age signals on Android and Apple has a Declared Age Range API. The OS approach is more comprehensive because it can reach the open web where app-store signals cannot, though that browser-to-website path is still unresolved.
The caveat is that a signal is only a declared age, not a verification. The bracket comes from what the user declared at setup. No document, no face, no wallet. It is the same mandate gap that regulation keeps widening, one layer lower.
What does “highly effective age assurance” mean under Ofcom’s standard, and how is it different from “commercially reasonable”?
Before you can route a platform, you need to know which bar applies. There are two. “Highly effective age assurance” is an outcome bar, judged on whether the method actually works. Ofcom scores it against four criteria: technical accuracy, robustness, reliability and fairness. “Commercially reasonable” is an effort bar, judged on whether you took proportionate steps. Confusing the two is an easy route to choosing the wrong method.
Ofcom has set no numerical thresholds, so the standard lives in its Part 3 guidance on highly effective age assurance, issued under the Online Safety Act 2023. It names seven methods that can meet the bar: open banking, photo-ID matching, facial age estimation, mobile network checks, credit card checks, email-based estimation and digital identity services. Self-declaration and a bare date-of-birth entry do not qualify. The joint statement from the ICO and Ofcom reconciles those duties with data protection, because Article 25(1A) of the UK GDPR now makes children’s design protection a legal duty.
“Commercially reasonable” comes from the US state laws, notably New York’s S 8102 and A 8893, which require device makers and app stores to apply it at activation. You get flexibility in method choice, but the burden of reasonableness sits with the operator. One bar is judged on what a method achieves; the other on what you attempted.
The common failure is choosing estimation where a jurisdiction demands verification, or the reverse. It is also where photo-ID matching gets picked by default, even though facial estimation, open banking and wallet credentials clear the same bar without leaving a stored document on your business’s servers. For the wider trade-offs, compare the method spectrum.
Can one verification flow serve the US states, the EU and Australia?
The short answer is no, not without layering, because the three regimes demand different evidence. US states are document and attestation heavy, the EU wants attribute-only selective disclosure, and Australia forbids government-ID checks outright.
California’s AB 1043, the first enacted OS-level mandate, takes effect in January 2027 and requires the OS to transmit a standardised bracket, under 13, 13 to 16, 16 to 18, or 18 plus. California and Colorado exempt open source; Illinois does not. The EU is heading the other way: the draft KIDS Act would bar under-15s from social media and require a certified EU solution using a zero-knowledge proof, so a user proves they are over 16 without revealing who they are. The EUDI Wallet‘s mini-wallet design already implements this selective disclosure, relocating trust away from a stored ID, and the KIDS Act would hardwire it.
Australia sits elsewhere. Its under-16 social media restriction took effect in December 2025, enforced by the eSafety Commissioner, who is explicit that self-declaration alone does not meet the “reasonable steps” standard. The regime leans against government-ID collection, a different privacy model.
A service with teenage users in the UK and the EU would run two account gates at two ages, 16 in the UK through any Ofcom-accepted method and 15 in the EU through a prescribed certified solution. You can see it landing on real platforms. Pornhub’s parent Aylo has urged Apple, Google and Microsoft to run verification at device level, and Snapchat in Australia verifies age through the ConnectID bank flow.
How do I map my platform to the correct compliance threshold across multiple jurisdictions?
Threshold mapping is a routing exercise. You establish which bar applies in each jurisdiction, then layer methods and workflow configurations so one build can satisfy divergent regimes.
The mapping begins with a data-flow inventory, every point in the user journey where age data is collected, used, inferred, processed or retained. From there the bar is set per jurisdiction: highly effective age assurance in the United Kingdom, commercially reasonable in New York-style device laws, prescribed technology under the EU KIDS Act, and the ID-prohibition stance in Australia.
The next step is routing each cohort to a proportionate method: verify, estimate, or attest. Apple, Google and Microsoft are unlikely to ship different systems per state, so extraterritoriality turns one mandate into a global build.
For Australia, the authoritative source is the eSafety Commissioner’s social media age-restriction guidance, which sets out the reasonable steps and the court-imposed penalties.
The practical route is an age assurance marketplace and multi-method workflow configuration. A unified platform combining document checks, liveness, fraud detection and configurable workflows lets one build route different cohorts to different regimes. The monitoring layer, VPN detection and displacement monitoring, is now an assumed part of compliance, not an afterthought. A separate walkthrough covers the build-versus-buy decision.
The chokepoint has moved down the stack, and platforms now inherit age signals they did not collect. The rulebook has split into an outcome standard and an effort standard, and the three big regimes cannot be served by one flow, so layering is the only workable answer. It is mappable, and that is the regulatory layer of the verification crisis now settling over the whole stack.
Frequently Asked Questions
Why is my operating system asking how old I am?
Your operating system is asking because age signals are moving from websites down to the device itself. Microsoft has confirmed Windows 11 carries OS-level age signals to limit app features, starting with Teams Free, and the federal Parents Decide Act proposes the same at setup. The OS collects a broad age bracket once and shares it with apps, so each one no longer has to ask.
What age bracket does an app actually receive from the operating system, and does it include a birthdate?
An app receives a low-entropy age bracket, not a birthdate or identity document. Windows transmits ranges such as under 13, 13 to 16, 16 to 18 and 18+ through APIs like GetUserAgeRangeAsync or GetAgeVerificationStatusAsync. The app learns only which band the user falls into, which is enough to trigger children’s-privacy duties without handing over personally identifying details.
What does “actual knowledge” mean, and what obligations does it trigger?
Actual knowledge means receiving an age bracket legally counts as knowing the user’s age range. Under COPPA, California AB 1043 and the DAAA, that deems a developer to know the child’s age, removing the “we didn’t know” defence. It automatically triggers children’s-privacy duties such as data minimisation, parental consent and restricted features.
Is OS-level age verification just government ID collection by another name?
No. OS-level age signals are deliberately designed to avoid ID collection. The operating system shares a coarse age band rather than a name, birthdate or document, so the platform never sees identity. That is different from the document-heavy US state model, where photo-ID matching or attestation is central, and from Australia’s stance, which rejects government-ID checks outright.
Does age estimation alone satisfy “highly effective age assurance”?
It can, but only where the method meets Ofcom’s outcome bar of being technically accurate, robust, reliable and fair. Ofcom accepts facial age estimation alongside photo-ID matching, open banking, mobile-network-operator checks and digital identity services. The failure is choosing estimation where a jurisdiction demands verification, or the reverse, which is the most common method-selection error.
Where can I find Ofcom’s Part 3 guidance and the ICO/Ofcom joint statement on age assurance?
Both sit on the regulators’ own sites. Ofcom publishes its Part 3 guidance on highly effective age assurance under the Online Safety Act 2023 at ofcom.org.uk, and the joint statement on age assurance with the ICO is available at ico.org.uk. Treat these as the primary sources for what the UK bar actually requires.
Where is the AU eSafety Commissioner’s social media age-restriction guidance?
The authoritative source is the eSafety Commissioner’s own site at esafety.gov.au, which publishes the social-media age-restriction guidance for the under-16 rules. It explains how the regime is enforced, what platforms must do and how displacement into VPNs, messaging and gaming is monitored. Read it alongside the ICO and Ofcom material to see how differently each regulator treats identity.
What happens if a user uses a VPN to get around an age check?
Regulators and platforms increasingly assume VPN detection as the counter. A user who routes around a device-level age gate still has to be monitored, because displacement is now treated as a compliance concern rather than an afterthought. VPN detection and displacement monitoring have become assumed parts of an age-assurance programme, not optional extras.
Do open-source projects have to comply with US state age-assurance laws?
It depends on the state, and the treatment is inconsistent. California’s AB 1043 and Colorado exempt open-source projects, while Illinois does not. That means an open-source maintainer distributing into multiple states cannot assume a single exemption applies everywhere, and should check each jurisdiction’s wording before relying on it.
If one US state passes an age-assurance mandate, does it affect my users elsewhere?
Often yes, because extraterritoriality turns one state’s mandate into a global build. A platform that must satisfy California or New York typically applies the same age-assurance flow to all users rather than building separate versions. That is why California’s AB 1043, as the first enacted OS-level mandate, exports its requirements well beyond its own borders.
What is an age assurance marketplace, and do I really need one?
An age assurance marketplace is a layer that connects a platform to multiple verification providers and methods, so one build can route different cohorts to different regimes. Because the UK, US states, EU and Australia demand incompatible evidence, most platforms cannot serve them with a single flow. An assurance marketplace plus multi-method workflow configuration is how they layer compliance without rebuilding each time.
