Age Assurance Accuracy Standards: The 2026 Benchmarks Explained
Age assurance is the practice of establishing that a user falls inside or outside an age band without necessarily establishing who they are. Until August 2026 it had no widely applied numeric standard. A landmark US settlement changed that by attaching measurable accuracy targets, third-party testing and independent audit to a platform's age controls, and by doing so without requiring users to hand over government identity documents.
For any platform operating an age gate, this is the moment age assurance stopped being a policy statement and became a measurable engineering requirement.
Key takeaways
- Age assurance now carries published accuracy targets: a 10% under-18 false-positive ceiling for ages 16-17 and 3% for ages 13-15, to be met within a year.
- Compliance is verified by annual third-party testing and an external auditor, not by self-attestation.
- The framework explicitly does not require government ID or other sensitive personal information.
- Under-13 detection and removal carry their own audited targets.
- The direction of travel is toward age proof that is accurate, repeatable and privacy-preserving at the same time.
What an accuracy target actually measures
Age assurance methods, whether facial age estimation, behavioural signals, account-history inference or a verified credential, all produce classification errors. Two error types matter:
| Error type | What it means | Who it harms |
|---|---|---|
| False positive (under-18 passed as adult) | A minor is admitted to an adult experience | The minor, and the platform's regulatory exposure |
| False negative (adult blocked as minor) | An eligible adult is locked out | Conversion, revenue, user trust |
The new benchmarks target the first category, and they are tighter for younger cohorts. A 3% ceiling for 13-15 year olds against a 10% ceiling for 16-17 year olds reflects a simple reality: estimation error grows as the subject's apparent age approaches the threshold, and the harm of a miss is greater the younger the child.
This is the part that has been missing from the age verification debate for years. "We use age assurance" was an unfalsifiable claim. "Our method holds under-18 false positives below 3% for 13-15 year olds, verified annually by an independent tester" is a claim that can be measured, audited and enforced.
Why the no-government-ID condition matters most
The most consequential clause is the one that receives the least attention. The framework requires accuracy improvements while ruling out demands for government identification or other sensitive information.
That combination is the hard problem. It is straightforward to build an accurate age gate if you are willing to collect a passport scan from every user. It is straightforward to build a privacy-preserving age gate if you are willing to accept a self-declared birthday. Holding both at once, high accuracy and minimal data collection, is the constraint that defines the next generation of age assurance.
Three approaches satisfy that constraint:
- On-device facial age estimation. The image is processed locally, an age band is returned, the image is discarded. Accuracy is measurable; the biometric never leaves the device.
- Verified age credentials. A trusted issuer confirms a date of birth once. The user then presents a reusable credential asserting "over 18" without revealing the underlying date, document or issuer file.
- Zero-knowledge age proofs. A cryptographic proof establishes that a hidden birthdate satisfies a threshold. The verifying platform learns the answer and nothing else.
The second and third approaches share an important property: the accuracy of the assertion is inherited from the original verification event, not re-estimated at every login. A credential issued after a document check does not degrade over time the way an estimation model does at the margins.
What platforms should do now
Instrument before you optimise. Most platforms cannot currently state their own under-18 false-positive rate by age cohort. That number is now the unit of compliance. Build the measurement before you change the method.
Separate the age question from the identity question. Age assurance failures often start as architecture failures: the age gate is bolted onto a KYC flow, so the only tool available is a document check, so every age decision collects far more data than it needs. Splitting the two lets you apply a proportionate method to each.
Plan for annual external testing. If the benchmark is audited yearly, the method has to be reproducible yearly. Vendor-supplied accuracy claims that cannot be independently reproduced on your own population are not evidence.
Assume the numbers will tighten. A 10% and 3% pair of ceilings is a floor, not a destination. Design for headroom.
How this connects to reusable identity
The structural inefficiency in age assurance today is repetition. A user proves their age to a marketplace, then again to a game, then again to a streaming service, then again to a ticketing platform. Every repetition is a new collection event, a new retention obligation, a new breach surface and a new opportunity for a false positive.
AIR Identity treats the verification as the durable asset. A partner that has already established a user's age can issue a reusable credential; other partners in the network confirm the age band through a zero-knowledge proof without receiving the birthdate, the document or any raw personal data. The accuracy of the assertion is set once, at issuance, under controlled conditions, rather than re-estimated in the wild at every gate.
For platforms in gaming, communities and fandom and regulated commerce, this changes the economics of age compliance: the cost of accuracy is paid once and amortised across the network, instead of being paid again at every front door.
Frequently asked questions
What is the difference between age verification and age assurance?
Age verification establishes a specific date of birth, usually from an identity document. Age assurance is broader: it establishes with defined confidence that a user sits inside or outside an age band, using any method from document checks to facial age estimation to verified credentials. Age assurance is the category; age verification is one method within it.
What is a good false-positive rate for age assurance?
The benchmarks now in circulation set an under-18 false-positive ceiling of 10% for 16-17 year olds and 3% for 13-15 year olds. Treat these as the compliance floor rather than the target, and measure your own rate per cohort rather than relying on a vendor's published figure.
Does age assurance require collecting government ID?
No. The 2026 benchmarks were deliberately written to be achievable without government identification or other sensitive information. On-device facial age estimation, reusable verified credentials and zero-knowledge age proofs all meet the accuracy requirement without a document upload at the point of use.
How does zero-knowledge age proof work?
A trusted issuer verifies a user's date of birth once and issues a cryptographic credential. When a platform asks "is this user over 18," the user's wallet generates a proof that the hidden birthdate satisfies the condition. The platform receives a verifiable true or false. It never receives the birthdate, the document or the identity of the issuer's underlying record.
Who is responsible for age assurance accuracy, the platform or the vendor?
The platform. Regulatory obligations and settlement terms attach to the operator of the service, not to the supplier of the method. Vendor accuracy claims are inputs to your compliance case; they are not a substitute for measuring performance on your own user population.
Related reading
- Under-16 social media bans: the 2026 age verification map
- Government digital credentials in 2026
- Why biometrics alone are no longer enough
More from AIR: AIR Identity, industry solutions, or browse the full AIR blog.
Building an age gate that has to be accurate and privacy-preserving at the same time? See how AIR Identity issues and verifies reusable age credentials, or read the developer documentation.




.png)