Age Verification Guide: Methods, Laws and How to Choose an Age Assurance Provider

Age verification, age estimation and self-declaration: what regulators mean

Three different things get called an "age check", and regulators treat them very differently.

• Self-declaration is a date-of-birth field or an "I am over 18" tickbox. It costs nothing and proves nothing, and it is the baseline that most age laws were written to replace.
• Age verification establishes a date of birth, or an over/under-threshold fact, from an authoritative source: an identity document, a government or commercial database, or a digital ID.
• Age estimation infers an age range from a signal, most often a face image. It returns a probability, not a fact.

Age assurance is the umbrella term that covers all of these plus inference methods that work from account or behavioural signals. When a law asks for "reasonable steps" or "highly effective" age assurance, it is describing an outcome, not naming a technology. That is why a single method rarely satisfies every market you operate in, and why this guide is organised around the decision (which method, in which market, with what fallback) rather than around vendors.

Age verification methods compared

The table is qualitative on purpose. Accuracy, drop-off and cost depend on the vendor, the document mix and your audience, so test any method on your own traffic before you commit to it.

No row wins on every column. Strong certainty costs friction, low friction costs certainty, and the privacy-friendliest options depend on an ecosystem (wallets, trusted issuers) that is still uneven across countries.

Why the threshold matters more than the average

Vendors quote an average error for estimation. The number that matters to you is the error for people close to the legal age, because those are exactly the users you most need to classify correctly. A model that is accurate on average can still be wrong about whether a 16-year-old is 18.

The practical pattern is a challenge age. If the legal limit is 18, set the estimation pass mark well above it, and send everyone estimated near or below that mark to a stronger method such as an ID check. You trade a little friction for a minority of users against a much lower chance of letting an underage user through. The same logic works as a waterfall: start with the lightest method that is acceptable in the market, and step up only when the result is uncertain.

What the law requires by market

Rules in this area are moving quickly. Treat the summaries below as orientation, confirm current dates and guidance with the regulator or legal counsel before you build, and note that this is information, not legal advice.

Australia: social media minimum age

The Online Safety Amendment (Social Media Minimum Age) Act 2024 sets a minimum age of 16 for holding an account on age-restricted social media platforms. The obligation sits with the platforms, not with children or parents, and it came into effect on 10 December 2025. Platforms must take reasonable steps to prevent under-16s from holding accounts, and the eSafety Commissioner enforces it, with civil penalties of up to A$49.5 million.

In November 2025 eSafety told nine services (Facebook, Instagram, Snapchat, Threads, TikTok, X, YouTube, Kick and Reddit) that it considered them age-restricted platforms, and it named others it considered out of scope, such as Discord, GitHub, Roblox, WhatsApp and Messenger. eSafety has said there will not be a static list: platforms are expected to keep assessing whether they meet the definition, particularly when they add features or their main use changes. The law does not prescribe a single technology, so "reasonable steps" is judged on the approach you take and how well it works. eSafety's announcement is the primary source for these points.

United Kingdom: Online Safety Act

Under the Online Safety Act 2023, Ofcom expects "highly effective age assurance" from services that allow pornography and from services in scope of its children's protection codes, which took effect in July 2025. Ofcom's guidance says a method must be technically accurate, robust, reliable and fair. It lists methods it considers capable of meeting the bar, including photo-ID matching, facial age estimation, open banking, mobile network operator checks, credit card checks and digital identity services, and it does not accept self-declaration. That list is not exhaustive, so what counts is whether your implementation performs, not whether the method is on the list.

United States: a patchwork

There is no single federal age verification law for general websites. Instead, a growing number of states require age verification for adult content and, in some states, for social media or app access, and several of those laws are in litigation. Separately, the Children's Online Privacy Protection Rule, enforced by the Federal Trade Commission, restricts collecting personal information from children under 13 without verifiable parental consent. If you serve US users, map your exposure state by state and expect the picture to change.

European Union

The Digital Services Act requires online platforms accessible to minors to ensure a high level of privacy, safety and security for them. The European Commission has issued guidelines on protecting minors under that Act and has been piloting a privacy-preserving age verification app, while some member states have their own age rules for specific content. For EU-facing services, the practical question is which of those expectations apply to your product category and which methods your data protection authority will accept.

Matching the method to the use case

The right method depends less on the technology than on the harm you are preventing and the penalty for getting it wrong. A rough way to decide:

Two principles hold across the table. Check at the point of risk rather than at the front door when the product allows it, because it keeps friction away from users who never reach the restricted feature. And make the first method the lightest one the law and your risk appetite accept, with a documented step-up for everyone it cannot confidently classify.

Where age checks go wrong

Most failures are not in the model; they are in the flow around it.

• One-and-done at sign-up. A check passed once says little about who is using the account months later. Decide whether the law or your risk requires re-checks, for example before payouts or when a device or location changes sharply.
• No path for false rejects. Every method wrongly rejects some adults. Without a quick appeal route (another method, a human review), legitimate users leave and support costs rise.
• Treating the pass mark as a constant. The right estimation pass mark can differ by market, content type and regulator expectation. Make it configuration, not code.
• Ignoring presentation and injection attacks. Photos of photos, screen replays, face-swap deepfakes and virtual-camera injection are used to defeat selfie checks. Liveness and injection detection matter as much as the age model. See how forged IDs are detected for the document side of the same problem.
• Borrowed documents. A genuine document from an older sibling or parent passes authentication. Tying the live selfie to the document photo is what closes that gap.
• Keeping everything "just in case". Retained images and documents become a breach target and a privacy liability. Keep the result and the audit trail, not the evidence, unless the law requires otherwise.

Measuring and evidencing performance

Regulators asking whether you took "reasonable steps" or delivered "highly effective" assurance are really asking whether you can show it works. Build the evidence as you go:

• Funnel metrics: start rate, completion rate, time to complete, and drop-off by device and country, so you can see where friction costs you users.
• Outcome metrics: pass, fail and step-up rates per method, and how many users were rejected and then passed a second method (a proxy for false rejects).
• Accuracy testing: periodically test with known-age samples, including people close to the threshold, rather than relying only on vendor-published figures.
• Audit trail: for each user, the method used, the date, the result and the configuration version in force at the time.
• Change log: when you change a threshold or method, record why and what happened to pass rates afterwards.

This record is also the fastest way to answer a regulator's inquiry, and it makes vendor comparisons far more honest than a sales demo.

How an ID plus liveness age check works with ScreenlyyID

The highest-certainty route in the table is a document check with a liveness selfie, which is what ScreenlyyID's identity verification flow does. In an age check the sequence looks like this:

1. The user captures their identity document in your app or on the web.
2. Document authentication checks that the document is genuine and unaltered, and the date of birth is read from it.
3. A liveness selfie confirms a real person is present, and a face match ties that person to the photo on the document.
4. Your system compares the verified date of birth against the threshold for that market and records only the outcome you need.

Where the user has no suitable document, a data-source match through electronic identity verification can confirm a date of birth without a camera, which suits markets with good data coverage. Because the date of birth comes from a verified source rather than from a model, the result is a fact you can defend, rather than a probability you have to explain.

Privacy-preserving design

Age checks collect sensitive data to answer a narrow question, and regulators increasingly ask whether you collected more than you needed. Design for the narrowest answer:

• Store the result, not the evidence. Keep "over 18, verified on this date, by this method" and delete the document image and selfie as soon as the check completes, unless a law requires retention.
• Separate the check from the account. Where possible, make the verification result a token that does not carry name or address into your marketing or analytics systems.
• Use the lightest method that meets the law. Estimation with a challenge age may be enough for some content; an ID check should be the fallback, not the default.
• Offer an alternative. Not everyone has a document or is comfortable with face-based methods, so give users a second route.
• Document your choices. Keep a short record of the methods you chose, the thresholds, and why, so you can answer a regulator or a data protection assessment.

Checklist: choosing an age assurance provider

Whichever provider you evaluate, ask for evidence rather than claims:

• Which methods are supported (document, database, estimation, digital ID), and can they be combined in a step-up flow?
• Can you set the pass mark and challenge age per market and per product?
• What does the provider publish about accuracy near the threshold age, and on which test data?
• Is there independent assessment or certification against a recognised age assurance standard?
• What is retained, for how long, where is it processed, and can you configure deletion?
• How does it handle users without documents, and how does the flow behave on low-end phones and poor connections?
• What is the audit trail: can you show a regulator what check was run on which user and when?
• How fast can you change thresholds or methods when a law changes?