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.