Age Assurance for the Children’s Online Privacy Code and Social Media Minimum Age

Australia has told platforms to keep under-16s off social media without telling them how. The wrong way to comply is to build an identity-collection layer that becomes its own liability the day it is breached.

The Online Safety Amendment (Social Media Minimum Age) Act 2024 has been in force since 10 December 2025. It requires age-restricted platforms to take reasonable steps to stop under-16s holding accounts, on pain of civil penalties up to A$49.5 million. A second obligation is close behind: the Children’s Online Privacy Code, made under the Privacy and Other Legislation Amendment Act 2024, which must be finalised and registered by 10 December 2026. Both push the same hard problem onto the technology function — age assurance that is effective enough to satisfy a regulator and restrained enough not to create a fresh privacy catastrophe. Those two goals pull in opposite directions, and that tension is the whole engineering problem.

What the law requires, and what it deliberately does not

The minimum age is 16. The duty is to take “reasonable steps”, and the statute prescribes no method for meeting it. The eSafety Commissioner has been explicit that there is no legally enforceable effectiveness standard — no accuracy percentage you can hit and declare yourself safe. That is a process obligation dressed as an outcome, and it changes how you have to build.

The restricted set, as the Commissioner has scoped it, includes Facebook, Instagram, Threads, TikTok, Snapchat, YouTube, X, Reddit, Kick and Twitch. Services such as Discord, GitHub, Google Classroom, Messenger, Roblox, Steam and YouTube Kids sit outside it. The first engineering question, before any of this, is whether your service is even in scope — the boundary is not intuitive, and it moves.

What the Act does specify is restraint. If a platform collects government-issued or digital ID to determine age, it must also offer a method that does not depend on the user having ID at all. Information collected for age assurance must be destroyed once it has served that purpose, and it cannot be repurposed without consent. The statute, in other words, tells you to minimise. The Children’s Online Privacy Code will sharpen this further, layering data-minimisation and default-setting duties on services likely to be accessed by children. Read together, the law wants you to know a user is old enough — and to know almost nothing else.

The methods, and where each one breaks

The Age Assurance Technology Trial commissioned by the Australian government concluded that age assurance can be done privately, efficiently and effectively, and — importantly — that there is no one-size-fits-all solution. That second finding is the one to internalise. There are three families of technique, and each fails in a different place.

Age verification checks a document or a verified date of birth. It is the most accurate and the most tempting, because it feels defensible. It is also the most collecting: it draws in exactly the identity data the rest of the law is telling you to avoid, and it excludes anyone without ID. Reach for it as your primary gate and you have built a honeypot.

Age estimation — typically facial analysis from a selfie — was found in the trial to perform broadly consistently across demographic groups within stated tolerances. The catch is structural: the error margin is widest precisely at the boundary that matters. A confident 24-versus-14 call is easy; a 15-versus-16 call is not, because a 15-year-old and a 16-year-old look alike. Any estimation gate therefore needs a buffer band around the threshold and a fallback route for anyone who lands in it, or it will wrongly admit and wrongly exclude in roughly equal measure at the exact age you care about.

Age inference from behavioural and account signals is the least intrusive and the least reliable on its own. It is useful as a corroborating layer, not as the decision. The trial’s endorsement of successive validation — combining methods rather than betting on one — is the honest engineering answer: estimation first for most users, a fallback for the buffer band, inference as a cross-check, and hard verification reserved for the narrow set who need it and who have chosen it.

The architecture that avoids the honeypot

The mistake is to treat age assurance as something your platform does. It should be something your platform receives the result of. Delegate the check to a separate, accredited provider and have it return a signed attestation — a claim that the user is over 16 — and nothing else. The platform never sees the selfie, the document or the date of birth. The provider, given a blinded session, never learns which platform or which user it just checked. That is the double-blind pattern, and it is what lets you satisfy the assurance duty without accumulating the evidence that makes you a target.

Store the minimum: the attestation identifier and its expiry, not the material that produced it. Destroy the biometric or document the moment the claim is issued, which is what the Act requires in any case. This is the same discipline as engineering a data obligation into the product by design rather than bolting a collection form onto the front of it — the obligation shapes the data model, not the login screen.

# Age-assurance flow: the platform never stores raw ID or biometric.
# It delegates the check to an accredited provider and keeps only a
# signed attestation ("over 16") plus its expiry. Double-blind: the
# provider sees no platform user ID; the platform sees no evidence.

import json, time
from jwcrypto import jwt, jwk

PROVIDER_KEY = jwk.JWK.from_json(open("provider_public.jwk").read())
MIN_AGE_CLAIM = "age_over_16"

def verify_attestation(token: str, expected_nonce: str) -> bool:
    """Accept only a fresh, provider-signed 'over 16' claim.

    Raises on any signature or freshness failure -- we never fall
    back to trusting an unverified token. No date of birth is read.
    """
    verified = jwt.JWT(key=PROVIDER_KEY, jwt=token)
    claims = json.loads(verified.claims)

    if claims.get("nonce") != expected_nonce:      # replay protection
        raise ValueError("nonce mismatch")
    if claims.get(MIN_AGE_CLAIM) is not True:      # a boolean, not an age
        return False
    if claims["exp"] < time.time():
        raise ValueError("attestation expired")
    return True

def record_result(account_id: str, token_id: str, expiry: int) -> dict:
    # Persist the minimum: which attestation, when it lapses. No selfie,
    # no document image, no date of birth. Nothing to breach later.
    return {
        "account_id": account_id,
        "attestation_id": token_id,   # opaque, non-reversible
        "verified_over_16": True,
        "expires_at": expiry,
    }

The shape matters more than the library. A boolean claim, a signature you verify, a short expiry, and a hard failure path that never degrades to trusting an unchecked token. If a breach of this store leaks anything worse than “account X was attested over-16 until date Y”, the architecture is wrong.

The evidence a regulator will actually ask for

Because “reasonable steps” is a process standard, you are evidencing a decision, not a hit rate. Document which methods you chose and why, the tolerance band you set around the threshold, the fallback for users who fall into it, the accessibility of the flow for people who cannot complete a selfie check, and your retention position — which should read “zero raw evidence retained”. That written trail is the equivalent of an accessibility conformance report: evidence you can actually defend when someone tests it, rather than an assertion that you tried.

The firms that will struggle are the ones that treated this as an identity project and stood up a verification wall. They will pass the assurance question and fail the privacy one, and the Children’s Online Privacy Code is being written precisely to catch that failure. The firms that will be fine built the gate to know one thing, prove they know it, and forget everything else by design.

The regulator is not asking you to identify your users. It is asking you to be sure of a single fact and to hold nothing you cannot defend keeping. Collect more than that, and you have not over-complied — you have manufactured the next incident.