Microsoft’s documentation says the APIs are published ahead of availability and are not yet enabled at runtime. As of September 4, 2026, developers calling them receive an unknown age range and an unavailable verification result. Microsoft says the feature is planned to be switched on in a future release later in 2026, but has not named a Windows build, update, or release channel.
That makes this more than a curiosity for developers. It is an early look at how Windows could become a privacy-conscious intermediary between an account-level age signal and software that needs to make age-sensitive decisions. It may reduce the number of apps that ask users to repeatedly submit birth dates or go through separate verification flows. But its real privacy and usability impact will depend on details Microsoft has not yet publicly explained: which apps can enroll, where the system will work, how an account’s status is established, and what apps may do after receiving a signal.
What Windows will return — and what it will not
The planned age-range API uses five broad categories:
- Under 10
- 10 through 12
- 13 through 15
- 16 through 17
- 18 and over
An application therefore gets a category rather than a precise number. It is not given the user’s date of birth, exact age, or family relationship details through this interface.
Those bands are detailed enough to support common policy breakpoints. An app can distinguish a child under 13 from a teenager, and a teenager from an adult, without receiving a birthday that can be retained and reused. Microsoft’s split between under-10 and 10-to-12 also offers more granularity than the familiar under-13 threshold.
That does not mean an age band is meaningless from a privacy perspective. A category can still influence which features, content, or purchases an app makes available. The important design choice is data minimization: the app can make an age-based decision without needing the underlying identity data that produced the result.
The documentation describes a separate API, GetAgeVerificationStatusAsync, for a different issue: whether an identity provider has independently verified the person’s age. Its possible responses are:
- Verified
- Unverified
- OptedOut
- TemporarilyUnavailable
- NotApplicable
Keeping the range and verification result separate is one of the most consequential parts of the design. An 18-and-over range is not, by itself, the same thing as a verified-adult finding. Conversely, a service receiving an Unverified result should not treat that as proof that a user is underage; it means independent verification has not been established through this signal.
The temporary-unavailability result matters as well. It indicates that apps need a fallback path, rather than assuming the operating system will always produce a usable answer. Microsoft explicitly advises developers to retain their normal behavior or existing age gate until the platform becomes available.
It is not an open query service for every app
One concern prompted by the phrase “Windows tells apps your age” is that any installed program could silently inspect an age profile. Microsoft’s documentation does not describe that model.
The Digital Safety platform validates the identity of the application making the request before returning meaningful values. Microsoft says applications must be properly registered and identified with the platform. This gating is a significant safeguard in principle: it places an access-control layer between account-derived signals and software that wants to use them.
However, several consequential details remain unknown. Microsoft has not publicly set out the enrollment process, vetting standards, geographic coverage, policy requirements, or enforcement model for third-party developers seeking Digital Safety registration. It has also not said what retention, sharing, secondary-use, advertising, or profiling restrictions may apply after an app receives an age signal.
Those omissions mean it is too early to conclude that the system will resolve the privacy debate around age assurance. Limiting an API to broad bands is protective, but a robust privacy model also needs clear limits on which apps can access the data and how they can use the answer. Those questions will matter particularly if the API becomes useful for services with large audiences or sensitive content.
Technical requirements narrow the first audience
The initial documented surface is not a universal Windows programming interface. Microsoft lists the following requirements:
- Windows 11
- A signed-in user session using a Microsoft account
- A Win32 COM interface for C/C++ applications
- Application identity established through the Digital Safety platform
The Win32 COM requirement is particularly notable. It indicates a native desktop-oriented integration path, rather than a simple capability that every web page, script, or cross-platform app automatically inherits. A browser-based service, for example, would not obtain this signal merely because the customer visits it from a Windows PC; its Windows-side application would need to meet Microsoft’s identity and platform requirements.
The Microsoft-account requirement also creates a practical boundary for households and managed devices. A local Windows account is not listed as supported. Neither is a generic statement that any work or school identity can participate. The documentation specifically identifies a Microsoft-account user session, so users should not assume this feature will apply across every sign-in arrangement on a Windows device.
Microsoft’s reference material is labeled prerelease and says it may change substantially before release. Developers should consequently avoid treating today’s enumeration names and integration assumptions as a final contract. Most importantly, they should not ship a workflow that expects useful production results before Microsoft enables the service.
What the feature could change for Windows users
If Microsoft enables the APIs as documented, users may encounter fewer repetitive age prompts in participating software. Instead of handing every individual app a birth date, a user could receive a service that checks whether the account falls within the appropriate age bracket and, separately, whether an age-verification status exists.
For a parent or guardian, the potential benefit is that a content app may need less personal information to decide whether an adult-only area should be available. For an adult user, a verified status could eventually remove some repeated friction across participating applications. For developers, it offers a possible common signal in place of building and maintaining multiple incompatible age-gate systems.
But users should not expect a single Windows setting that instantly proves adulthood everywhere. The platform is not active yet, applies only under documented account and app conditions, and does not make the underlying online service free of responsibility for its own compliance decisions. A service may still require its own checks, particularly when its rules call for a particular assurance method or when a Windows signal is unavailable.
The OptedOut status adds an additional unanswered consumer question. Microsoft has documented the value but has not explained the circumstances in which it appears, how a user opts out, or what the associated Windows experience looks like. Until that is clarified, users should avoid assuming that an opt-out will be universally available, or that it will have the same consequences in every app.
A regulatory backdrop, not a proven causal story
Age assurance has become a major public-policy subject, but the available records do not establish that Microsoft created these particular APIs at the direction of any named regulator or law. It is more accurate to say the Windows design arrives amid a broader move toward age-aware online services.
In the United Kingdom, Ofcom describes age assurance as a cornerstone of the Online Safety Act. For covered publishers of pornography, highly effective age assurance is required before access to pornographic content unless a user has been determined to be an adult. Ofcom also makes clear that the underlying provider remains responsible even where system-level measures are involved.
Crucially, age assurance should not be reduced to a simple checkbox. Ofcom identifies self-declaration as not capable of being highly effective for an 18 threshold. At the same time, it recognizes several approaches that can potentially meet a highly effective standard, including credit-card checks, digital identity services, facial age estimation, and photo-ID matching. The policy issue is therefore not whether every method is useless, but what level of reliability and privacy is appropriate for the particular risk.
The European Commission has likewise developed an age-verification blueprint designed to let someone prove that they are over a chosen threshold without revealing their exact age or identity. That approach aligns with the broad principle behind Microsoft’s planned bands: disclose the minimum information needed to make an eligibility decision.
Microsoft’s documented bands also overlap with age thresholds described in California’s age-bracket framework: under 13, 13 to under 16, 16 to under 18, and 18 or older. The Windows API is more granular below age 13, separating under-10 from ages 10 through 12, while its 13-to-15, 16-to-17, and 18-plus categories align with the later threshold boundaries. Still, no reviewed record says that Microsoft designed this implementation to meet that framework or any other named legal mandate.
The key test will be implementation, not documentation
The architecture is promising in a limited sense. A broad age band plus a distinct verification-state signal is a cleaner data model than routinely distributing exact birth dates to every service. Application-identity validation could also prevent the interface from becoming a free-for-all data source.
Yet the product is not available at runtime, the documentation remains prerelease, and the hard governance questions are unsettled. How an account obtains a verified status, how errors are corrected, what recourse users have when a result is wrong, which developers qualify, and how app recipients are restricted will determine whether the system earns trust.
For now, Windows users do not need to change a setting or submit new information because of these APIs. Developers should regard the current documentation as an opportunity to plan fallback behavior and age-sensitive product design—not as authorization to remove existing age gates. When Microsoft activates the feature, the most useful question will not be whether Windows can tell an app “how old you are.” It will be whether Windows can help an app make a necessary age decision while disclosing as little about the person as possible.
Update: Teams Free emerges as an early age-verification use case (September 4, 2026)
Neowin reports that Microsoft has published a Teams Free support page describing feature restrictions for users in certain regions who do not complete age verification through their Microsoft account. This provides the first concrete example of how Microsoft’s broader Windows age-signal work may affect a consumer application.
According to the report, affected Teams Free users can continue using the service without completing verification, but may lose access to meeting and call recording, Copilot and other AI features, and Communities until their status is resolved. Microsoft reportedly says account updates after verification can take up to 24 hours.
The Teams guidance also describes additional protections for minors. Children with the required parental consent can use Teams Free, but are less discoverable by default: other users ordinarily cannot search for them using an email address or phone number. Communities are unavailable to minors entirely.
This does not mean the Windows 11 APIs are live. Rather, Teams appears to be a product-level example of the age-sensitive access model Microsoft is preparing, with regional requirements and account verification determining which features remain available.
Update: Windows Age APIs reportedly reach Windows Insiders alongside faster family approvals (September 9, 2026)
Windows Central reports that Microsoft has begun making its Windows Age APIs available to Windows Insiders, a change that would supersede the earlier documented runtime-unavailable state. If confirmed through Microsoft’s rollout documentation, participating Insider builds could return usable age-awareness signals before the platform reaches general Windows 11 availability.
The report also describes broader Family Safety changes. Microsoft has reportedly accelerated parental approvals for requests such as extra screen time, app access, and purchases, while improving family-group management and visibility into web activity, app activity, and spending.
For parents and administrators, the immediate practical change is reduced delay when approving legitimate child-account requests. For developers, Insider availability would create the first opportunity to test age-aware application behavior against a live Windows implementation, though production apps should still retain fallbacks until Microsoft confirms general availability, supported builds, regions, and enrollment rules.
Update: Insider builds add specific Family Safety reliability fixes (September 9, 2026)
Neowin reports that the Family Safety changes are included in Windows 11 Insider build 26340.9354 for version 26H2 and build 28120.2912 for version 26H1, both described as experimental releases.
Beyond faster approval handling, the update reportedly expands Activity Report coverage for applications that previously were not consistently included. Microsoft has also addressed cases in which Family Safety funding balances did not refresh correctly, reducing confusion around money available for child-account purchases.
The changes further streamline adding, removing, and managing family-group members. For Windows households testing these Insider builds, the practical effect is a more dependable parental-control workflow rather than a new age-verification capability: approval requests, activity reporting, and family funds should better reflect current account activity.
Update: Microsoft officially confirms Windows Age APIs are broadly available to Insiders (September 9, 2026)
Microsoft’s Windows Blog now confirms that the Windows Age APIs are broadly available to Windows Insiders, replacing the earlier report-based indication that the capability had reached experimental builds. Microsoft says availability for all Windows users is coming “soon,” though it still has not identified a specific public Windows 11 build, release channel, or date.
The company also clarifies that the current API set includes age-range and age-verification-status calls, while a third method, CheckAgeStatusAsync, will arrive in a future update. That forthcoming API is intended to provide child, minor, or adult classification globally and according to regional policies.
Microsoft further says its Microsoft Age Verification system is already used in Storefronts in Singapore, Brazil, and Australia. Verified status is stored with the Microsoft account and can be exposed to developers through the Windows Age APIs, potentially allowing participating apps to rely on a single account-level verification outcome rather than requiring repeated checks.
Update: Microsoft reportedly requires Copilot sign-in and limits access for children under 13 (September 11, 2026)
Türkiye Today reports that Microsoft has made sign-in mandatory for Copilot and is restricting access for children under 13, or above that threshold where local law requires it, under a new Safe Participation Framework announced September 10.
The move is a concrete product-policy application of age-differentiated experiences, rather than an expansion of what the Windows Age APIs disclose. According to Türkiye Today, Microsoft says the framework also includes safety-by-design reviews, measures intended to reduce harmful-content exposure, self-harm crisis-resource prompts, healthier-use reminders, and safeguards against misleading AI outputs.
For Windows users and IT administrators, the immediate impact is likely to be most visible in Copilot access: anonymous use is no longer the intended path, and younger users may receive restricted or unavailable experiences based on account age and regional rules. It also reinforces that the age APIs are part of a wider Microsoft account-based safety strategy, not a standalone mechanism that automatically unlocks every age-sensitive service.
Update: Additional details (September 14, 2026)
According to PCWorld, Microsoft’s account-level age-verification process can involve facial age estimation from a selfie, an identity-document upload, or—where supported—sign-in through a government digital-identity system such as Singapore’s Singpass. The report says Microsoft identifies Yoti and Verifymy as verification partners.
These details concern how a Microsoft account may obtain the verified status exposed through the Windows Age APIs; they do not change the APIs’ limited output model. Participating apps receive an age range and verification status, not the uploaded document, selfie, or an exact date of birth.
Update: Additional details (September 16, 2026)
Microsoft’s developer documentation identifies Windows 11 build 26220.9472 as the starting point for broad Insider availability. Apps must declare the userAccountInformation capability and obtain the user’s Windows privacy consent for account-information access; without it, requests can return an access-denied error.
The documentation also says administrators can set default age-group or verification-status values through Group Policy or mobile-device management. Local, Active Directory, and other non-Microsoft-account sessions otherwise return no account-derived age range and a NotApplicable verification status.