How do you verify age without collecting an ID?

On a Friday evening in the summer of 2025, two people in Britain hit the same age gate on the same website. One was thirty four. One was fifteen. Ninety seconds later both of them were past it. The only difference was that one of them uploaded a passport first.

That sentence is the whole problem, and it is worth sitting with before we reach for any technology.

The thirty four year old did what the law intended. He photographed the identity page of his passport, held his phone up to his face while a progress ring completed, waited for a vendor he had never heard of to say yes, and went on with his evening. He is now a row in a database somewhere. He does not know which database, or which company operates it, or how long the row will live, or what happens to it when that company is acquired or breached. He accepted all of that in exchange for permission to look at something entirely legal.

The fifteen year old did not bother. She had already read the thread. She installed a VPN, chose an exit node in a country with no such requirement, reloaded the page, and the gate was gone. Total elapsed time was under two minutes, and the app was free.

Consider what the system actually achieved. It collected a passport image from an adult who posed no risk to anyone, and it collected nothing at all from the child it was written to protect. It converted a question with a one bit answer, is this person old enough, into a permanent store of identity documents. Then it left the front door open.

This is not an argument that age assurance is pointless. It is an argument that the current implementation of it is close to the worst available trade, and that the reason is a design choice almost nobody has questioned: the check verifies a document, at a site, in a session. It does not verify a human, once, in a way that human can carry.

What actually happened when the UK switched on age checks?

Britain ran the largest live experiment in age assurance that has ever been attempted, and the results are unusually well documented, because the regulator was required to report on them.

The age assurance duties in the Online Safety Act took effect on 25 July 2025. Services likely to be accessed by children, and services hosting pornography, had to put what the Act calls highly effective age assurance between users and certain content. Ofcom, the regulator, published its first statutory report on how that was going under section 157 of the Act in July 2026.

The headline number is genuinely large. Across a sample of thirty two regulated pornography, dating and social media services, more than sixty nine million age checks were completed in the second half of 2025. Ofcom put that at roughly a twenty three fold increase on the preceding six months. Whatever else you conclude, the industry did comply at scale and at speed. Engineering teams shipped, vendors were integrated, and tens of millions of checks ran.

The second number arrived the same week the rules did. Proton, which operates Proton VPN, reported that UK sign ups on 25 July 2025 rose by more than fourteen hundred percent on an hourly basis. Reporting through August 2025 described UK VPN downloads passing two million for the month, and a sharp rise in online discussion of bypass techniques, with one widely cited figure putting the increase in relevant Reddit comment volume at around four hundred and sixty percent. Treat the precise percentages as indicative rather than exact, because they come from company blog posts and press coverage rather than audited data. The direction is not in dispute. A meaningful share of the population responded to the gate by routing around it, and the tool they needed cost nothing and took two minutes to install.

The uncomfortable arithmetic

Put the two figures side by side and the shape of the problem appears. Sixty nine million checks were completed. Millions of VPN installs happened in the same window. The checks fell disproportionately on people who were willing to comply, which correlates strongly with being an adult with a document, a stable address, and no particular reason to hide. The evasion fell disproportionately on people motivated to evade, which includes precisely the minors the rules exist to protect.

A control that is easy for the compliant and easy for the motivated to bypass is not a control. It is a tax on good faith.

Why does an age check turn into a data breach?

Here is the part that should worry any engineer who has ever been on call for a data store they did not design.

To answer over eighteen, yes or no, the dominant method asks for a government identity document and a selfie. That means somebody, somewhere, now holds a photograph of a passport or driving licence together with a face image, linked to an account on a service whose subject matter may be extremely sensitive. The question was one bit. The artifact retained is a dossier.

In October 2025 Discord said that a third party service used to handle age verification appeals had been compromised, and that a number of government identity photographs belonging to users were exposed. Reporting at the time put the figure at roughly seventy thousand images. Discord's own account and subsequent coverage differ in emphasis, so treat the exact count as approximate, but the shape is clear: the images existed, they were held by a vendor in the verification chain rather than by the platform, and they left.

Earlier the same year, in July 2025, the Tea app suffered an exposure that included verification selfies and identity documents. The detail that made it notable was the gap between the retention policy users had been shown and the data that turned out to still be there. Again, verify the specifics before you cite them in a board paper, because the initial reporting and the company's statements did not perfectly agree. And again, the structural lesson survives any dispute about the numbers.

The liability you cannot delete

The reason these incidents matter more than an average credential breach is that identity documents do not rotate. If a password leaks you change it in ten seconds. If a session token leaks it expires. If a photograph of your passport leaks alongside the name of an adult content site, you cannot revoke your face, you cannot reissue your date of birth, and the association between the two is permanent.

Every organisation that stands up an age gate is therefore accepting a liability with no expiry date, in exchange for answering a question that required one bit. It is the data protection equivalent of taking out a mortgage to buy a sandwich.

Regulators have noticed the tension. When the US Federal Trade Commission issued a policy statement on 25 February 2026 relating to the Children's Online Privacy Protection Act, part of its purpose was to reassure operators that collecting information solely to determine a user's age would not itself trigger the enforcement the rule is designed for. That is a regulator explicitly trying to unblock age checking by promising not to punish the data collection it requires. It is a sensible accommodation. It is also an admission that the standard method creates a data problem serious enough to need one.

For context on the wider COPPA picture, the amended rule reached full compliance on 22 April 2026 and recognises eight approved methods of obtaining verifiable parental consent. We look at the parental consent side of this separately, because it is a different problem with a different shape.

What is the difference between identification, estimation, and attribute proof?

Most of the confusion in this debate comes from three genuinely different operations being described with one word. Separating them is the single most useful thing you can do before choosing a method.

Identification asks who are you

This is the document upload path. The user proves a specific legal identity: a name, a date of birth, a document number, usually a face match to bind the document to the person holding it. The output is a strong claim about a specific individual, and the by-product is a rich identity record.

It is worth being fair here: identification is genuinely accurate, and for some purposes, opening a bank account, for example, it is exactly right. Its problem in the age context is that it is enormously more powerful than the question being asked, and power you do not need is liability you keep.

Estimation asks how old do you look

Facial age estimation takes a selfie and returns a predicted age, usually with a confidence band. Good implementations never store the image, process on device or delete immediately, and return only a decision.

This deserves real credit, and it does not always get it. Estimation collects vastly less than document upload. A well built estimation flow can genuinely answer the question without retaining anything, and the better vendors have invested seriously in that property. If your only choice is between uploading a passport and a selfie that is deleted in the same request, the selfie is the better trade.

Its limitation is statistical rather than moral. Estimation produces a distribution, not a fact. Around a threshold of eighteen the error band is measured in years, which is why the operational practice is to set the challenge age higher, commonly at twenty five, and route anyone below it to a fallback. That fallback is usually document upload. So estimation reduces how often you need the dossier, which is a real gain, but for the population closest to the threshold, which is exactly the population the rule targets, it tends to hand the problem back to identification. Accuracy also varies across demographic groups, which turns a technical error band into a fairness question about who gets asked for a passport more often.

Attribute proof asks one question and returns one bit

The third operation is the one the debate keeps skipping. An attribute proof asserts a predicate about a person without revealing the underlying data or the person's identity. Over eighteen: true. Nothing else.

The reason this feels exotic is that we rarely encounter it outside cryptography, but the everyday version is familiar. When a bouncer glances at a wristband, they are checking an attribute, not an identity. Somebody at the door did the identity work once, bound the result to a physical token, and now every bar inside the venue can act on one bit without seeing anybody's licence. The wristband model is strictly better than carding at every bar, provided two things hold: the issuer is trusted, and the band cannot be slipped off and passed to someone else.

Those two conditions are the entire engineering problem, and we will take them in order.

Why does the same adult verify their age fifty times a year?

Because the check does not travel, and because nobody in the value chain benefits from it travelling.

Every verification is scoped to one site, often to one session. Change device, clear cookies, or visit a different service in the same category, and the same adult repeats the same procedure with the same documents for a different vendor, who starts a new record. The industry's own term for the alternative, reusable age verification, exists precisely because the default is not reusable.

This is the failure we call trust islands: a verification result that cannot leave the institution that produced it. It is the same structural problem that makes you re-do identity checks at every bank, re-upload the same documents to every marketplace, and re-establish the same facts about yourself endlessly across systems that could in principle have accepted a proof. We catalogue it alongside thirteen other structural failures in the Identity Failure Map.

There is also an incentive worth naming plainly, without accusing anyone of bad faith. Age assurance vendors are generally paid per check. A reusable proof reduces the number of checks. This does not make vendors villains, and several of them have shipped genuinely privacy preserving products, but it does mean the commercial gravity of the sector points away from portability. When you are evaluating why an obvious improvement has not happened, following the invoice is usually more explanatory than assuming incompetence.

How can a website verify age without collecting ID?

Split the problem into two jobs that are usually mashed together, and it becomes tractable.

Job one, done once: establish the fact. Somebody who is competent to know a person's age asserts it. That could be a bank that already ran identity checks, a mobile network operator with a contract holder on file, a government wallet under eIDAS, a mobile driving licence following ISO 18013-5 which carries purpose built attributes of the form age_over_NN, or a conventional identity verification vendor doing exactly what it does today. This step involves real identity data, and it happens at one organisation that is already regulated to hold it.

Job two, done many times: present the fact. Everywhere else, the person presents a receipt of that assertion, cryptographically bound to a key on their device, together with a fresh signature made at the moment of presentation. The relying site verifies two things offline: that a trusted issuer signed the assertion, and that the person holding the device signed this presentation now.

The site never sees a document. It never sees a face. It never sees a name. It sees a signature it can check against a published key, and a predicate that is true.

What the presentation actually contains

Concretely, the artifact a site receives looks like this. The issuer block was signed once, potentially years ago. The presentation block is signed at the moment of the check.

{
  "attestation": {
    "predicate":   "age_over_18",
    "value":       true,
    "issuer":      "did:web:issuer.example-bank.com",
    "issued_at":   "2026-02-14T09:22:31Z",
    "expires_at":  "2027-02-14T00:00:00Z",
    "subject_key": "z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP"
  },
  "presentation": {
    "audience":    "example-service.co.uk",
    "nonce":       "9f2c14a7e0b83d51",
    "signed_at":   "2026-09-07T20:14:02Z",
    "presence":    "device_signature_with_liveness"
  },
  "signatures": {
    "issuer":  "ed25519:3QK8...c41a",
    "subject": "ed25519:9dA2...77f0"
  }
}

Read what is absent. There is no date of birth, because the predicate already answers the only question asked. There is no name, no document number, no image. The subject_key is a public key, not a person. If this record leaked in its entirety, an attacker would learn that some key holder is an adult, which is a fact about roughly five billion people.

What the site does with it

Verification is local. No callback to the issuer, no callback to us, no dependency on anyone's uptime at the moment a user is trying to get through a gate.

ok = verify_ed25519(att.issuer_sig, canonical(att), key_of(att.issuer))
     and att.predicate == "age_over_18" and att.value is True
     and now() < att.expires_at
     and att.issuer in accepted_issuers

fresh = verify_ed25519(pres.subject_sig, canonical(pres), att.subject_key)
        and pres.audience == my_domain
        and pres.nonce == nonce_i_just_issued
        and now() - pres.signed_at < 120

admit = ok and fresh

Four lines of policy and two signature checks. The nonce binding is what stops a captured presentation being replayed at another site or on another day, and the audience field is what stops a proof gathered by one service being forwarded to a different one.

What stops a teenager borrowing an adult's proof?

This is the right question, and it is the one that kills most reusable credential designs. If an age proof is just a file, it is a wristband you can slip off and hand across the fence.

The answer is that the presentation must be signed at the moment of use by the person the attestation was issued to, and that signature has to be difficult to make on someone else's behalf. In practice that means the private key lives in device hardware, the signature is unlocked by a live biometric gesture on that device, and the flow includes a liveness challenge that a photograph or a recording cannot satisfy.

Return to the analogy and make it precise. A wristband alone is transferable. A wristband plus a glance at the person wearing it is not, which is why venues do both. What the device signature provides is the glance, performed by hardware, without any picture being stored or transmitted anywhere. On our own how to prove you are human flow the face match happens on the device and only a one way key ever leaves it, which means there is no template to breach.

Honest about the residual: a parent who unlocks their own phone and hands it to their child has defeated this, and nothing in cryptography prevents a person from voluntarily helping someone else. What the design does is convert a silent, scalable bypass, sharing a file or a login, into an active, per session, in person act by a specific adult. That is a large reduction, not an elimination, and anyone selling it as elimination is overselling.

How do the methods actually compare?

The table below is the artifact worth taking into a procurement meeting. The columns that matter are not accuracy claims, they are what the method retains and what a breach of it would expose.

Two rows in that table are doing something categorically different from the others. Government wallet attestations and portable receipts both separate the identity work from the presentation, and both therefore let a site act on one bit. The difference is coverage. Wallet schemes are excellent within their jurisdiction and for people who hold the underlying documents, and the EU Digital Identity Wallet timetable makes them a serious part of the picture by the end of 2026. They are less helpful for people outside the scheme, people without documents, and services that need to accept users from many countries at once. We have written separately about where eIDAS fits, and the honest summary is that these approaches compose rather than compete: a wallet is an excellent issuer, and the presentation layer needs to work across all of them.

What is on the roadmap versus what is shipped?

A section that most vendor writing omits, and the one that should determine whether you believe the rest.

Shipped and working today: enrolment that binds a person to a device key with an on device face match, where only a one way key leaves the device and no biometric template is stored anywhere. Fresh presence signatures with liveness. Receipts that verify offline against a published Ed25519 key. An embeddable widget that gates access on a presence proof.

Not shipped, and argued for rather than sold: full selective disclosure using SD-JWT, and zero knowledge range proofs that would let a holder prove over eighteen from an underlying date of birth without the issuer learning where the proof was used. Those are the right long term shape, they are on the roadmap, and they are not in production here today. Anyone who tells you their zero knowledge age proof is deployed at scale should be asked for the verifier, the circuit, and the audit. If you want the background on why these primitives matter, we have written up selective disclosure and zero knowledge proofs for it.

What is somebody else's job: the original age determination. We are not an age estimation engine and have no plans to become one. Somebody with the evidence, a bank, an operator, a wallet, an identity verification provider, makes that call once. The contribution here is carrying it and proving the carrier is present.

What does this approach not fix?

Six limits, stated plainly, because a method that claims no limits is a method nobody should deploy.

• Somebody still has to know the age once. This removes repeated identity collection. It does not conjure the original fact. If a person has no bank, no phone contract, no wallet and no document, the first attestation is still hard, and that population is real.
• A determined user still reaches a VPN. Nothing described here makes evasion harder. It makes compliance cheap enough that fewer people bother evading, which is a different and more achievable goal.
• Linkability needs deliberate design. If a receipt is presented unchanged everywhere, it becomes a tracking identifier across sites. Avoiding that requires per audience derivation or blinded presentation, and getting it wrong builds the surveillance system this is supposed to prevent.
• An adult can still assist a minor in person. Discussed above. Reduced, not eliminated.
• Issuer trust is a policy problem, not a cryptographic one. A site has to decide whose attestations it accepts, and there is currently no universal registry. This is the same problem certificate authorities have, with the same failure modes.
• Adoption is the actual bottleneck. A portable proof is worth exactly as much as the number of sites that accept it. On day one that number is small, which is the unglamorous reason good designs lose to bad ones.

The part of this debate that is not about technology

It would be dishonest to write four thousand words on age assurance and pretend the disagreement is technical.

People evade age checks for several reasons, and only some of them are the reason the rules exist. Some are minors doing what minors have always done. Some are adults who object on principle to identifying themselves to visit a legal website. Some are people for whom the association between their legal identity and their reading, viewing, or community membership carries genuine risk, in a country or a household or a workplace where it would be used against them. That last group is small and the consequences for them are severe, and the standard method treats them identically to everybody else.

Technology can resolve one part of this cleanly. It can remove the data liability, so that verifying your age does not create a permanent record of who you are and where you went. It can make the check portable, so complying once is not a commitment to comply endlessly. Those are real gains and they are available now.

What technology cannot do is settle whether a particular check should exist, where a threshold belongs, or how to weigh a child's safety against an adult's privacy. Those are political questions and they will be decided politically. The most useful thing engineers can contribute is to stop making the trade worse than it needs to be, so that the political argument is about the policy rather than about the collateral damage from a poor implementation.

What to do this week

Concrete, in rough order of value per hour spent.

1. Find out what your verification vendor actually retains, in writing. Not the marketing page, the data processing agreement. Ask specifically: is the document image stored, where, for how long, and what happens on appeal, since appeals flows are where images tend to persist.
2. Map your own copies. Many teams believe the vendor holds everything, and then discover images cached in support tooling, in an object store from a migration, or in logs. Grep for it.
3. Separate the decision from the evidence. Store the outcome, over eighteen true, with a timestamp and an issuer reference. Do not store the evidence that produced it. This one change removes most of your breach exposure and is usually a small piece of work.
4. Set and document a real retention period, then verify deletion actually happens by trying to retrieve a record that should be gone.
5. Instrument abandonment at the gate. Measure how many users drop at each step. That number is your evasion rate, and if you are not measuring it you are managing the wrong thing.
6. Ask your vendor about reusable proofs and portability, and note whether the answer is technical or commercial. It is a useful diagnostic.
7. Write down your issuer acceptance policy before you need it. Which wallets, which operators, which providers do you trust, and who decides.
8. Try a presence based gate on a low risk surface to see the flow end to end from a user's side. Our walk up demo runs with no signup, and the integration docs show what the verification call looks like.

Frequently asked questions

How can a website verify age without collecting ID? By accepting a portable age receipt. A trusted issuer confirms the person is over the threshold once and signs an attestation bound to that person's device key. At every site afterwards, the person presents the attestation with a fresh device signature proving they are present. The site verifies both signatures offline and learns only one bit.

Why do age verification laws drive VPN use? Because the cost of complying is high and personal, uploading an identity document to an unfamiliar vendor, while the cost of evading is a free app and two minutes. When the UK duties took effect on 25 July 2025, Proton reported UK VPN sign ups rising more than fourteen hundred percent hourly. People are not primarily objecting to the age limit. They are objecting to the identity collection.

Is it safe to upload my ID for age verification? It carries real risk, and the risk is permanent. Discord disclosed in October 2025 that identity photographs held by a vendor in its age verification appeals process were exposed, and the Tea app exposure in July 2025 included verification images. Passwords rotate, passports do not. Prefer methods that retain nothing, and ask what the appeals path does.

What is reusable age verification? Verifying age once with a trusted issuer and then presenting a portable proof of that result at many sites, instead of repeating the check everywhere. It reduces the number of organisations holding identity data and lowers the cost per check. It requires binding the proof to the holder so it cannot be lent to someone under the threshold.

Does facial age estimation avoid the privacy problem? Partly, and it deserves credit for that. A well built estimation flow can decide without retaining an image. Its limit is statistical: near a threshold of eighteen the error band spans years, so services set a higher challenge age and route everyone below it to document upload. For the population closest to the threshold, estimation often hands the problem back to identification.

Can a child just borrow an adult's age proof? Not silently. The proof only verifies when presented with a fresh signature from the device it was issued to, unlocked by a live gesture, so a copied file is worthless. An adult who unlocks their own phone and hands it over in person can still help, which the design reduces rather than eliminates by making it an active per session act rather than a one time share.

How does this relate to the EU Digital Identity Wallet? It composes with it. Wallet schemes under eIDAS are excellent issuers of age attributes, and mobile driving licences under ISO 18013-5 already define age_over_NN attributes for exactly this. What is still needed is a presentation layer that works across schemes, for users outside any one jurisdiction, and a presence check so an issued attribute cannot simply be passed along.

Sources

1. Ofcom, protection of children and age assurance under the Online Safety Act, including the first statutory report published July 2026: ofcom.org.uk
2. UK Online Safety Act 2023, full text and commencement of age assurance duties on 25 July 2025: legislation.gov.uk
3. Proton, company blog reporting UK VPN sign up surge following 25 July 2025: proton.me/blog
4. Discord, company blog and security disclosures relating to the October 2025 third party age verification vendor incident: discord.com/blog
5. US Federal Trade Commission, Children's Privacy and COPPA guidance, including the amended rule and the February 2026 policy statement: ftc.gov
6. ISO/IEC 18013-5, personal identification, mobile driving licence application, which defines age_over_NN attributes: iso.org
7. European Commission, EU Digital Identity Wallet policy and timetable: digital-strategy.ec.europa.eu
8. W3C, Digital Credentials API specification: w3.org

The question was one bit. Stop answering it with a passport.