Microsoft started shipping age APIs to Windows Insiders in September 2026. Three calls, one new idea, and one value that is going to show up in your incident channel.
The calls are GetUserAgeRangeAsync, GetAgeVerificationStatusAsync and CheckAgeStatusAsync. The first returns one of five brackets: under 10, 10 to 12, 13 to 15, 16 to 17, and 18 and over. Microsoft’s framing is that an app receives only the age-related signal it needs, “not sensitive personal data such as the full date of birth”.
Hold the brackets for a moment. The second call is the interesting one.
The first OS age signal that ships its own provenance
GetAgeVerificationStatusAsync tells you how the age was produced. Verified, declared, or declined.
No other operating system vendor gives you this cleanly. Apple’s Declared Age Range returns a range. Google’s Play Age Signals returns a bracket, and only where a parent chose to share it. In both cases you get an answer and you do not get a reliable statement about how much work went into it, which is exactly why we have argued before that a store signal is not an age check.
Microsoft has separated the answer from the method, in the API surface, as a first-class return value.
That matters because every regulator currently grading age assurance grades the method, not the answer. Ofcom’s “highly effective” test asks whether the method is technically accurate, robust, reliable and fair. The EU’s draft guidance under the Digital Services Act asks about the assurance level of the technique. New York’s SAFE for Kids rules ask what the method is and what it achieves. None of them ask whether you got the right answer for a given user, because nobody can audit that. They ask what you did.
A signal that tells you “this is a declared value” is therefore more useful than a signal that silently blends declared and verified values into one bracket. It is also more dangerous for lazy integrations, because the blended version lets you pretend and this one does not. Once the API has told you in writing that the age was self-declared, calling your age gate verified becomes a claim you cannot defend.
Declined is a third state and your schema has two
Your age gate has a pass branch and a fail branch. Now consider a user who is signed in, whose account exists, who Windows can identify, and who has actively refused to verify their age.
That is not a pass. It is also not a fail. The user did not fail a check. They declined to take one.
Treat declined as false and you will lock out adults who simply do not want Microsoft confirming their age to your application, which is a reasonable position for an adult to hold. Treat it as unknown-and-therefore-fine and you have built a one-click bypass: refuse the OS prompt, get treated as unverified, fall through to whatever your default is. If your default is permissive, the most privacy-conscious user and the most motivated 14 year old have found the same door.
The correct handling is that declined routes to your own verification path, with a clear explanation, and never to either default. It is the one branch worth writing a test for before you ship, because it is the branch your QA will not hit by accident: whoever tests this will click Allow.
Two related failure modes to plan for while you are in there. A machine with no Microsoft account signed in returns nothing at all, which is a fourth state. And an API that is Insider-only today will return an error on most installs for months, so your fallback has to be the normal path rather than an exception handler.
The brackets are not arbitrary
Under 10. 10 to 12. 13 to 15. 16 to 17. 18 and over.
Compare that against the staircase in the European Commission’s KIDS Act proposal, published on 16 September 2026: no account under 13, a guardian-controlled account at 13 and 14, an independent account from 15, with a narrow parent-hosted route for younger children. Compare it against Australia’s under-16 line. Compare it against the 13 to 15 and 16 to 17 split that keeps appearing in age-appropriate design work.
An operating system vendor’s enum has started to match the shape legislatures are converging on. That is not a coincidence, and it is a hint about your own data model.
If your user record still stores a boolean called is_adult, or an integer age you derived once and never revisited, you are modelling a world that regulators left. We made this argument when the KIDS Act proposal landed: a yes-or-no answer cannot express four states, and one of those states is not an age at all but a link to another person. Microsoft’s enum is the same argument arriving through the SDK instead of through a consultation document.
Store the band, the provenance, the source and the timestamp. Not a boolean.
One operational trap in the bands: a user in the 16 to 17 bracket will cross into 18 and over at some point, and the operating system will know the date while you will not. Your application sees a bracket, not a birthday. So you cannot schedule the transition, you can only observe it on the next call. Either you re-read the signal on a sensible cadence, or you let a user sit in a restricted band for months after they stopped belonging in it. Both of those are choices. Only one of them is a choice you made on purpose.
The desktop problem is the denominator
Everything above is about the quality of the signal. The harder question is how many users it exists for.
On mobile, the operating system vendor is also the distribution channel. An app arrives through a store, the store holds an account, and a regulator leaning on two companies reaches most of the installed base. That is why Australia’s app store age checks could go live across four storefronts at once.
Windows does not work like that. Most Windows software does not come from the Microsoft Store. There is no chokepoint, which means there is no mechanism to make the signal universal, which means the signal will be present for some users and absent for others for the foreseeable future.
And the population it is absent for is not random. The age information comes from the Microsoft account signed into the device. So you get a usable signal from a child on a family-managed device in a country where Microsoft Age Verification is live, and nothing from a local account, a device signed in with a work or school identity, a shared family PC where everyone uses one profile, or a second-hand machine that was never re-enrolled.
Microsoft Age Verification is currently live in Singapore, Brazil and Australia, with expansion described as following regulatory requirements. Parental controls get extra prominence during Windows setup in some countries, including France. So the geographic coverage is a short list, and your global coverage rate will be low for a while.
This is the same lesson as the mobile signals, arriving in a sharper form. A signal that is missing for most of your users cannot be your gate of record. It can be a fast path for the users who have it.
How to actually consume it
Use it to skip work, never to grant access on its own. An 18-and-over bracket with a verified status is a good reason not to interrupt a returning adult. It is not evidence you can hand a regulator, because you cannot show how Microsoft produced it, and under the OSA you would be adopting someone else’s signal with the due diligence burden staying on you.
Branch on provenance before you branch on the number. The decision tree is status first, bracket second. Verified and 18 plus is a fast path. Declared and 18 plus is a weak prior that lowers your risk score and nothing more. Declined goes to your own flow. Absent goes to your own flow. Treating all four the same is the integration mistake that will get written up.
Log what you got and what you did with it. Bracket, status, whether the API was available at all, and the action you took. When somebody asks how your age assurance works on desktop, the answer is a distribution, not a sentence. Being able to say “we received a verified signal for 11% of Windows sessions and ran our own check on the other 89%” is a much better position than “we use the Windows age API”.
Do not degrade your existing check because a new signal arrived. The strongest control stays the control. A cheap OS signal is useful precisely because it lets you spend the expensive check where it changes the outcome.
Decide the under-13 behaviour deliberately. A bracket of under 10 or 10 to 12 on a general-audience service is not just an access decision. In the United States it is actual knowledge for COPPA purposes, and the obligations that follow are about data collection, not just about content. Route it to your children’s data path, not to a generic block.
The honest limits
This is an Insider feature. Microsoft has not published general availability dates or build numbers, and the developer documentation is thin. Enum names, bracket boundaries and status values can change before general release, so write a thin adapter rather than scattering GetUserAgeRangeAsync across your codebase.
We have not seen Microsoft publish how CheckAgeStatusAsync differs in practice from the other two, and the public reporting does not resolve it. Read the SDK documentation rather than this post for the exact contract.
Microsoft Age Verification being live in three countries is the state as reported in September 2026. It will move. Nothing in this post should be read as the current market list by the time you integrate.
Finally, none of the above tells you whether a regulator will accept the Windows signal as part of a highly effective age assurance stack. Nobody knows yet. The ones who have spoken on the mobile equivalents have been consistent that a store or OS signal is an input, and that the duty stays with the service. Assume the same here until somebody says otherwise in writing.
How Xident fits
The OS signal is an input to orchestration, not a replacement for it. This is the layered approach applied to a new source. A verified 18-plus from Windows lowers the risk score and routes the user to the cheapest confirmation path. A declined or absent signal routes them into a real check. One decision record comes out either way, carrying which inputs were used.
Provenance is already how we record decisions. Every Xident check returns outcome, method, threshold, confidence, policy version and timestamp. Adding “the operating system asserted 18 plus with status verified” to that record is a field, not a redesign, and it is what lets you report the distribution rather than a slogan.
Bands, not booleans. Xident returns an age band rather than a date of birth, which is the same shape the Windows API uses and the same shape the KIDS Act staircase needs. If you are rebuilding your schema for one of these, you are building for all of them.
The arithmetic that makes a fast path worth having. A document Verification on Growth is €0.20. A Check, which covers the browser age check and the returning-user lookup, is €0.02. Take a service with 1 million monthly Windows sessions where 10% return a verified 18-plus signal. Those 100,000 sessions take the cheap path, the other 900,000 run your normal flow, and the OS signal has paid for the integration several times over without ever being load bearing. Rates are on the pricing page.
The free sandbox grants 1,000 Checks and 100 document Verifications as one-time allowances rather than a monthly quota, which is enough to wire the four-branch decision tree and test the declined path properly before it reaches production.
The short version
Windows now has three age APIs. The brackets are under 10, 10 to 12, 13 to 15, 16 to 17 and 18 plus, and they line up with the age bands legislatures have been converging on all year, which is a good reason to stop storing a boolean.
The genuinely new thing is that the signal ships its own provenance. Verified, declared or declined, as a return value. That makes it more honest than the mobile equivalents and more awkward to misuse, which is a feature.
Write the declined branch first. It is a signed-in user who said no, it is neither a pass nor a fail, and whoever tests this feature will click Allow and never see it.
Then look at your coverage rate rather than your accuracy rate. On desktop there is no store chokepoint and the signal comes from a Microsoft account, so for a long time the answer to “how many of our users does this cover” will be the number that decides whether any of this matters.
Xident provides age and identity verification infrastructure that treats OS and store signals as inputs to a layered decision rather than as the decision, and returns age bands with full provenance in a decision record. The free sandbox includes a one-time allowance of 1,000 Checks and 100 document Verifications. Talk to us about using a cheap signal to skip work without pretending it is evidence.
