Windows Age API capabilities are now broadly available to Windows Insiders, Microsoft said on September 8, giving eligible applications limited signals about a signed-in user’s age range or verification status without returning a full date of birth. The company says a wider Windows rollout will follow, while one classification function remains planned for a future update.
- Windows can return one of five age bands: under 10, 10–12, 13–15, 16–17 or 18 and older.
- A separate call can indicate whether age has been verified.
- Apps must be registered for the digital-safety capability; Microsoft says users retain consent and platform controls.
- The architecture reduces repeated birthday sharing but centralizes important trust decisions in the operating system and Microsoft account.
The concise answer: the Windows Age API is a privacy-minimizing signal service, not proof that every user is the age recorded on an account. It can help apps avoid collecting birthdays, but developers must still decide when a declared range is sufficient, when stronger verification is necessary and how to handle missing or disputed signals.
How the Windows Age API works
Microsoft’s model starts with the consumer’s Microsoft account. Windows uses account context to determine whether the user is a child, teen or adult, whether parental consent applies and whether a separate age-verification process has been completed. An eligible app asks Windows for only the signal needed for its experience.
GetUserAgeRangeAsync returns a band rather than an exact age. GetAgeVerificationStatusAsync returns the verification state for cases where self-reporting is not enough. CheckAgeStatusAsync is designed to classify a user as a child, minor or adult under global and regional rules, but Microsoft says that function will arrive in a future update.
| Function | What it returns | Status described by Microsoft |
|---|---|---|
| GetUserAgeRangeAsync | One of five age brackets | Broadly available to Insiders |
| GetAgeVerificationStatusAsync | Whether age has been verified | Available through Windows Age APIs |
| CheckAgeStatusAsync | Child, minor or adult classification | Future update |
| Microsoft Age Verification | Reusable account verification status | Storefront use in Singapore, Brazil and Australia |
Why a bracket can be safer than a birthday
Many apps need to know whether a user falls below a legal or product threshold, but they do not need the person’s exact birth date. Returning a bracket reduces the amount of personally identifiable information copied into many developer databases. A breach at one app would therefore expose less precise age information.
Centralization can also make controls more consistent. A parent does not have to discover a separate age setting in every program, and an app can adapt content or features using a platform signal. TechRepublic and Biometric Update both emphasized that the design follows an operating-system-level model already pursued by other platforms.
That is data minimization, not anonymity. The app still learns a sensitive category and may combine it with account, device or behavioral data. Developers should log the minimum necessary information, avoid keeping the signal longer than needed and explain what changes when a user falls into a particular band.
Declared age and verified age are different
An account birthday can be inaccurate because a user mistyped it, chose a convenient value or inherited an old family setup. A declared range is useful for low-risk personalization, but it may not satisfy a high-risk legal requirement. Microsoft’s separate verification-status call acknowledges that distinction.
Microsoft Age Verification is intended to let a person verify once and reuse the status across Microsoft experiences. The company says storefront verification is already available in Singapore, Brazil and Australia, with more regions and scenarios to come as regulation expands. Microsoft did not present the September announcement as a universal identity check for every Windows user.
What developers need to decide
An app should first document why it needs age information. If the purpose is to simplify a child interface, a broad range may be enough. If the app controls access to regulated content, a developer may need a higher-confidence signal, additional consent or a jurisdiction-specific process.
Developers also need a fallback. A device may use a local account, the signal may be unavailable, a user may deny consent or the API may not yet be present. Treating every missing response as adulthood would defeat the safeguard; treating every missing response as childhood could unnecessarily block legitimate users.
The correct behavior depends on the risk. The application should disclose that behavior, offer correction and appeal paths, and avoid dark patterns that pressure users to reveal more information than the feature needs.
Parents gain consistency, but should keep visibility
Microsoft is pairing the API work with changes to how parental controls appear during device setup and with improvements to Family Safety approvals, activity reporting and wallet balances. The platform approach is meant to make protections follow a child’s account across Windows experiences.
Parents still need to understand which applications requested an age signal and what each app did with it. A useful control panel would show access history, let a family revoke permission and explain whether the result came from a declared birthday or stronger verification. Microsoft’s announcement describes consent and platform controls, but does not publish that complete audit experience.
The policy context raises the stakes
Age assurance is moving from individual websites into operating systems and app stores as governments impose more duties around children and restricted content. Biometric Update noted that industry groups disagree over whether declared age ranges should count as age assurance or be governed primarily as parental-control tools.
That distinction matters because a low-friction signal can be valuable without being conclusive. Regulators should avoid treating an operating-system bracket as infallible, while platforms should not market data minimization as proof that no privacy risk remains.
How this connects to AI products
Microsoft specifically points to AI as an emerging category where age-appropriate safeguards matter. An assistant can change its content boundaries, explain features differently or require a parent before enabling certain actions. The signal can support those choices, but it does not test whether the model’s behavior is actually safe.
Our report on Google’s agentic AI threat findings shows why identity and permissions must be treated as operational controls. An age signal is another permission input, and it needs logging, limits and abuse testing. The US AI distillation advisory similarly illustrates that technical controls must be paired with clear governance rather than trusted in isolation.
Questions that remain unanswered
Microsoft has not yet detailed the all-user rollout date, every eligibility rule for apps or the final interface for reviewing signal access. It also has not explained how conflicts between account age, parental settings and third-party verification will be resolved in every jurisdiction.
Independent testing should examine false classifications, account-recovery edge cases, shared devices and accessibility. Researchers should also test whether applications can infer narrower age information by combining the bracket with other signals.
The best measure of success is not how many apps call the API. It is whether children receive more appropriate experiences with less personal data collected, while adults retain meaningful control and users can correct mistakes.
Security and abuse cases deserve separate testing
An attacker may try to create an adult account for a child, reuse a verified session on a shared PC or persuade an app to accept a stale cached result. Those problems are not unique to Microsoft, but moving the signal into the operating system makes its lifecycle a security boundary. Developers should define when a result expires and when a fresh check is required.
Malware on the device is another concern. An app should not assume that receiving an age band authorizes every action associated with that age. Sensitive changes may still need account authentication, parental approval or an independent policy decision. The API should be one input in a defense-in-depth design.
Microsoft can support trust by publishing threat models, compatibility guidance and a clear response process for developers who discover inconsistent results. External researchers should be able to test the interface without exposing real minors’ data.
Accessibility and household realities
Shared devices complicate a model built around a signed-in account. Families may hand a laptop between adults and children, schools may use managed logins and some users may rely on assistive technologies that interact differently with consent dialogs. A safe implementation must avoid locking people out because a verification step is inaccessible.
Apps should provide plain-language explanations and keyboard, screen-reader and low-vision support for every age-related prompt. Parents need a route to correct a child’s information, while adults incorrectly classified as minors need an appeal that does not force unnecessary document collection.
A checklist before relying on the signal
Product teams should record the feature being gated, the minimum signal needed, the jurisdictions involved and the consequence of a false result. Privacy teams should review storage and retention. Security teams should test shared-device, account-recovery and replay scenarios. Support teams need scripts for users who cannot complete verification.
Finally, the organization should revisit the decision when Microsoft changes availability or regional rules. A platform API can simplify compliance plumbing, but it cannot transfer legal responsibility from the application operator to Microsoft.
Frequently asked questions
Does Windows send apps my exact birthday?
Microsoft says the API returns a limited age bracket or verification status, not a full date of birth.
Is the Windows Age API available to everyone?
Microsoft says the APIs are broadly available to Windows Insiders and will come to all Windows users later; CheckAgeStatusAsync is planned for a future update.
Can any app request the signal?
Microsoft’s developer documentation describes registration for a digital-safety capability, with consent and platform controls. Developers should verify the current eligibility requirements before shipping.
Does an age bracket prove a user’s identity?
No. A bracket communicates account-based age context. Higher-risk uses may require a verified status or another lawful assurance step.
Get the day’s top stories in your inbox
One concise email. No spam, unsubscribe anytime.
