.webp)
For more than a year now, regulated services with UK users have been trying to work out what “highly effective age assurance” means in practice under the Online Safety Act. And while Ofcom has named methods that may qualify, it’s still often unclear how good is good enough.
Now, the lack of clarity has become even more pressing, as the UK government is preparing a new under-16 social media restriction. If the plan moves ahead, some services may also need to prove that a user is over 16, which is harder than an 18+ check.
That’s why the Department for Science, Innovation and Technology (DSIT) has asked Ofcom to assess what “highly effective” should mean when proving that someone is over 16 for the planned regulation, with results due by October.
In this commentary article, we look at why the wording has caused trouble, what DSIT is asking Ofcom to clarify, and how teams can prepare age checks that are strong enough to defend without collecting more data than they need.
I think it’s a great move by DSIT, as there is enough confusion already about the existing checks. And now that there are even more sensitive age checks on the horizon, the industry must operate with more precise policy language.
Otherwise, every service ends up defining highly effective in its own way.
Get posts like this in your inbox with the bi-weekly Regula Blog Digest!
Why the Online Safety Act’s wording has been a mixed bag
To start with, the Act is not as vague as some may think. For example, Ofcom’s guidance does name specific methods with the potential to be highly effective, including photo-ID matching, facial age estimation, and reusable digital identity services. Moreover, it treats self-declaration, debit cards or other payment methods that do not require the user to be over 18, and general contractual age restrictions as too weak.
The guidance also gives four criteria for assessing whether an age assurance process is highly effective: technical accuracy, robustness, reliability, and fairness. Privacy and accessibility are also important parts of the wider implementation discussion.
At the same time, that guidance still asks teams to fill in a lot of product detail themselves. It does not give one universal numerical threshold for key metrics, nor does it provide a ready-made step-up policy for every type of service.
That’s why teams still have to make their own decisions on several key parameters:
-
the acceptable false-accept rate near the age line;
-
the acceptable false-reject rate for users old enough to access the service;
-
the point at which age estimation should move to document verification or digital ID;
-
records needed for audit, complaints, and regulator requests;
-
fraud tests needed before launch, including replay, injection, forged IDs, borrowed documents, and virtual cameras.
There are so many seemingly ordinary things teams can get stuck on without proper direction. It helps to know how to approach things like a 15.8 age estimate, a low-quality selfie, a repeat attempt from the same device, or a user without a passport.
The right decisions in such cases determine whether the whole age assurance process holds up to scrutiny.
What DSIT asked Ofcom to clarify
DSIT’s request consists of three major parts. Ofcom has been asked to:
-
produce a rapid assessment of highly effective age assurance at 16, with publication due by October so Parliament can debate the government’s planned regulations before the end of the year;
-
look at new methods that could support that age line;
-
take account of people who are old enough to use a service but cannot prove age with a passport or driver’s license, while keeping privacy and security high on the list.
Despite the October deadline, Ofcom has already hinted at the likely direction. Its reply says that checking whether someone is over 16 should be technically possible, but it is harder than checking whether someone is over 18. For example, credit card checks are the easiest example: they may help prove that someone is an adult, but they do not prove that someone is 16 or 17.
Ofcom also sounds cautious about systems that guess age from user activity, such as account behavior or usage patterns. In its reply, it says this type of inference is not yet proven as an effective and privacy-preserving way to support an under-16 social media restriction.
We probably should not expect Ofcom to solve everything with one percentage. A 16+ rule has too many variables for that: the user’s exact age, the type of service, the level of risk, and the age-checking method being used.
A more realistic outcome would be clearer guidance on which metrics to measure, when to send a user to a stronger check, and what evidence should be kept after the decision.
Making age assurance highly effective without over-collecting data
October may bring more formal wording from Ofcom, but teams shouldn’t wait to clean up their age assurance logic.
First, determine which age line applies to each product, feature, and market. Some teams may need to deal with 16+ and 18+ decisions at the same time, and Ofcom has already flagged that as an issue for services with concurrent duties.
Next, decide which check comes first. In many cases, age estimation may be enough as the first step because it asks less from the user. In other cases, the service may need stronger proof from the start, such as a verified document or digital ID.
After that, define the point where the user is sent to a stronger check. This is one of the most important decisions because borderline results are where age assurance gets messy. A user who is clearly above the age line should not be treated the same way as someone whose result is close to the threshold.
Good age assurance does not automatically mean asking everyone for an ID document. That would be too heavy for many services and would create its own privacy and inclusion problems.
Yes, some cases will need liveness and document authenticity checks because fraud risk is higher. But only some. The point is to connect the check to the risk, then keep enough evidence to be able to defend your decision later, if necessary.
Then, set up clear rules for image storage, deletion, staff access, training use, repeat attempts, and fraud review. Good privacy is setting reasonable limits and being able to prove that those limits were followed.
Finally, decide what record remains after the check. In case of a user complaint or an Ofcom review, the team should be able to show which policy was active, which method was used, what result was returned, whether a step-up check was offered, and what happened after that.
A simple working model may look like this:
| If this happens… | …the system should… |
|---|---|
|
The user is clearly above the age line in a lower-risk check |
Let them pass with a low-friction method and keep a basic audit record |
|
The result is close to the age line |
Send the user to document verification, digital ID, or review |
|
The user has no passport or driver’s license |
Offer another route instead of blocking them by default |
|
The session looks suspicious |
Use liveness, injection detection, document authenticity checks, or repeat-attempt controls |
|
The user challenges the result |
Show the policy, method, result, and review trail |
So, while Ofcom works on the definition of “highly effective,” teams can already prepare for the version of age assurance that is coming: one with thresholds, fallbacks, privacy rules, fraud testing, and audit records.
What our approach to age assurance is about
As regulations change, we will surely see fewer and fewer simple checkboxes to verify users’ age. That’s why we will also be seeing more widespread use of age verification solutions that are not only reliable, but are adaptable to risk levels and compliant with privacy laws.
Regula’s approach is to build solutions that are just that. The Regula IDV Platform combines two solutions to cover the full spectrum of age assurance needs and allows managing age verification workflows depending on the business use-case. Together, they offer much flexibility, matching the verification method to the risk level, and not forcing a one-size-fits-all process on every user:
-
selfie-based age estimation powered by Face SDK, which uses biometric analysis to estimate age (for lower-risk checks);
-
and document-based age verification via Document Reader SDK, which extracts and validates a date of birth from an official ID. It also analyzes the portrait in the ID, estimates the person’s approximate age, and compares that signal with the document’s date of birth and date of issue (for higher-risk checks).
Regula featured in NIST’s FATE-AEV as a top performer in two of the most critical age assurance scenarios: Challenge 25 and Child Online Safety (ages 13–16). It also topped the list of ID verification vendors as the most accurate age estimator across six geographic regions.
Curious about how Regula can help you build an age assurance setup that fits your risk level? Let’s talk.
