Age Assurance for Social Platforms: The Users You Already Have

Most teams scope age assurance as a signup problem. Add a check before account creation, pick a vendor, ship it, tell the regulator.

That scoping misses the obligation with the largest penalty attached. Australia's minimum age law does not only ask you to stop new underage accounts. It asks you to deal with the ones already open, and to stop those same people coming straight back.

Age assurance for social platforms is therefore a remediation programme wearing a signup gate as a hat. The gate is a fortnight. The remediation is a quarter.

Four regimes, one product, and they disagree

A platform with users in Europe, the UK, India and Australia is inside four instruments at once, and they bind on where the users are rather than where the company is incorporated. No European entity is required for the DSA to apply.

1. Australia. The Online Safety Amendment (Social Media Minimum Age) Act 2024 took effect on 10 December 2025. It sets a minimum account age of 16 that parental consent cannot override, which is the part that surprises people. Platforms must take reasonable steps to prevent under 16s holding accounts, including removing existing ones and preventing re registration. Penalties reach AUD 50 million, and the eSafety Commissioner published a compliance update in March 2026 setting out what it expects to see.

2. United Kingdom. The Online Safety Act requires age assurance that Ofcom describes as highly effective for certain content categories, enforceable since 25 July 2025. Penalties run to £18 million or 10 per cent of global turnover, whichever is greater, with business disruption measures available on top. Ofcom's own reporting shows the share of children encountering effective checks rising from 25 per cent to 43 per cent between July 2025 and January 2026, and its July 2026 statutory report said tougher action is still needed.

3. European Union. The Commission published DSA guidelines on protecting minors on 14 July 2025. They recommend age verification for adult content and for platforms posing high risk to minors, and set criteria for the methods: accurate, reliable, resistant to circumvention, minimally intrusive and non discriminatory. Alignment with the UK regime is substantial, so a platform meeting Ofcom's guidance is usually close on the DSA.

4. India. A different shape entirely. The IT Rules make safe harbour under Section 79 of the IT Act 2000 conditional on due diligence, with grievances acknowledged within 24 hours and disposed of within 15 days with reasons. A Significant Social Media Intermediary, meaning more than 5 million registered users in India, appoints a Chief Compliance Officer resident in India, a nodal contact available 24 hours, and a Resident Grievance Officer, and publishes a monthly compliance report.

Read those together and the engineering requirement falls out. You need to know where a user is, which gate applies there, what evidence you hold for them, and when that evidence expires. Four columns, one table, and almost nobody has it.

What each one accepts as a check

The methods overlap more than the laws do, which is the good news.

• Document based verification. A photo ID matched against a selfie. Highest assurance, highest friction, worst conversion. Reserve it for the cases that need it and for appeals.
• Facial age estimation. A model estimates an age band from a selfie without identifying the person. Accepted by Ofcom as capable of being highly effective, much lower friction than documents, and it does not require the user to hold ID. Accuracy falls at the boundaries, which matters when your threshold is 16 and the model is least confident between 14 and 18.
• Third party confirmation. A bank, a mobile carrier or a digital ID provider confirms the user is over the relevant age without disclosing anything else. Very low friction where it is available, and availability varies enormously by market.
• Inference from existing signals. Account age, behavioural patterns, connections, stated age at signup. On its own this is not highly effective anywhere and should not be presented as a primary control. As a triage layer it is extremely useful, and that is the design most teams miss.

The pattern that works: inference triages the base, and only accounts flagged as likely under age are sent through a real check. Running document verification across an entire user base is unaffordable and unnecessary. Running it across the 4 per cent your inference layer flags is a project.

The retrospective obligation nobody prices

Now the part this article exists for.

Your platform has, hypothetically, 2 million Australian accounts. Some proportion are under 16. Nobody knows the number, because the only age data you hold is a self declared date of birth from signup, and any 13 year old who wanted an account typed a different year.

Australia's requirement covers those accounts. Reasonable steps to prevent under 16s holding an account includes the ones already holding one.

That is four distinct pieces of work, none of which appear in a vendor's integration guide.

Estimate the population. Before doing anything, get a defensible estimate of how many accounts are likely affected, because it sizes everything downstream. This is an inference exercise across behavioural and declared signals, and the output is a distribution rather than a number.

Triage, then verify. Score the base, flag the likely cohort, and route only those through a real check. If your inference flags 4 per cent of 2 million, that is 80,000 checks, not 2 million. The difference between those two figures is the difference between a project and an impossibility.

Handle the ones who do not respond. Many flagged accounts will simply ignore the prompt. You need a policy: how many prompts, over what window, and what happens at the end. Deactivation of a non responding account that turns out to be a 34 year old who never checks notifications is a support problem and a press problem, so the escalation path and the appeal route need to exist before the first prompt goes out.

Handle the ones confirmed under age. Account closure, data handling, and a clear message. There is a genuine dignity question here and it is worth spending time on the copy. A teenager losing their account and their content with a one line error message is the screenshot that ends up on a news site.

Seventy to 150 hours of engineering, plus a support load that finance should be told about in advance rather than discovering in the ticket queue.

Re registration is the hard half

Removing an account is a database operation. Stopping the same person opening another one on Tuesday is the actual requirement, and it is the part where honest engineering has to admit its limits.

Australia's expectations include preventing re registration, with circumvention tooling such as VPN detection called out. So the design question becomes what you can hold about a person you have just removed, in order to recognise them again, without keeping a register of children.

That tension is real and there is no elegant answer. What works in practice is a narrow, hashed, purpose limited signal rather than a profile. Enough to recognise a repeat attempt from the same verified identity, held for a defined period, used for nothing else, and documented as such. What does not work is retaining the full verification artifact, because now you are storing identity documents belonging to minors, which is a worse liability than the one you were solving.

Two practical notes. Device and network signals decay quickly and are trivially circumvented, so they belong in triage rather than in enforcement. And any re registration control will produce false positives on shared devices, particularly on family tablets, so the appeal route carries real load here and should be staffed rather than automated.

Storing an age signal without creating a new liability

The general rule for the whole build: store the conclusion, not the evidence.

What you need to keep is that this account was verified as over the threshold, by which method, on which date, with a reference the provider can reconcile if challenged. What you do not need to keep is the image, the document, or the raw biometric.

Most reputable providers support exactly this. The check happens on their side, they return a pass or fail with an audit reference, and the artifact is deleted according to their retention policy. Confirm that in the contract rather than assuming it, and confirm what their retention period actually is, because a provider holding minors' documents for 24 months is your exposure as much as theirs.

Two more design points that save trouble later.

Age bands, not birthdays. Store over 16, over 18, over 21 as separate flags rather than a derived date of birth. It is less data, it answers every question you actually ask, and it avoids the drift problem where a stored age becomes wrong on a birthday.

Expiry and re verification. A check performed at 15 is not evidence at 17, and more importantly a check performed once is not evidence forever if your regulator asks about current controls. Decide a re verification cadence per market and write it down.

What the check costs you in signups, and how to argue about it

Somebody will raise conversion, usually in the meeting where the budget is approved, and the argument goes badly without numbers.

Friction is real and it varies enormously by method. Document verification asks a user to find identification, photograph it and wait. Facial age estimation asks for one selfie and returns in seconds. Third party confirmation through a bank or carrier can be almost invisible where it is available. Those three sit at very different points on a drop off curve, and the correct method for your product depends on which markets you serve and what content you carry.

Three things make this conversation productive rather than circular.

Instrument the funnel from day one. Started, completed, abandoned, failed, appealed, at each step, split by method and market. Without that you are comparing a vendor's published figures against your own anecdotes.

Do not gate everything. Most platforms need a check for specific content or specific features rather than for account creation itself. Gating the whole product when the obligation attaches to one surface is a self inflicted conversion loss, and it is common because it is simpler to build. Map the obligation to the surface, then gate the surface.

Offer a fallback method. A user who cannot complete one check should be offered another rather than being dropped. Fallbacks recover a meaningful share of abandonments, and they also answer the non discrimination expectation in the EU guidance, since a single method will systematically exclude some populations.

The honest framing for a board is that a check costs signups and the alternative costs 10 per cent of global turnover. That is not a close comparison, and putting the instrumentation in place means the first number stops being a guess within a fortnight.

What age assurance costs, with the hours shown

The rate is $40 to $100 per hour by role. Provider integration and reporting sit near the floor, inference and remediation policy near the ceiling, and mixed teams blend to around $65.

Module	Hours	What it covers
Jurisdiction and gate mapping	40 to 90	Which market, which gate, which threshold, which evidence, held as data
Age assurance provider integration	60 to 130	One or more methods, fallbacks, appeal path, conversion instrumentation
Signal storage and re verification	50 to 110	Bands rather than dates, expiry, provider reference, retention
Existing user remediation	70 to 150	Population estimate, inference triage, prompt campaign, non response policy
Re registration prevention	50 to 110	Purpose limited hashed signal, decay, appeal handling
Evidence and regulator reporting	50 to 100	What was done, to whom, when, regenerable

Worked example. Mapping 65 plus integration 95 plus storage 80 plus remediation 110 plus re registration 80 plus reporting 75 equals 505 hours. That is $20,200 at $40, $50,500 at $100, and about $32,825 at a $65 blend.

The full span across the six modules runs 320 hours at every minimum to 690 at every maximum.

Deliberately excluded: the per check fee charged by your assurance provider, which is usage rather than build, and the support headcount for the remediation campaign. Both are real and both belong in a different column of the budget.

Note the shape. The signup gate that most people scope as the whole project is inside the integration row, at roughly 95 hours. The remediation and re registration rows together are 190. The obligation people skip is twice the size of the one they plan for.

What the evidence pack has to contain

Regulators in all four regimes ask a version of the same question: show us what you did and show us it worked.

Four artifacts answer it.

• A written policy per market, stating the threshold, the accepted methods, the re verification cadence and the appeal route. Dated and versioned, because you will be asked what the policy was in March rather than what it is now.
• Aggregate outcomes over time. Checks attempted, passed, failed, appealed, appeals upheld. Movement matters more than absolute numbers, because a regulator is assessing whether the control is working, and Ofcom's own framing of 25 per cent rising to 43 per cent is exactly this kind of measure.
• The remediation record. How the population was estimated, how many were flagged, prompted, verified, removed, and reinstated on appeal. This is the artifact nobody has, and it is the one that demonstrates the retrospective obligation was taken seriously.
• A circumvention log. Attempts detected, what was done. Not proof of perfection, which nobody expects. Proof of attention, which is what reasonable steps means.

None of that is exotic reporting. All of it needs the underlying events captured from day one, which is why the reporting module sits at 50 to 100 hours rather than being a spreadsheet somebody assembles the week before.

A sequence that reaches a defensible position

Weeks 1 to 2. Jurisdiction mapping and the written policy per market. Cheap, and it prevents building a control for a market that does not require one.

Weeks 2 to 5. Provider integration and the signup gate, with instrumentation on conversion from the first day. You will be asked what the check costs in signups, and a number beats an argument.

Weeks 5 to 7. Signal storage, bands, expiry, and the evidence capture. Before remediation, so the campaign generates a record as it runs.

Weeks 7 to 11. Population estimate and inference triage. Do the estimate before committing to a campaign size, because it changes the support plan by a factor of several.

Weeks 11 to 15. The remediation campaign itself, staged by cohort rather than all at once, with the appeal route staffed from the first batch.

Weeks 15 to 17. Re registration controls, tuned against what the campaign actually surfaced.

Seventeen weeks, roughly 505 hours, and a defensible written position from week two rather than week seventeen. That ordering matters more than the total, because a regulator asking a question in month two gets a policy and a plan rather than silence.