Before You Add Another Selfie Scan: A UK Age-Assurance Reality Check

Somewhere in the last eighteen months, the age gate stopped being a niche compliance chore and became a default product surface. A forum asks for a selfie before you can post. A retailer wants a driving licence before you can buy a kitchen knife. A group chat asks you to confirm you are over thirteen, then over eighteen, then asks again because the first answer did not match the account history. In 2026, Britain’s Online Safety Act has pushed age assurance out of the legal department and into the interface, and product teams are now expected to have opinions about it.

The trouble is that most of those opinions arrive as a vendor demo. Someone shows a neat modal, a progress bar, a smiling face inside a dotted oval. It looks like a door. It is not a door. It is a trust fall with a database attached, and the product team is the one falling.

What the gate actually checks

Age assurance is an umbrella term, and the methods underneath it are not interchangeable. A self-declared date of birth checks nothing except whether someone can type. A credit card check infers age from financial history, which is a rough proxy at best. An ID upload verifies a document, which means it is really checking identity, not just age. Facial age estimation guesses from a biometric signal, usually without storing the image, but the guess has error bars that matter. Mobile network operator checks and open banking signals sit somewhere in the middle, useful but unevenly distributed across the adult population.

Ofcom’s guidance is clear that the method should be proportionate to the risk. That is a sensible principle, and it is also where most product teams skip ahead. The useful question is not “which vendor has the best conversion rate?” It is “what specific harm are we trying to reduce, and what is the lightest check that meaningfully reduces it?” A gambling sign-up and a knitting forum do not need the same assurance. A retailer selling age-restricted goods needs something defensible. A social app trying to keep under-thirteens out of a public feed needs something quite different from a payments product trying to stop a nine-year-old from spending £400 on skins.

Six questions before the next selfie scan

1. Are we checking age or identity? These are not the same. An ID upload creates a identity-verification event, and that event generates data: document numbers, names, dates of birth, sometimes a selfie to match. If you only need to know whether someone is over eighteen, an identity check may be over-collection. If you need to know who they are, say so, and design for it. Ambiguity here is how teams end up holding more personal data than they can justify.

2. What happens when the check says no? False negatives are not an edge case. Adults without passports, people who have changed their name, trans users whose documents do not match their appearance, older users with poor camera phones, and anyone in a badly lit room will hit the failure path. A pass/fail gate with no redress is a customer-service problem disguised as a security feature. The failure path needs a human route, a reasonable timeframe, and a way to appeal that does not require another selfie.

3. Where does the data go, and how long does it stay? Facial age estimation vendors often say the image is not retained. That is good, but it is not the whole map. Ask about logs, metadata, processor access, retention schedules, and whether the vendor trains models on your users’ data. If biometric data is involved, treat it as special category data under UK GDPR and expect a data protection impact assessment. “The vendor handles it” is not a retention policy.

4. Can we design our way out of this instead of gating? Age-appropriate design is not a consolation prize for teams that cannot afford assurance. It is often the better product. Defaults that limit discovery, safer direct messaging settings, time-limited sessions, and clearer reporting flows can reduce harm without asking every user to prove their birthday. A gate is a checkpoint. Design is the road.

5. What does the check cost the user in access and dignity? Age assurance lands unevenly. It can exclude people who do not have the right documents, the right phone, the right lighting, or the right face for the model. It can also feel intrusive in contexts where the risk is low. If your product is a community noticeboard, a full ID upload is not a proportionate trust signal. It is a barrier that says “we did not think about you” to a lot of adults.

6. What is the exit plan? Age assurance is a fast-moving market with a small number of large vendors. Ask whether the integration is portable, whether you can swap methods, and whether the user’s proof can be reused across services without creating a new honeypot. The UK’s digital identity work is moving toward reusable proofs, but the practical reality in 2026 is still a patchwork. Design for the swap, not just the launch.

The pass/fail trap

A gate feels decisive because it produces a binary. But age is not binary, and harm is not binary either. A fourteen-year-old and a seventeen-year-old are not the same risk on every product, and an adult who fails a facial scan is not a security incident. The teams that get this right tend to treat age assurance as one signal in a wider safety model, not as a magic door. They log less, explain more, and build a failure path that does not punish the user for the model’s uncertainty.

The Online Safety Act has made age assurance unavoidable for a lot of UK products. That does not mean every product needs a selfie scan. It means every product team needs a defensible answer to a simple question: what are we actually verifying, and what happens to the person on the other side of the checkpoint? If the answer is “we’re not sure, but the vendor looked good in the demo,” the gate is doing more for the slide deck than for the user.