Age checks arrived. Most of them prove the wrong thing.

Age assurance in Britain has stopped being a policy discussion and become an enforcement one. Ofcom's programme on age assurance has moved from investigating to fining, with penalties against pornography providers now running well into seven figures and the largest so far at £1.35 million. It has also opened cases involving generative AI services, which tells you the scope is no longer confined to the industry everyone assumed this was about.

The measurable effect is real. Among children who were asked to prove their age, the proportion encountering a highly effective check rose from 25 per cent in July 2025 to 43 per cent in January 2026. Every one of the ten most visited pornography sites in the UK now runs checks.

So the regime works, in the sense that it has changed behaviour at scale in eighteen months. I want to make a narrower argument about what these systems actually establish, because there is a confusion sitting inside most implementations that will cause problems later.

Three different questions

When a site asks whether you are old enough, it can be answered in three fundamentally different ways, and they are not interchangeable.

Is this person over eighteen? Answered by an identity document, a credit reference check, or an open banking lookup. It is a fact about a specific named human, sourced from a record about them.

Does this face look over eighteen? Answered by facial age estimation, which returns a statistical guess from an image. It is not a fact about a person, it is an inference about an appearance, with an error distribution that is widest exactly where it matters most, around the threshold.

Has someone over eighteen been involved at some point? Answered by nearly every implementation in practice, whether or not it intended to. This is the one nobody puts on a slide.

Ofcom's four criteria for a highly effective check are technical accuracy, robustness, reliability and fairness. Those are sensible criteria and I would not change them. But notice that they are properties of the method. They say a great deal about whether the check works when it is run honestly, and much less about whether the person the check ran on is the person now using the service.

The gap between the check and the session

Here is the mechanism, stripped of any particular vendor.

A user is presented with a check. The check completes. A token, a cookie or a flag is set. The session proceeds. Every subsequent request is authorised by that flag rather than by the check.

Which means the security of the whole arrangement rests on the binding between the human who passed the check and the session that inherited the result. In a great many deployments that binding is a browser cookie.

A child who borrows a parent's face for eleven seconds, or a parent's document, or a parent's phone, has not defeated the age check. The check ran correctly and returned the right answer about the person in front of it. What has been defeated is the assumption that the same person continues to be there.

This is the same structural problem I have written about in biometric fraud, and it has the same shape. A strong check at one moment, followed by a long period in which trust is inherited rather than re-established. The attack does not go at the check. It goes at the inheritance.

Why estimation and verification keep getting conflated

Facial age estimation is genuinely useful. It is fast, it needs no document, it collects less about a person than an identity check does, and for the large majority of users who are obviously well above or well below a threshold it is accurate enough to be the right tool.

The difficulty is that its accuracy is not uniform. An estimator is most uncertain about seventeen and nineteen year olds, which is precisely the population the rule exists to separate. Vendors publish mean absolute error across a whole distribution, and that headline figure is dominated by the easy cases. The number that matters is the error rate in the two years either side of the threshold, and it is a different and less flattering number.

Deployments handle this with a buffer. Estimate high, and send anyone near the line to a stronger check. That is the correct engineering response. It also means the system is really two systems, and the honest description of it is that most users get an estimate and the contested cases get a verification.

The privacy problem nobody has solved well

The instinctive fix for all of this is to check harder and check more often. That runs directly into the reason age assurance was contentious in the first place.

Every additional check is a collection event. A regime that requires a document scan to read a news site has traded one harm for another, and the ICO and Ofcom have both been explicit that data minimisation is not optional here.

The resolution is not more checking, it is better shaped checking. What a site needs is a signed, unlinkable assertion that the holder is over a threshold, issued once by a party competent to establish it, presented many times without the issuer learning where. That is exactly what a digital identity wallet is designed to carry, and it is why the age assurance debate and the wallet debate are converging whether or not the people having them realise it.

It also has a failure mode that is not yet widely appreciated, and I have written about it separately: a series of over-eighteen, over-twenty-one, over-twenty-five answers about the same person eventually reconstructs the date of birth that nobody disclosed.

What I would build

Ask for the weakest assertion that satisfies the duty, and no more. Almost nothing requires a date of birth. Most things require a boolean.

Bind the result of the check to something more durable than a session cookie, and re-establish it at the moments that carry consequence rather than only at the door.

Be honest internally about which of the three questions your system answers. If it answers the third one, know that, and decide whether it is sufficient rather than discovering the answer during an investigation.

And keep the buffer. The single most useful design decision in age assurance is admitting that your estimator is unreliable near the threshold and routing those users somewhere better, rather than pretending to a precision the method does not have.

Ofcom has been clear that tougher action is needed. I read that as a signal that the compliance-theatre implementations, the ones with a tick box and a cookie, are going to be tested. The systems that survive will be the ones that can say what they proved, about whom, and when.