Last week Xbox told a group of its users that it had worked out their age without asking them anything.
The reported wording of the email is specific, and worth reading twice: “Due to your longstanding XBOX account activity, we’ve estimated your XBOX profile to be an adult account and updated its age verification status to ‘Verified.’”
Two words in one sentence. Estimated. Verified.
A first wave went out in August 2026. A wider second pass landed around 30 September, with reports from the United Kingdom, Australia, Brazil and Singapore. Microsoft has not published documentation for this route. The official Xbox Wire post from July 2025 lists four ways to prove your age: government-issued ID, age estimation, a mobile provider check and a credit card check. Account history is not one of them.
So account tenure is now an age signal in production, on a console platform, in four countries, with no published criteria and no stated way to reverse it.
Most coverage has framed this as a loophole story, or as good news for players who did not want to upload a passport. It is neither. It is the clearest live example of a failure mode that almost every age assurance programme has and almost none measures, and the failure mode generalises far beyond gaming.
Two signals that look identical and are not
Start with the uncomfortable part, which is that history-based age signals are not automatically junk.
Ofcom’s own guidance lists seven methods capable of being highly effective age assurance: email-based age estimation, open banking, photo ID matching, facial age estimation, mobile network operator checks, credit card checks and digital identity services. Email-based age estimation is on that list. It works by looking at how long and how widely an email address has been used, which sounds a great deal like looking at how long an account has existed.
The difference is where the history lives.
Email-based estimation is accepted because the signal is anchored outside the platform asking the question. The method leans on records held by banks, lenders and other organisations that verified a person at some point, and the vendors build in an anti-spoofing step so you cannot pass by typing in somebody else’s address. Ofcom’s four criteria are that a method be technically accurate, robust, reliable and fair. The anchor is what makes it reliable and the anti-spoofing is what makes it robust.
Account tenure, as deployed, has neither property. The history is yours. You generated it, about an account, and nobody outside your own database ever checked who was holding that account.
That is the whole distinction, and it collapses into one sentence. Account age is not user age. A 2009 account tells you the account is seventeen. It tells you nothing about the person holding the controller tonight.
The error that leaves no trace
Here is the part that matters, and it is not really about Xbox.
Every age decision can be wrong in two directions, and the two directions produce completely different amounts of evidence.
Direction one: you call an adult a child. A 34-year-old gets locked out of voice chat or blocked from an 18-rated purchase. What happens next is loud. A support ticket. An appeal. A one-star review. A post that gets 4,000 upvotes. A spike in your signup abandonment chart. A journalist’s email. We wrote at length about why the adult lockout is the expensive failure, and the reason it is expensive is precisely that it is visible.
Direction two: you call a child an adult. A 14-year-old is handed an adult status flag and full access.
Now count the complaints. The minor does not complain, because the outcome is the one they wanted. The parent does not complain, because the parent does not know the field exists. Your support queue stays quiet. Your appeal volume stays at zero. Your abandonment rate improves, because nobody abandoned anything. No journalist writes about a teenager who got into a chat feature without friction.
Read your own dashboard after shipping a tenure grant and this is what you see: coverage close to 100 percent, appeal volume zero, support contacts zero, drop-off zero, unit cost zero. It is the best performing age assurance method you have ever deployed, by every number you collect.
Every one of those numbers is measuring the error direction tenure does not make.
This is worse than an unmeasured risk. It is a metric set that actively rewards the dangerous direction. If your age assurance review is driven by support volume and conversion, as most are, then the method with the worst false adult rate will win the review, every quarter, forever.
And it breaks the one metric we have been telling people to collect. Appeal reversal rate is the sharpest signal that a threshold is set wrong, because it counts the times a human looked at a refusal and disagreed with the machine. Note the word refusal. You can only reverse a decision somebody contested. Nobody contests being promoted. For tenure-based adult grants, appeal reversal rate is structurally blind, and it will read 0.0% on a method that is wrong about a million people.
Where the false adults actually come from
“A minor with a seventeen-year-old account” sounds like a rounding error until you name the populations.
The inherited family account. One Xbox in the living room, bought in 2011 by a father, used by three children since. On a console the account is attached to a device as much as to a person, which is why we spent a whole post on binding a check to the right human. Tenure measures the household, not the player.
The handed-down account. An older sibling leaves home and the account stays. The gamertag has fourteen years of history and a twelve-year-old behind it.
The lie that aged well. A child typed a false date of birth in 2016 and has been playing ever since. Ten years of clean activity now reads as evidence of adulthood. Nothing about the person was ever checked.
The bought account. We covered the resale market for verified accounts earlier this year. Tenure-based adult grants make that market better, not worse, because an old account now carries an adult flag as a bundled feature. Price goes up accordingly.
Not one of those four is exotic. Three of them describe ordinary family life.
Tenure launders a self-declaration
Look at where the tenure clock started.
It started on the day somebody created the account and typed a date of birth into a form. Nobody checked that date. It was a self-declaration, which is the method the ICO already fined a platform for relying on.
Years pass. The declaration does not get better. No new information about the person enters the system. Then the tenure rule runs, and the unchecked declaration comes out the other side written into a field that says “Verified”.
That is the actual mechanism, and it is a laundering step. The input is a self-declaration that regulators have ruled insufficient. The output is a status that looks, to every downstream system, exactly like a document check.
Worth saying plainly: a date of birth on a consumer account is one of the easiest fields in the world to edit. Treating duration-since-an-editable-field as proof of anything requires a confidence nobody has earned.
What tenure can honestly give you
Tenure is not nothing. It gives you a lower bound on age, and you can write it down:
minimum possible age today = minimum age allowed at account creation
+ years since account creationRun it. Your terms of service floor is 13. The account was created in 2012, fourteen years ago. The minimum possible age today is 27, which clears an 18 gate with room to spare.
That looks like a proof, and for about ten seconds it is a satisfying one. Then notice which term is doing the work. The floor of 13 is not a measured fact about this user. It is a rule you wrote in your terms of service and enforced with a dropdown.
So the inequality inherits the weakness of the thing it rests on. Tenure gives you a real lower bound on age if, and only if, the age floor at creation was actually enforced. It was not. It was typed.
That is the honest summary of the method. Tenure is a sound deduction from a premise you never verified.
This is a back-book cost decision, not an engineering opinion
Nobody ships this because they think it is rigorous. They ship it because of arithmetic.
Ofcom’s statutory report in July 2026 recorded more than 69 million age checks in the second half of 2025, a 23-fold increase, and the share of children meeting a highly effective check rising from 25% to 43% between July 2025 and January 2026. Good numbers, and they came from the front door: new signups, one check each, at the moment a user is already motivated.
The back book is a different problem. A platform with 40 million existing accounts and a new duty does not have 40 million motivated users. It has 40 million people who already had access yesterday, most of whom will not complete a verification flow they did not ask for, many of whom will quietly stop using the product instead. Xbox itself said unverified UK users keep playing but lose social features beyond their friends list, which is the polite version of the same squeeze.
Set against that, tenure costs nothing, converts at 100%, annoys nobody and closes the coverage gap on a slide this week.
We are not going to pretend that pressure is imaginary. It is the single strongest force in age assurance right now, and it is why this signal will spread from consoles to social, marketplaces and storefronts over the next two quarters. The question is not whether teams will use history-based signals. They will. The question is what the record says afterwards, and what the signal is allowed to unlock.
The data model is where this becomes unfixable
A boolean cannot hold the difference between an estimate and a verification.
If your schema has age_verified: true, then the tenure grant and the government ID check are the same value in the same column, and every consumer downstream reads them identically. Your chat service, your store, your ad stack and your transparency report all see true. Three months later nobody can answer “how many of your verified adults were verified by a document” without archaeology, and that is a question regulators now ask directly.
We argued this from a different direction when the EU KIDS Act arrived and a yes-or-no field stopped being enough to answer the question. Tenure makes the same point from inside your own codebase.
What the record needs instead, per decision:
| Field | Example | Why it has to be separate |
|---|---|---|
method |
account_tenure_inference |
The name of what you did, not the name of the outcome |
assurance_level |
inferred / estimated / verified |
So one query separates the populations |
signal |
account_created_2011-04-18 |
The actual input, recoverable later |
threshold |
tenure >= 10y |
What rule was running when this ran |
confidence |
n/a for deterministic rules |
Say n/a rather than inventing a number |
policy_version |
tenure-v2 2026-09-28 |
So “what was running in September” is a query |
timestamp |
ISO 8601, with timezone | Obvious, and frequently missing |
reversible |
true |
Because you will need to undo a batch of these |
Then make the gates read the level, not the boolean. An inferred adult and a document-verified adult should not be able to reach the same surfaces.
One more thing about the field name, and it is not a pedantic point. Writing the word “Verified” into a status field, and telling the user in the same sentence that you estimated it, is a claim about your own system. Texas showed what that costs when the description of the protection became the violation, independent of how the protection performed. A transparency notice does the same thing from the other end: it collects your description of your systems under penalty and measures you against it later. “Estimated, status Verified” is a sentence that reads differently in an enforcement letter than it did in a product review.
If you are going to use a history signal, do these seven things
Pragmatically, because some of you will ship this next month whatever we write.
- Make it a triage input, not a terminal decision. A history signal is a reasonable way to decide who gets a cheap check and who gets a full one. It is not an outcome. This is what a layered waterfall is for, and tenure fits the first layer well.
- Require a second, externally anchored signal before granting adult status. Payment history in a name, a carrier check, an open banking confirmation, or a document check from any point in the past. One signal you generated about yourself is not corroboration.
- Cap what an inferred adult can reach. Chat with existing friends, yes. An 18-rated purchase or an unrestricted stranger-contact surface, no. Write the cap in the gate, not in a doc.
- Force a measurement sample. This is the important one. Route a random slice of tenure-eligible accounts through a real check and compare the answers. That comparison is the only way you will ever obtain a false adult rate, because the population will not report itself. On Growth, a Check is €0.02, so a 10,000-account sample costs €200. There is no budget argument against €200, which means a decision not to measure is a decision not to know.
- Build the reversal path before you need it. You will eventually have to downgrade a cohort of these grants. Do it carefully, because an age sweep has no undo button and a mass downgrade of real adults is the loud failure again.
- Give the user a way to say no. “We decided you are an adult, here is how to tell us you are not” is a one-line addition that produces the only inbound signal this method can generate.
- Write the sentence you would send a regulator. One paragraph: the signal, the threshold, what it unlocks, what it does not, how you sampled it and what the sample found. If you cannot write it today, you have found the gap, and you found it before somebody with statutory powers did.
The honest limits
Microsoft has published nothing about how these grants are calculated. Everything above about Xbox comes from the emails users received and from press reporting of the two waves. We do not know the tenure threshold, whether other signals are combined, how many accounts were affected, whether the status can be reversed, or whether it applies outside the four countries reported. If Microsoft publishes the criteria, read those instead of this post.
No regulator has ruled on account tenure as an age signal, as far as we can find. Ofcom’s “serious doubts” about age inference, published in its July 2026 statutory report, were aimed at behavioural inference in general, with the warning that such systems “may fail to identify significant numbers of children”. That is directionally relevant and it is not a ruling. Ofcom owes Parliament a rapid assessment of what counts as highly effective for establishing whether a user is over 16, due in October 2026, which may address history-based signals directly.
We also cannot give you a false adult rate for tenure, and we are not going to estimate one. No published trial measures it. That absence is the argument of this post, not a hole in it. It also connects to a harder problem we have written about before: you cannot ethically test an age gate on children, so the forced-sample comparison in step 4 is a workaround, not a solution.
None of this is legal advice.
How Xident fits
Assurance level is a first-class field, not a comment. Every Xident decision records method, outcome, threshold, confidence, policy version and timestamp. That means “how many of my verified adults were verified by a document” is a query against your own data instead of a quarter of reconstruction work.
Policy versions are recorded, so a rule change is visible after the fact. When you tighten a tenure threshold, records written before and after say which rule was running. That is what lets you answer a question about September in October.
A Check is cheap enough to make the measurement sample unavoidable. On Growth a Check is €0.02 and a document Verification is €0.20. The forced-sample comparison that gives you a real false adult rate is the difference between €200 and €2,000 for 10,000 accounts, and that gap is usually what decides whether a team measures or assumes. Rates are on the pricing page.
Records survive, images do not. Document images are deleted within 24 hours of processing. What remains is the decision, which is the part a regulator asks for and the part that does not become a breach disclosure later.
The free sandbox is enough to run the comparison before you commit. It grants 1,000 Checks and 100 document Verifications as one-time allowances rather than a monthly quota, which covers a first sample of your own tenured population.
The short version
Account tenure measures how long an account has existed. It does not measure the person using it, and the clock it reads started with a date of birth nobody checked.
The reason it spreads anyway is not that anyone believes in it. It is that its errors are silent. An adult wrongly called a child complains in five places. A child wrongly called an adult complains nowhere, so coverage goes up, appeals stay at zero and the method wins the quarterly review.
If you ship a history signal, make it a triage input rather than an answer, require a second signal that you did not generate yourself, cap what it unlocks, and force a measurement sample so the false adult rate becomes a number instead of a silence.
And do not write “Verified” into a field you estimated. That word is not a label. It is a claim, and somebody will read it back to you.
