The practical change is still substantial. Windows apps can request one of five coarse ranges—under 10, 10–12, 13–15, 16–17, or 18+—along with a separate status of verified, unverified, opted out, temporarily unavailable, or not applicable. Microsoft’s documentation says applications receive neither a date of birth nor an exact age. They do, however, gain a standard operating-system route to act on age across Windows rather than asking each user independently.
PCMag correctly identifies a broader shift: age checks are moving down the technology stack, from individual websites and storefronts toward the OS account that sits beneath them. The important qualification is that Windows is building the plumbing now, while state laws and individual services will determine where that plumbing must be used—and what happens to people who decline verification.
What Windows 11 actually exposes to apps
Microsoft’s September 8 Windows Experience Blog announcement calls the feature the Windows Age API. Its developer documentation identifies two core methods: GetUserAgeRangeAsync, which returns a bracket, and GetAgeVerificationStatusAsync, which returns the assurance state. A third method, CheckAgeStatusAsync, is planned for a future update and is intended to classify someone as a child, minor, or adult using regional policies.
The API is not a passive data feed open to any process on a PC. Microsoft says an application must declare the userAccountInformation capability, and the user must consent to account-information access through Windows privacy settings. If consent is not granted, the call can fail with an access-denied error. The documentation also tells developers to implement fallback behavior whenever no signal is returned.
That last point deserves more attention than Microsoft’s family-safety messaging gives it. A missing signal does not mean “adult,” and Microsoft explicitly warns developers not to interpret a null result as any specific age group. A properly built application must decide whether it offers a limited experience, requests age another way, or denies a regulated feature. The hard policy choice therefore moves from a web form into an app’s business rules.
The new APIs are broadly available to Insiders beginning with Windows 11 build 26220.9472, according to Microsoft Learn. The underlying UserAgeVerificationStatus API contract is documented for Windows 11 version 24H2, though the company still labels parts of the developer surface as prerelease. Administrators can set a default age group or verification status through Group Policy or mobile-device management, in which case Windows returns the policy-defined value rather than an account-derived signal.
For IT departments, that makes this less of a consumer-only feature than it first appears. A managed Windows fleet can have an administrative default for applications that call the API, but Microsoft’s documentation does not explain the intended enterprise scenarios, the precise policy names, or whether the control will be shipped in ordinary ADMX templates before the APIs reach general availability. It also does not explain how third-party apps should distinguish a status supplied by organizational policy from one backed by an account-verification process.
Microsoft accounts are the hinge—and local accounts are outside it
The feature is fundamentally tied to a Microsoft account. Microsoft’s developer guidance says identity-provider age signals are currently retrieved only for Microsoft accounts. When a device is used with a local account, Active Directory account, or another account type, Windows returns no age range and reports the verification state as not applicable unless an administrator has configured a default.
That is a concrete constraint on the idea that Windows itself is becoming an identity checkpoint. A local-account user is not, based on the currently published API behavior, compelled by Windows to upload a driver’s license or submit a selfie merely to obtain an age bracket. The app receives no account-derived result and must follow its fallback path.
Microsoft’s new age-verification system, Microsoft Age Verification or MAV, sits alongside the API. Once an account has a verified state, Microsoft says the status can be reused across Microsoft experiences, Windows devices, and applications. Its support documentation confirms the verification can be performed through facial age estimation from a selfie, an uploaded document, or a government-account login where supported.
The “verify once, use everywhere” pitch reduces repeat requests for users, but it creates a more consequential account attribute. Microsoft says apps get the verified status rather than the underlying ID, selfie, or birth date. Still, a verified adult signal can shape access to mature content, social functions, purchases, communications, and AI features across multiple applications attached to the same Microsoft account. The operating system is being positioned as a broker of that result.
Microsoft already offers account age verification in Australia, Brazil, Singapore, and the United Kingdom. The company had previously described Singapore’s methods in March: Singpass, a selfie-based facial age estimate, or an official ID such as a national ID card, driver’s license, passport, or residence permit. Microsoft Support now lists the same general options, while noting that choices vary by country and verification partner.
What Microsoft has not published is a full data-retention explanation for every verification partner, a list of the apps that will request verified status at launch, or a commitment that an unverified Windows user will retain equivalent access to all nonregulated services. Users should not assume that “unverified” means “blocked,” but neither should they assume it will remain a neutral setting once regulated apps begin consuming the signal.
Three state laws make an OS age signal useful
PCMag’s central legal point holds up: California, Colorado, and Illinois have enacted laws that require operating-system or device-account providers to collect age-related information and provide a bracketed signal through an API in specified circumstances. But the calendar matters.
California’s Digital Age Assurance Act becomes operative on January 1, 2027. California’s Attorney General described the requirement in proposed regulations as a digital signal from an operating-system provider to application developers. The statute’s model is age categorization at account setup and signal sharing—not a universal government-ID requirement.
Colorado’s SB26-051, the Age Attestation on Computing Devices Act, is later. Colorado’s legislative record says operating-system providers must collect a birth date, age, or age bracket during account setup and offer an accessible interface for older devices. Its main obligations begin in 2028, with preexisting-device interfaces required before January 1, 2029.
Illinois Public Act 104-0664, the Children’s Social Media Safety Act, likewise requires a covered manufacturer to offer an account-setup interface by January 1, 2028. Its provisions focus on giving covered social-media operators an age-bracket signal for a device’s primary user, with the operator expected to treat a received under-18 signal as authoritative for that device.
Those distinctions puncture the most sweeping interpretation of this week’s Windows announcement. The statutes are primarily age-attestation frameworks: they require a person to indicate age, birth date, or both, then require a platform-safe signal rather than indiscriminate sharing of a birth date. They restrict unnecessary transmission of the data. They do not, on their face, tell Microsoft that every California, Colorado, or Illinois Windows user must furnish a driver’s license or face scan at setup.
Verification becomes more likely when a service needs higher confidence than self-reported data can provide, or when another jurisdiction requires it for a particular class of content or transaction. Microsoft itself says MAV is for cases in which high confidence is necessary to meet local legal requirements. That is a meaningful escalation, but it is different from Windows demanding ID as a general condition of sign-in.
The near-term issue is app behavior, not the setup screen
For Windows enthusiasts and administrators, the immediate task is to watch which software adopts the API and how it behaves when a signal is unavailable. Microsoft’s published examples include user-generated content, social features, communication tools, in-app purchases, virtual currencies, and media with maturity ratings. Those categories cover a large share of the Microsoft Store and could eventually touch software distributed outside it as developers seek a common compliance mechanism.
Developers should not build around a simplistic “verified equals allowed” rule. Microsoft’s own API documentation requires handling all status values, including temporary service failures and user opt-outs. An app that treats a transient outage as proof that a user is underage will create avoidable lockouts; one that treats every unavailable result as adult will defeat the regulatory purpose the API is meant to serve.
Organizations using Windows 11 should inventory consumer-facing Store apps and internally developed Windows applications that have youth-safety, age-gated commerce, social, or AI features. Developers should determine whether the userAccountInformation capability is justified, describe its use plainly to users, and test local-account, Entra ID, policy-managed, opted-out, and unavailable-signal paths before relying on Microsoft account data.
Microsoft has built a technical answer to laws that are about to demand one. The company has not announced a date for general Windows 11 availability, a mandatory ID check for Windows sign-in, or a universal restriction on local accounts. What it has announced is more durable: an API that lets age classification and account verification become reusable properties of a Windows identity.