Age assurance UX is the design of the moment a UK product asks someone to prove their age: where the check sits, which methods people can pick, what you tell them about their data, and what happens when the check gets it wrong. Since July 2025, user-to-user services likely to be accessed by children that allow the most harmful content must use checks that are "highly effective" under section 12 of the Online Safety Act.
The law sets the bar but doesn't draw the screens. The flow must stop children, let adults through without a fight, and give anyone wrongly blocked a way back.
This guide is for product leads at UK social, community, dating, gaming, creator and AI chat products. If you want a fintech UX designer in London who also designs consumer products, I work remotely. This is design guidance, not legal advice: your counsel decides what applies to you.
What the Online Safety Act asks for, and since when
GOV.UK's Online Safety Act explainer gives the dates. The duty on services publishing their own pornographic content (Part 5, section 81) came into force on 17 January 2025. User-to-user services likely to be accessed by children had until 24 July 2025 to complete a children's risk assessment, and the protection of children duties took effect that month.
Section 12(4) to (6) is the core. If your service doesn't prohibit primary priority content (pornography, and content encouraging suicide, self-harm or eating disorders), you must use age verification or estimation to stop children encountering it, "highly effective at correctly determining whether or not a particular user is a child". Section 230 defines both terms and rules out self-declaration "without more".
Ofcom's Report on the use of age assurance of 16 July 2026 shows the scale: over 69 million checks across 32 analysed services between July and December 2025, a 23-fold rise on the previous six months. Among 8 to 17 year olds, exposure to checks other than self-declaration rose from 25% to 43% between July 2025 and January 2026.
Does your product need highly effective age assurance?
Your lawyer makes the call. In the intro call I sort the answers into a rough table like this, built from the Act and the Ofcom and ICO joint statement of 25 March 2026.
| Your situation | What applies | What it means on screen |
|---|---|---|
| You publish your own pornographic content | Highly effective checks before access | A front gate: nothing visible until the check passes |
| User-to-user service that allows primary priority content | Highly effective checks so children don't encounter it | A gate on that section, logged in or out |
| Minimum age, say 13, in your terms | Apply it consistently; Ofcom recommends highly effective checks for services most used by children | A check at account creation |
| Likely to be accessed by children, no harmful content allowed | No Act age check duty, but the Children's code applies | Know age well enough, or give everyone the child protections |
The joint statement also rules out terms of service restrictions and payment methods that don't require the user to be 18, such as debit cards. A footer line saying "18+ only" protects nobody.
Age assurance UX starts with where the check sits
The mistake I watch for is a gate placed for the build's convenience: at sign-up, for everything, when only one part of the product needs it. Ofcom's Protection of Children Code, as its July 2026 report summarises it, ties the check to what is restricted: the whole service when its principal purpose is harmful content, otherwise the content and features that carry the risk.
For adult services, Ofcom calls the "front gate" the safest placement: a blank page until the check passes. Of 118 adult services with checks that children in Ofcom's measurement panel visited, 45% had a front gate, 39% a blur gate and 14% an image gate. For a mixed product, the joint statement's social media example gates only the restricted section, for logged-out users and anyone without a completed check.
My placement rules:
- Gate at the point of need, where the person can see why you're asking.
- Explain before you collect: one sentence on why, one on what you'll ask for, then the choice.
- Say the rest of the product stays open, in words.
- Decide when to ask again. Ofcom asks services relying on a one-time check to consider repeats or triggers such as new log-ins. I write that rule into the design file.
That is how I design age checks for London product teams: placement first, in grey wireframes, before anyone picks a provider.
Choosing which age check methods to offer
Ofcom's guidance lists seven methods capable of being highly effective, and says the list isn't exhaustive. It judges the whole process on four criteria (technical accuracy, reliability, fairness, and working correctly in real conditions) and two principles about being easy to use and working for everyone. I don't name or rank providers; Ofcom's report asks you to run regular due diligence on yours.
| Method | What the person gives | What the screen must make clear |
|---|---|---|
| Facial age estimation | A selfie or short video | That it estimates age, and when the image is deleted |
| Photo ID matching | An ID and a selfie | Which IDs work, and what is kept |
| Digital identity services | A share from an ID app | Which details are shared, ideally "over 18" only |
| Mobile network operator checks | A phone number | What the network shares |
| Credit card checks | Card details | Whether anything is charged; debit cards won't work |
| Email-based age estimation | An email address | What the check looks at |
| Open banking | A bank connection | Exactly what the bank shares |
Choice matters because not everyone has a passport, a credit card or a usable camera. Ofcom found all 19 analysed adult services offered more than one method, three on average, and facial estimation made up 68% of their completed checks from July to November 2025.
The ICO's Children's code standard 3 adds: avoid giving people no choice but a hard identifier like a passport unless the risks warrant it. So I list the least intrusive option first, the ID option last, with equal visual weight, and never pre-select the cheapest one for you.
Two invisible parts shape the screens. Ofcom expects liveness detection with facial estimation and photo ID, so the camera step needs instructions people can follow. And it expects a challenge age: anyone estimated below a set threshold above 18 takes a second step with another method. That step is a screen to design, not an error.
Privacy messaging people believe
Privacy was the most common theme in responses to Ofcom's 2025 call for evidence, and its research found adults supportive of checks in principle but worried about breaches. The report's fix is "clear, understandable and easily accessible information" about how data is used and deleted.
The ICO's age assurance opinion of 18 January 2024 lists what you must tell people. I turn it into three labels beside the method choice:
- Why we ask: the reason, and what it unlocks.
- What we keep: what's collected, for how long, and that it's used for nothing else.
- Who runs it: whether a third party checks, and what comes back.
Then a link to challenge a wrong decision. The opinion says you may often need to record only a yes or no, so the result screen says exactly that: kept, "18+ yes" and the date; deleted, the photo. The ICO flags the opinion as under review after the Data (Use and Access) Act, so check for an update before sign-off.
My test: after the check, I ask people in a usability session what we kept. If they can't say, the screen failed.
Failure, fallback and the appeal
Every check will sometimes refuse an adult: low light, a young-looking face, an unreadable ID. The ICO opinion names both harms: children let in, and adults wrongly denied.
The Act makes the way back a duty. Section 21 requires a complaints procedure that is easy to access, easy to use (including by children) and transparent, and section 21(5)(e) covers a user locked out by "an incorrect assessment of the user's age". Ofcom found many services had no full appeals process, some only allowed a retry of the same method, and only six gave data on appeals upheld.
My pattern:
- Say what happened without blame: "We couldn't confirm 18+ this way", not "Verification failed".
- Offer the other methods at once, so nobody loops on a camera that won't work for them.
- Put "Ask for a review" on the same screen as a real button.
- Keep the review short: what went wrong, an optional note, how you'll reply. A person reviews it.
- Restore access when you were wrong, and say so.
- Count appeals and the share upheld, as Ofcom asks, on the product dashboard.
Accessibility, and not punishing adults for a bad check
The joint statement warns that a check that isn't easy to use "might unduly prevent adult users from accessing legal content". I hold the check to WCAG 2.2 AA like any other form:
- Spoken and written cues: "Move a little closer" announced to screen readers, not only an animated oval.
- No hidden timer. Timing Adjustable asks that people can turn off, adjust or extend time limits.
- A way out of the camera on every camera screen.
- Errors that say what to do, in text, next to the action.
- Keyboard access to the method choice, visible focus, targets at least 24 by 24 CSS pixels.
Accessible Authentication (Minimum) is written for sign-in, but its idea carries over: no puzzles to get through. The code side is in my WCAG 2.2 checklist for React components.
Not punishing adults also means not asking twice without reason and not making the appeal slower than sign-up. If the check is the slowest screen in onboarding, people blame you for it; see SaaS onboarding that reaches value for keeping first sessions short.
The Children's code when users might be under 18
The ICO's Age appropriate design code, the Children's code, applies to online services likely to be accessed by children, whatever the Act requires. Standard 3 gives a choice: establish age with certainty that fits the risks of your data processing, or apply the code's standards to all users.
That's the design fork. Know age well enough, and child users get high privacy by default while adults get the standard product. If not, everyone gets the protective defaults, which the ICO says doesn't mean adults are "infantilised". The code's guide age ranges are 0 to 5, 6 to 9, 10 to 12, 13 to 15 and 16 to 17, and I write privacy information for the ranges a product really serves.
The joint statement says self-declaration doesn't keep under-13s off a service with a minimum age of 13, and gives facial estimation, digital ID and one-time photo matching as current examples. The ICO doesn't currently consider profiling effective for that, and Ofcom's report has "serious doubts" about some behavioural age inference models.
What changes next: under-16 rules and ISO/IEC 27566-1
On 15 June 2026 the government announced a social media ban for under-16s, with limits on livestreaming and contact from strangers across more services, gaming included. It expects to bring the plans to Parliament before Christmas, in force in Spring 2027. Ofcom's report says the power sits in a new section 214A of the Act and that Ofcom would report by the end of October 2026 on effective checks for over 16. Read that before you set thresholds.
A 16 line changes the method list: a credit card check only shows someone is an adult, so it can't tell 16 from 15. Make the threshold a setting, not a redesign.
The standard to know is ISO/IEC 27566-1:2025, published by BSI as BS ISO/IEC 27566-1 on 31 December 2025. It is technology neutral and covers functionality, performance, privacy, security and acceptability, meaning inclusive, transparent and proportionate. BSI's launch release of 3 February 2026 says it doesn't require full identity verification every time. I haven't read the paid text, so I use it as vocabulary, not a checklist.
Where I would start
In the intro call I'd ask what your service allows, which parts children could reach, what minimum age your terms state, and what happens today when a check fails. Then I'd map the gates, wireframe the six screens in the diagram, and test them with adults who have no passport to hand.
My take: a good age check is short, honest about data and forgiving of its own mistakes. Ofcom found adult sites with checks lost traffic while some without gained it, so a check that treats adults as suspects protects nobody. For UK money products, the same habits apply to Consumer Duty screens for UK fintechs.
That is the core of my product design work for London teams: a free 30 minute intro call, a written scope and one fixed quote, weekly Figma sprints, an update every 48 hours and a documented design system. I can also build the front end in React and Next.js. See my wider product design for SaaS and consumer products.
Frequently asked questions
What is highly effective age assurance?
It's the Online Safety Act's standard for age checks: a process "highly effective at correctly determining whether or not a particular user is a child". Ofcom judges the whole process on technical accuracy, reliability, fairness and working correctly in real conditions, and expects it to be easy to use and to work for all users.
Is self-declaration of age allowed under the Online Safety Act?
Not on its own. Section 230(4) says a measure that only asks users to declare their age is not age verification or estimation, and Ofcom and the ICO agree self-declaration alone is ineffective. A birth date can tailor content, but it can't be the check that keeps children from restricted content.
Which age verification methods does Ofcom accept?
Ofcom lists seven methods capable of being highly effective: facial age estimation, photo ID matching, digital identity services, mobile network operator checks, credit card checks, email-based age estimation and open banking. The list isn't exhaustive. Self-declaration, payment methods that don't require the user to be 18, such as debit cards, and terms of service restrictions don't qualify.
What should happen if an age check wrongly blocks an adult?
They should be able to try another method straight away and ask for a review on the same screen. Section 21(5)(e) of the Act covers complaints about an incorrect age assessment, and Ofcom expects prompt action to restore wrongly restricted access. The ICO wants the challenge route prominent.
Does the ICO Children's code require age verification?
Not as such. Standard 3 asks you to establish age with certainty that suits your data risks, or to apply the code's standards to all users. If your terms set a minimum age, such as 13, the ICO expects an effective age gate, and says self-declaration and profiling aren't currently effective for that.
Do I need to keep users' ID or selfies after an age check?
Usually not. The ICO's age assurance opinion says you may often only need to record a yes or no that the person meets the threshold, and that you need a retention policy and should erase data from earlier checks you no longer need. Say on the result screen what you kept.
Sources and method
I read every source on 13 October 2026. Every number comes from Ofcom or GOV.UK, not client work; the diagram is invented. I name no age check providers. Ofcom's website blocked automated access, so I link the GOV.UK copy of its report and the ICO's copy of the joint statement, and describe Ofcom's guidance as they summarise it.
- legislation.gov.uk, Online Safety Act 2023, sections 12, 21 and 230, date read 13 October 2026: section 12, section 21, section 230
- Ofcom, Report on the use of age assurance (16 July 2026), GOV.UK copy, date read 13 October 2026: assets.publishing.service.gov.uk
- Ofcom and ICO, Age assurance: a joint statement (25 March 2026), date read 13 October 2026: ico.org.uk
- GOV.UK, Online Safety Act: explainer (updated 24 April 2025), date read 13 October 2026: gov.uk
- GOV.UK, Social media to be banned for under-16s, press release (15 June 2026), date read 13 October 2026: gov.uk
- ICO, Age appropriate design: a code of practice for online services, date read 13 October 2026: ico.org.uk
- ICO, Children's code standard 3, Age appropriate application, date read 13 October 2026: ico.org.uk
- ICO, Age assurance for the Children's code, opinion (18 January 2024), section 6, date read 13 October 2026: ico.org.uk
- BSI Knowledge, BS ISO/IEC 27566-1:2025 (published 31 December 2025), date read 13 October 2026: knowledge.bsigroup.com
- BSI, Global framework for trustworthy age assurance (3 February 2026), date read 13 October 2026: bsigroup.com
- W3C, WCAG 2.2 and its Understanding pages for Timing Adjustable and Accessible Authentication (Minimum), date read 13 October 2026: w3.org, w3.org, w3.org
Tags: Online Safety Act, Age assurance, Ofcom, Children's code, Accessibility, United Kingdom
