Age is not a gate. It is a moving number.

Every deployed age system checks a boolean at a boundary and stores the answer. Age is the one human attribute that is guaranteed to change, on a schedule everyone can predict. Treating a moving number as a fixed gate produces both of the failures in this debate: children who are not protected, and young adults who cannot get out.

A boy signs up for a game at eleven. He types his real birthday because he is eleven and it does not occur to him to do otherwise. The game correctly places him in a child account: no direct messages from strangers, no purchases without approval, a restricted friends list. The system worked exactly as designed.

He turns thirteen. Then fourteen. The account does not notice. Two years later he is still in a child account, because the platform recorded a verdict rather than a date, and nothing in the architecture wakes up on a birthday. So he does what every fifteen year old in that position does, which is make a second account with a birth year that gets him what he wants. Now the platform has two records for one human, one of them stale and one of them false, and it believes the false one because it is newer.

Meanwhile his sister, who is nineteen, has spent eight months trying to get out of a teen experience on a different service. She was age estimated at signup, the model guessed low, and the only route out is to upload a government document. She does not have a driving licence, her passport expired, and she is not going to hand her identity papers to a social app to be allowed to see content she is legally entitled to see. So she stays restricted, and the platform records her as a satisfied teen user.

Two people, two opposite failures, one root cause. Neither system is tracking age. Both are storing a verdict about age from a moment that has passed.

What happens to one child's age across five apps?

Follow a single twelve year old across a normal Saturday's worth of accounts and watch the beliefs diverge.

On the game he plays with school friends, he is twelve, correctly, because he signed up honestly at nine and the record has been accurate ever since. On the social app everybody moved to last year, he is fifteen, because the signup form asked for a birth year and fifteen was the number that removed the friction. On a marketplace he used once to buy a hoodie, he is an adult, because the transaction went through on a parent's card and the platform inferred adulthood from the payment. On a chat app he is unknown, because it never asked. On a homework service the school provisioned, he is a student in a specific year group, which is the only one of the five records derived from an authoritative source.

Five services, five different beliefs, one human. None of them is wrong given what it was told. All of them are wrong about the world.

Now add time. He turns thirteen in March. In a coherent system that date would matter: some protections should relax, some new obligations should attach, his parents' consent under the children's privacy regime stops being required in the same form. In the real system, precisely nothing happens on that date at any of the five services. The game keeps treating him as twelve for another two years. The social app keeps treating him as sixteen. The marketplace still thinks he is an adult, and will still think so when he is twenty two.

Regulators, reasonably, hold platforms responsible for what they should have known. Platforms reply that the child gave a false birthdate, which is true and is also not a defence anyone finds satisfying. Both positions are coherent. The argument is unresolvable because the underlying data model cannot represent the thing being argued about.

Why does every age system treat age as a boolean?

Because the regulatory question is phrased as a boolean, and engineers build what the requirement asks for.

The obligations are written as thresholds. Under the children's privacy regime in the United States, the line is thirteen and it triggers a consent requirement. In the United Kingdom, the Online Safety Act's duties around content harmful to children have driven a very large volume of age checks: Ofcom's first statutory report on age assurance, published in 2026, described tens of millions of checks completed across a sample of regulated services in the second half of 2025, an enormous increase on the preceding period (Ofcom). Australia legislated a minimum age for social media accounts. A dozen or more US states have passed their own thresholds, at thirteen, sixteen and eighteen.

Every one of those is a threshold, so every implementation is a threshold check, so every stored result is the output of a threshold check. The information that the person is a specific age on a specific date, which is what would let the answer update itself, is discarded at the moment of evaluation. The industry stores is_adult: true and throws away the only field that would ever have let that value become false again, or become true later for someone it had wrongly marked false.

There is a second reason, and it is a good one: storing a birthdate is a privacy liability. A date of birth is a high value identifier, it is a standard knowledge based authentication answer, and it appears in every identity theft playbook. Teams that decided not to store one were making a defensible choice. The mistake was concluding that the alternative was to store a verdict, when the alternative that actually works is to store neither and carry a proof instead.

What does over-restriction actually cost?

This half of the problem gets almost no attention, so it is worth dwelling on properly.

The public debate about age assurance is conducted almost entirely in terms of failures to protect: a child saw something they should not have seen. That is a real harm and it deserves the attention it gets. But every age system has two error rates, and the second one lands on a group with no lobbying presence whatsoever, which is young adults incorrectly classified as minors.

Face based age estimation is the method being deployed most widely, because it requires no document and takes seconds. Independent evaluation programmes, including work run by the National Institute of Standards and Technology on face analysis technologies, report that estimation error is measured in years rather than months and that accuracy varies across demographic groups (NIST). An error of two or three years is unremarkable for the technique. That is a rounding error for a forty year old and it is the entire question for someone who is seventeen, eighteen, or nineteen.

So a nineteen year old gets estimated at sixteen, and the consequences are not trivial. They lose access to content they are entitled to. In some designs they lose messaging, or monetisation, or the ability to run an account that is their livelihood. The route out is a document check, and the population most likely to be misclassified as young is also the population least likely to hold current government identification, which is a compounding unfairness.

And unlike the under-protection failure, nobody reports this one. A misclassified young adult does not generate a news story or a regulatory inquiry. They generate a support ticket that gets closed, or they generate a false birthdate on a second account, which quietly poisons the platform's data and makes the next classification worse.

What does under-protection look like when the birthday never arrives?

The mirror failure is subtler than the headlines suggest. It is not usually a child defeating a check. It is a check that was correct once and was never revisited.

A verdict recorded at nine is applied at fifteen. A parental consent obtained under the children's privacy regime, which by its terms concerns children under thirteen, sits in a database attached to an account belonging to someone who is now sixteen and whose data is being processed under a legal basis that expired years ago. An account correctly restricted for a twelve year old still carries those restrictions at seventeen, so the young person routes around them, and the platform loses the ability to apply any age appropriate design at all because it no longer knows who it is talking to.

Consent withdrawal has the same shape. A parent removes consent on one service. The other four services in the Saturday list have no idea, because there is no channel through which that decision could reach them. We wrote about why revocation has to be an anchored property rather than a series of unconnected local deletions, and a parent's withdrawal of consent for a child is precisely that problem wearing a different hat.

What is age continuity?

Continuity is the property that lets a system know that the human in front of it now is the same human it dealt with before. We have written about it at length in the workforce context, where verification is a moment and employment is a duration. Childhood is the same shape and more so, because the attribute in question is the one that is guaranteed to change.

Applied to age, continuity means this. A trusted attester establishes the age fact once. That fact is bound to a key held on the young person's own device. From then on, any service that needs to know an age threshold receives two things: the signed attestation, and a fresh signature proving the holder is present right now. The service evaluates the threshold itself, arithmetically, from the attested fact and today's date.

Nothing needs to propagate on a birthday, because nothing was ever stored to become stale. The birthday propagates by subtraction. That is the whole trick, and it is almost embarrassingly simple once you stop storing verdicts.

The attestation looks like this. Note what is not in it: no name, no full date of birth, no document image, no face template.

{
  "typ":      "manav/attestation+v1",
  "sub":      "did:manav:human:2f91c4...7ab",   // the young person's key
  "claim":    { "birth_year": 2011 },            // coarse on purpose
  "attester": "did:manav:school:riverside-usd",  // who established it
  "issued":   "2026-09-19T09:12:44Z",
  "notAfter": "2033-09-19T09:12:44Z"
}

And the service side, which is the part worth reading slowly, because the service never learns a birthdate and never stores an answer:

att = wallet.present("age")                   # carried by the human
ok  = manav.verify(att, published_key)        # offline, no callback
assert ok and att.presence_fresh              # signed here, moments ago

age = current_year() - att.claim.birth_year   # recomputed every time
tier = ("child"  if age < 13 else
        "teen"   if age < 16 else
        "older_teen" if age < 18 else
        "adult")
grant(tier)                                    # nothing persisted

Two design decisions in there are deliberate and worth defending.

Why a birth year and not a birthdate

Because almost no service actually needs the date. A service needs to know which side of a threshold someone is on. A birth year answers that with an ambiguity of at most one year, and it removes the single most useful field an attacker could steal. Where the one year ambiguity matters, and near a threshold it sometimes does, the fix is to attest the threshold crossing dates rather than the birthdate, which is strictly less information again.

The version of this that leaks nothing at all, where the service learns only the predicate over sixteen and cannot correlate the same person across services, requires selective disclosure with zero knowledge predicates. We should be clear: that is roadmap at Manav, not shipped. What ships today is the passkey binding, the on device face match producing a one way key, the presence check and the offline verifiable receipt. The coarse year band is the honest intermediate step, and we would rather describe it accurately than imply a privacy property we have not built yet. We have written separately on what selective disclosure means and where it stands.

Why presence matters more here than anywhere else

A carried attestation with no presence check is a token, and tokens get lent. The specific adversary in this domain is a thirteen year old who wants to be sixteen and who lives in the same house as several people who are. Without a presence check, the older sibling's proof is simply handed over, and the system is worse than a birthdate box because it now attaches false confidence to a lie.

The presence check is what makes the attestation non transferable: the fresh signature has to be produced on the enrolled device by the enrolled human, which for our purposes means an on device face match against a one way key derived at enrollment. No face is stored anywhere. The check answers one question, same human or not, and answers it locally.

How do the age models compare?

The app store row deserves fairness rather than dismissal. Both major mobile platforms have described mechanisms for sharing an age signal with developers, and inside a family account structure they hold something close to authoritative information. For apps installed from those stores on those devices, this is a genuinely good answer and will cover a large share of the problem. It stops at a browser game, a school issued device managed by a district, a console, a connected toy, and any service the child reaches on hardware they do not own. Those gaps are where portable attestations earn their place, alongside the broader question of whether the guardian relationship graph for every child should sit inside two companies by default.

What breaks this?

Four things, and none of them is small.

The first anchor is still hard. Somebody has to establish the age fact once, from a source that actually knows. Schools know, because enrolment records carry it. Paediatric practices know. A guardian who has already been established as a guardian can attest for a young child, which is why this and the parental consent problem are the same problem viewed from two ends. What a signature cannot do is invent the fact. Manav carries and binds the attestation; it does not originate it.

Family device sharing is the norm, not the exception. Exactly the age group in question shares tablets, uses a parent's old phone, borrows a laptop. Naive device binding fails here immediately and would exclude a large number of children from any benefit. This is why the binding has to be to the human through an on device check rather than to the hardware, and it is why any deployment has to assume a shared device rather than treat it as an edge case.

A motivated teenager has physical access. A fifteen year old who wants an adult account, and who has a parent's phone and a parent who will unlock it without reading the prompt, defeats this. Presence checks raise the cost and make the moment visible and deliberate. They do not make it impossible, and anyone claiming otherwise has not met a fifteen year old.

A persistent key for a child is not a free lunch. Giving a young person a durable cryptographic identity that travels between services carries real linkability risk, which is precisely the harm the privacy regime exists to prevent. This is the strongest objection to the whole design and it deserves to be answered rather than waved past. The mitigations are that the key is held by the child and their guardian rather than by any platform, that what is disclosed is a coarse predicate rather than an identifier, that per service key derivation prevents cross service correlation, and that the guardian can revoke. The complete answer requires the selective disclosure work that is, as stated above, not yet shipped.

Designing the moment someone becomes an adult

Here is the part almost nobody has built, and it is the most interesting product idea in this whole area.

Turning eighteen is currently an accident. Nothing happens. If you are lucky, a service eventually re-checks and reclassifies you. More often you make a new account, or you stay restricted, or you were misclassified as an adult years ago and the date passes without meaning.

With a timeline, the transition becomes a designed event that can be scheduled in advance, because unlike almost every other identity event, this one has a known date. The service can prepare: here is what changes about your account next month, here is the data we have been holding under a child specific legal basis and what happens to it, here is your opportunity to export or delete it, here are the protections that will relax and the ones you can choose to keep. Age appropriate design frameworks push in this direction, including the approach taken in the UK children's code, and a timeline is what makes it implementable rather than aspirational.

Most importantly, the young person gets to keep protections they want. Today, the restrictions of a teen account and the protections of a teen account are one bundle, imposed and then removed together. Separating them at a known date, and letting the person choose, treats an eighteenth birthday as the transfer of authority it actually is.

What to do this week

1. Find out what your system stores. Verdict, band, or date. If it stores a verdict, you have no mechanism by which a birthday can ever matter, and you should know that explicitly rather than discover it in an inquiry.
2. Instrument your re-classification rate. How many accounts have ever moved from one age tier to another after signup? At most services the honest answer is close to zero, and that number is the whole argument in one metric.
3. Measure your appeal path. When a user says the age check got it wrong, what happens? How long does it take, what does it demand, and what fraction of appeals succeed? If the only route is a document upload, you are excluding the people most likely to be misclassified.
4. Separate protections from restrictions in your own model. Write down which teen account behaviours protect the user and which merely restrict them. They are almost always implemented as one flag. They should not be.
5. Check what happens to old consents. Find accounts holding a parental consent record where the account holder is now over thirteen. Decide what the legal basis is today. This is the finding most likely to matter.
6. Stop asking for a birthdate you do not need. If your logic only ever evaluates thresholds, collect a year, or collect the threshold answers. Every field you do not hold is a field that cannot be breached or used against your user elsewhere.
7. Design the eighteenth birthday. Even without any new infrastructure, you can build a transition experience for the users whose stated age crosses a threshold. Almost nobody has, which means it is cheap differentiation as well as the right thing.

To see what a presence check that stores no face and requires no signup actually feels like, the walk up demo runs the whole flow in a browser, and the developer documentation covers attestations, presence and offline verification.

Frequently asked questions

How can platforms know a user's age without re-verifying on every app? By accepting a carried age attestation: a signed statement from a trusted attester, bound to the user's own device key, presented together with a fresh presence signature. The receiving service verifies the signature offline and computes the threshold from today's date. No document is re-uploaded and no birthdate needs to be stored by the service.

What is age assurance continuity? It is the property that an age fact established once stays connected to the same human over time, so the answer updates as they get older instead of freezing at the moment of the check. Continuity is what turns age from a verdict stored per platform into an attribute with a timeline that any platform can evaluate.

Do age verification results transfer between apps today? Almost never. Each service performs and stores its own check, which is why an adult may verify their age dozens of times a year and why a child's age is recorded differently on every service they use. Platform level age signals from the mobile app stores transfer within one ecosystem but stop at its boundary.

What stops a teenager borrowing an older sibling's age proof? The presence check. A carried attestation on its own is a bearer token and would be lent immediately. Requiring a fresh signature produced on the enrolled device by the enrolled human, through an on device face match against a one way key, makes the proof non transferable. It does not defeat an adult who actively cooperates.

Why not just store the date of birth? Because a full date of birth is one of the most useful fields an attacker can steal, it is a standard knowledge based authentication answer, and almost no service needs it. Services evaluate thresholds. A birth year, or the threshold crossing dates alone, answers the actual question while holding far less.

Is facial age estimation accurate enough? It is accurate enough for coarse decisions far from a threshold and not accurate enough near one. Published evaluations, including programmes run by NIST, report errors measured in years with variation across demographic groups. That is fine for distinguishing a child from a middle aged adult and inadequate for distinguishing seventeen from eighteen, which is exactly where the legal lines sit.

Does this require giving children a permanent digital identity? It requires a key the child and their guardian control, which is a meaningful commitment and the strongest objection to the design. The mitigations are that the key is not held by any platform, that per service derivation prevents cross service correlation, that what is disclosed is a coarse predicate rather than an identifier, and that a guardian can revoke it. Full unlinkability needs selective disclosure, which is roadmap rather than shipped.

Sources

1. Ofcom, online safety and age assurance reporting under the Online Safety Act: ofcom.org.uk/online-safety
2. Federal Trade Commission, Children's Online Privacy Protection Rule: ftc.gov COPPA rule
3. Information Commissioner's Office, Age Appropriate Design Code: ico.org.uk children's code guidance
4. eSafety Commissioner, Australia, social media minimum age: esafety.gov.au
5. National Institute of Standards and Technology, Face Analysis Technology Evaluation, including age estimation and verification: nist.gov FATE programme
6. European Commission, European Digital Identity Wallet, including age attestation use cases: digital-strategy.ec.europa.eu EUDI wallet
7. Apple developer documentation on declared age range and Google Play policy guidance on age signals: developer.apple.com and Google Play developer help

Every service in this debate is storing a verdict about a number that changes every year, then acting surprised when the verdict is wrong.