On 15 June 2026 the UK Government said it will bar under-16s from holding social media accounts. Almost four months later, there is still no rule to build against.
The announcement is not law. The ban only happens if the Secretary of State makes regulations and Parliament approves them. A law firm’s tracker reported that as of 18 September no regulations had been laid. Law firm commentary expects draft regulations by Christmas and the measures to take effect in spring 2027.
So you have one fact: the number 16. This post is about what to do with a number and nothing else. The short answer is to build the plumbing now and leave the wall for later.
What is known, and what is not
The power comes from a new section 214A of the Online Safety Act 2023. It was inserted by the Children’s Wellbeing and Schools Act 2026. The section lets the Secretary of State require services to stop or limit children’s access by reference to an age. Parliament gets one vote on the draft: approve or reject. It can’t amend it.
Here is the split as of this week.
| Known | Open |
|---|---|
| The legal power (section 214A) and the approval route | The final list of services in scope |
| Six services named so far: Snapchat, TikTok, YouTube, Instagram, Facebook and X | Whether the duty sits only with the platform, or also with app developers and device makers |
| WhatsApp and Signal are not intended to be caught | Which methods count as highly effective at 16 |
| The check must be “highly effective age assurance”, Ofcom’s term for an age check that works in practice | The start date, and what happens to accounts that already exist |
| Ofcom doesn’t check ages. Platforms do | The exact feature limits and their ages |
| The penalty ceiling is £18 million or 10% of qualifying worldwide revenue | Whether a store or device signal can count |
Ofcom has to report on age assurance for over-16 checks by the end of October. That report covers options. It doesn’t set the rule. Treat it as input, not as the specification.
The ban is wider than accounts
Most coverage says “social media ban” and stops. The Government has said more than that. The details differ between law firm summaries, and the final text will be in the regulations, so read this table as direction, not as obligation.
| Feature | Who it targets | What has been announced |
|---|---|---|
| Holding an account on a named service | Under 16 | Barred |
| Creating livestreams | Children, with defaults for 16 and 17 | Blocked or limited |
| Contact from strangers, including in games | Under 16, with defaults for 16 and 17 | Restricted |
| Overnight curfew | 16 and 17 | Default off-hours from midnight to 6am, which the user can change |
| Autoplay and personalised feeds | 16 and 17 | Off by default |
| Chatbots that simulate romantic or sexual relationships | Under 18 | Minimum age of 18 |
Read the age column again. It doesn’t say 16 once. It says under 16, 16 and 17, and under 18. One product will need three different answers about the same person.
The 16 and 17 tier is not a ban
The Government framed its default settings for 16 and 17 year olds as a way to avoid a cliff at 16. A user who turns 16 doesn’t get full access. They get a different set of defaults.
That breaks the usual data model. Most age gates store one flag: over_16, true or false. A flag can’t tell a 16 year old from a 40 year old, and under this plan the two get different treatment on at least four features.
You need bands: under 16, 16 to 17, and 18 or older. That means two thresholds, 16 and 18, and two different levels of difficulty. The 18 line gets its safety from a wide buffer: anyone estimated under 25 is sent to a stronger check. At 16 that cushion lands on the teenagers the rule exists to protect, so it costs far more and still isn’t safe. The EU is heading to the same shape. If you serve both markets, our post on why the EU’s age bands break a yes-or-no check applies here too.
Why not wait, and why not build the wall now
Waiting looks cheap. If the dates hold, the draft regulations land around Christmas and the measures start in spring 2027. That leaves roughly three to five months between seeing the text and being bound by it. For a product with a large base of existing accounts, that is not much. Rewriting the places that read a user’s age is slow. Changing how those places decide is slow too.
Building the full wall now is worse. You would guess the scope, the method and the date, and you would probably guess at least one of them wrong. Two costs follow. First, you lock out adults who can’t clear a check the final rule never required, which is the adult lockout problem. Second, you pay for checks you didn’t need to run, and the cost per verified adult is the number that decides whether that hurts.
The middle path is to build what doesn’t depend on the final text. That is three things: a rules table, stored evidence and a way to run a rule without enforcing it.
Keep the rule as data
The mistake to avoid is if (age >= 16) in the code that renders a screen. When the regulations arrive, every one of those lines is a change request.
Put the rules in one table instead. Each row says which feature, which place, which treatment for each band, how strong the evidence must be, and when the rule starts. Here is a version in TypeScript.
type Band = 'under16' | 'from16to17' | 'adult' | 'unknown';
type Mode = 'off' | 'shadow' | 'enforce';
type Level = 'declared' | 'estimated' | 'verified';
type Treatment = 'blocked' | 'default_on' | 'default_off' | 'allowed';
interface Rule {
id: string;
feature: string; // 'account', 'livestream', 'stranger_contact', ...
jurisdiction: string; // 'GB'
treatment: Record<Exclude<Band, 'unknown'>, Treatment>;
minAssurance: Level; // how strong the evidence must be
effectiveFrom: string | null; // ISO date. null until the regulations name one
mode: Mode;
version: number;
}
const order: Level[] = ['declared', 'estimated', 'verified'];
function decide(band: Band, evidence: Level, rule: Rule, now: Date) {
const live =
rule.mode === 'enforce' &&
rule.effectiveFrom !== null &&
now >= new Date(rule.effectiveFrom);
const enough = order.indexOf(evidence) >= order.indexOf(rule.minAssurance);
const treatment =
band === 'unknown' || !enough ? 'needs_check' : rule.treatment[band];
record({ ruleId: rule.id, version: rule.version, band, evidence, treatment, enforced: live });
return live ? treatment : 'no_change'; // in shadow mode: write the record, change nothing
}Four details matter.
effectiveFrom is null. Today nobody knows the date, so the table says so. A rule with no date can’t be enforced, even by mistake.
mode has a middle value. In shadow, the function computes the answer and writes it down, but the user sees no change. That is the whole trick, and the next section uses it.
minAssurance sits on the rule, not in the code. If Ofcom’s report or the regulations raise the bar, you change one value and bump version. The per-feature split matters, because a curfew default may not need the same evidence as an account ban.
The record carries the version. When someone asks in 2027 why a user was treated a certain way in March, the answer is in the log. Our post on conflicting age signals covers why the version belongs in that record.
Store the evidence, not the verdict
The table above reads two inputs: the band and the strength of the evidence behind it. If your database only holds over_16 = true, you have the verdict and not the evidence.
That matters because the bar can move. A March statement from Ofcom and the Information Commissioner’s Office said that facial age estimation and email-based age estimation can be highly effective, and that self-declaration and debit cards can’t. If the over-16 bar lands in a similar place, a user who typed a birthday three years ago has a verdict that no longer counts. If you stored only the verdict, you can’t tell them apart from a user you verified last week. You would have to ask everyone again.
Store each claim with its method, its level, its date and its source. The band is then computed from the claims, not written by hand. The same idea runs through our posts on account tenure as a signal and on why an operating system age signal is not a check.
Run it in shadow first
Shadow mode is the cheapest useful thing you can do before the text exists. Turn the UK rules on in shadow for GB traffic. For every session, the code computes the band and whether the stored evidence is strong enough. It enforces nothing. It asks no one for anything.
After a few weeks you can answer questions you can only guess at today:
- What share of active UK accounts has no evidence at the likely bar?
- How many sit in the 16 to 17 band, and so would get different defaults?
- How many have a birthday on file that disagrees with another signal?
- How many would be challenged on their next visit?
The cost of the exercise is engineering time and a log table. It doesn’t cost a single paid check, because it only reads evidence you already hold.
Now price it. Say shadow mode shows that 1,000,000 UK accounts are active in a month, and 70% of them have only a declared birthday. That is 700,000 people who would need a real check. These figures are an illustration, not a forecast, and they use Growth plan list rates of €0.02 per browser age check and €0.20 per document verification. They ignore the plan fee and the included monthly checks.
| Design | Share sent to a document | Cost for 700,000 people |
|---|---|---|
| Estimation first, 20% escalate | 20% | €42,000 |
| Estimation first, 40% escalate | 40% | €70,000 |
| Document first | 100% | €140,000 |
The escalation rate is the number to watch. At the 16 line it will be higher than at 18, for the reason in the buffer post. Shadow mode shows your real rate on your real users before you commit to a design, and the layered approach is what keeps it low.
Three things not to do
Don’t ship a hard 16 wall early. You would be guessing at scope and date. If you act on accounts now, you also face the problem our post on the age sweep with no undo button describes: deleted accounts, appeals and no clean way back.
Don’t read Ofcom’s October report as the rule. It reports on options. The regulations set the bar. Update minAssurance from the report if you want, but keep the rule in shadow until the text exists.
Don’t mistake declaration for compliance because other countries did. Australia’s ban removed more than five million accounts and still let testers open new ones by declaring they were 16. The Secretary of State has also asked that checks not shut out adults who have no passport or driving licence. A design that depends on documents alone fails that test before it starts.
A dated checklist
The dates below are expected dates, not fixed ones. The regulations could slip.
| When | What lands | What you do |
|---|---|---|
| Now | Nothing binding on accounts | Build the rules table. Store claims with method and level. Turn on shadow mode for GB |
| End of October 2026 | Ofcom’s report on over-16 age assurance | Read which methods it calls highly effective at 16. Update minAssurance and bump the version. Keep mode at shadow |
| Around Christmas 2026 | Draft regulations. Ofcom has said it will publish an updated roadmap straight after | Check whether you are in scope. Fill in the service list, the features and effectiveFrom. Ask counsel about who owes the check |
| Spring 2027 | Measures take effect, if Parliament approves | Flip mode to enforce on the date. Start with new sign-ups, then work through existing accounts in batches |
Where Xident fits
Xident returns an over or under answer for the age threshold you set. For this rule, those are 16 and 18. You can set a challenge-age buffer per surface, so a stricter feature can use a wider margin than a looser one.
Each decision record holds the method, the outcome, the threshold, the confidence, the policy version and the time. That is the evidence your rules table needs, and it lets you read old decisions against a new bar without asking users again. A returning user with an Xident ID costs one Check, not one document Verification, so the second pass costs far less than the first.
The free sandbox gives you 1,000 Checks and 100 document Verifications, once. That is enough to measure your own escalation rate on a sample before the regulations arrive. If you want to see what the bill looks like at your volumes, the pricing calculator takes your numbers. To talk through a UK rollout, get in touch.
This post is general information about age-assurance architecture and public policy, not legal advice. The regulations described here haven’t been laid, and details may change. Consult qualified counsel for your specific obligations.
