Age Assurance and Children's Design Code Laws: UK, US, AU

Laws protecting children online now come in three shapes, design codes that change how a service treats likely child users, age verification laws that gate specific content, and minimum age laws that bar children from holding accounts at all, and each shape pushes a different age assurance architecture onto the services it covers. This guide explains the three models through the UK Age Appropriate Design Code, US state laws including the 2025 Supreme Court ruling on Texas's age verification law, and Australia's social media minimum age, which applies from 10 December 2025. It then sets out the design decisions that follow: what to check, how strongly, what data to keep, and how to secure the age assurance pipeline itself. It is written for security, identity and privacy leads at online services, and for the teams that build the identity checks behind them.

Source note: Australian requirements are taken from the Australian Government Digital ID System site and from Herbert Smith Freehills Kramer and Corrs Chambers Westgarth summaries; the eSafety Commissioner's pages could not be accessed for this guide. The US Supreme Court ruling is taken from the Congressional Research Service. US state law status is based on named law firm trackers (Loeb & Loeb, June 2026, and Sheppard Mullin, February 2026), which change often. Penalty figures are included only where two independent sources agree. Confirm against the official text before relying on it.

This page covers the laws and what they mean for architecture. Methods, accuracy and vendor selection are in our Age Assurance Guide and Age Assurance buyer's guide; COPPA and the UK code's 15 standards are in the COPPA and Children's Privacy Guide; and Ofcom's "highly effective" age assurance duties are in the UK Online Safety Act guide.

Key takeaways

Three models, three architectures: design codes need a reasonable estimate of age so defaults can change; content gates need a strong, point-in-time check; account minimum ages need checks at sign-up and against existing accounts.
The US constitutional question has shifted: on 27 June 2025 the Supreme Court upheld Texas's age verification law for sites with sexual material harmful to minors, applying intermediate scrutiny (CRS).
Australia restricts how you check, not just whether: platforms must not rely solely on government ID or accredited Digital ID, and age assurance data must not be reused without consent and must be destroyed after use (Digital ID System and HSF Kramer on ID; HSF Kramer and Corrs on data).
Australian penalties are large: up to 150,000 penalty units, about A$49.5 million at the penalty unit value the sources used, for bodies corporate that fail to take reasonable steps (HSF Kramer; Corrs).
Age signals are moving down the stack: US app store accountability laws and California's Digital Age Assurance Act push age checks to app stores and operating systems, so app developers may receive an age signal rather than run a check (Loeb & Loeb).
The age check is a sensitive system: it handles identity documents and face images, so it needs the same protection as any identity proofing service.

The three regulatory models

Model	What it requires	Examples	Architecture it implies
Design code	Treat likely child users differently: high privacy defaults, limits on profiling, geolocation and nudges, impact assessments	UK Age Appropriate Design Code; US state codes such as California AB 2273 and Vermont S 69	Proportionate age estimation or age banding, then different defaults by band; strong checks only where risk is high
Content gate	Verify adult age before access to specific content	Texas HB 1181 and more than 20 similar state laws (CRS); UK Online Safety Act highly effective age assurance	Strong verification or estimation at the point of access, with minimal data returned to the service
Account minimum age	Prevent people under a set age holding accounts, or require parental consent	Australia's under-16 social media minimum age; US state social media laws; app store accountability acts	Checks at sign-up and against the existing user base, with appeal and re-check routes

Many services face more than one model. A social platform available in the UK, US and Australia may need age banding for UK design code defaults, a content gate for adult material, and an account minimum age check for Australian users, all from one identity system.

United Kingdom: the design code model

The ICO describes the Age Appropriate Design Code as a set of 15 flexible standards for online services likely to be accessed by children, with themes including high privacy settings by default, data minimisation, no routine sharing of children's data, geolocation off by default and no nudge techniques that weaken privacy. The code does not require hard identity checks for everyone; standard 3 asks services to take a risk-based approach, establishing age with a level of certainty appropriate to the risks to children from their data processing, or applying the code's standards to all users instead. The Online Safety Act adds a separate, stronger requirement for highly effective age assurance where services allow the most harmful content. For architecture, that means two tiers in the UK: proportionate age assurance to set defaults, and a strong gate where Ofcom's duties apply.

United States: content gates, design codes and app store laws

The Supreme Court on age verification

In Free Speech Coalition v. Paxton, decided on 27 June 2025, the Supreme Court upheld Texas HB 1181, which requires commercial websites where more than one-third of the material is sexual material harmful to minors to verify users' age. The Court applied intermediate scrutiny and found the law readily satisfied it, reasoning that it regulates unprotected activity and only incidentally burdens adults' protected speech (CRS). The CRS notes that more than 20 states have similar laws and that courts may now reconsider how they evaluate social media age laws.

State design codes and social media laws

Sheppard Mullin describes state design codes as mostly modelled on the UK code. Both trackers report that California's AB 2273 has been in litigation since it was passed and that Vermont's S 69 takes effect in 2027. Loeb & Loeb lists further codes and children's privacy laws in states including Connecticut, Colorado, Maryland, Montana, Nebraska and South Carolina, and a long list of state social media laws, many of which have been enjoined in whole or part. Status changes month to month, so treat any snapshot as a starting point and check the current position before a launch.

App store and operating system age signals

Loeb & Loeb describes app store accountability acts in Texas, Utah, Louisiana and Alabama that require app stores to verify age categories and get parental consent before minors download apps, with differing effective dates and litigation. It also reports that California's Digital Age Assurance Act (AB 1043), enacted in October 2025, requires operating system providers to collect user ages and provide age signals, and developers to request them. For app developers this changes the design problem: you may consume an age signal from the platform rather than collect evidence yourself, but you must handle it correctly and keep it consistent with any other checks you run.

Australia: the account minimum age model

The Online Safety Amendment (Social Media Minimum Age) Act 2024 added Part 4A to the Online Safety Act 2021. It received Royal Assent on 10 December 2024 (Corrs), and the obligation applies from 10 December 2025 (Digital ID System). Age-restricted social media platforms must take reasonable steps to prevent people under 16 from having accounts.

Which services: HSF Kramer explains that the definition covers services whose sole or significant purpose is online social interaction, with rule-making powers to exclude categories such as messaging, online gaming and health or education services.
How you may check: platforms must not rely solely on government-issued ID or accredited Digital ID; users must be offered other ways to show they are 16 or over (Digital ID System; HSF Kramer).
What you may do with the data: using or disclosing age assurance information for another purpose without consent, or failing to destroy it after use, is an interference with privacy under the Privacy Act 1988 (HSF Kramer; Corrs).
Penalties: up to 150,000 penalty units, about A$49.5 million, for bodies corporate (HSF Kramer; Corrs).

The destruction rule is the most important design constraint: an Australian age check should be built so that evidence is processed and discarded, keeping only the outcome. See our Online Safety Guide for Teens for the family-facing side.

Architecture decisions the laws force

1. Decide what you need to know

Most laws need an attribute, not an identity: "over 16", "under 18" or an age band. Design the flow to return that attribute and nothing more. Our recommendation is to define, per market and per feature, the attribute required and the minimum confidence, and to record the decision in the DPIA.

2. Match strength to risk

Design codes allow proportionate estimation; content gates usually need strong checks. Use a layered approach: estimation first, stronger methods only for borderline results or high-risk features. Offer alternatives to government ID, which Australia requires and which reduces exclusion everywhere.

3. Keep the evidence away from the service

Where you use a third-party age assurance provider, have it return a signed yes or no, or an age band, so your service never stores the document or face image. Digital identity wallets can prove an age attribute with selective disclosure; see the Digital Identity Wallets Guide.

4. Plan for existing users and re-checks

Minimum age laws apply to accounts that already exist. Build a re-check route that can be triggered by risk signals, and an appeal route for adults wrongly flagged as under age.

5. Treat platform age signals as inputs, not truth

Where app stores or operating systems supply age signals, record the source and the time received, reconcile them with your own checks, and decide in advance which wins when they conflict.

Securing the age assurance pipeline

An age check is an identity proofing system in miniature, and it attracts the same attacks. In our view the controls that matter most are:

Provider credentials: the API keys or client secrets your service uses to call an age assurance provider are non-human identities with access to sensitive results. Store them in a secrets manager, scope them to the age check endpoint, rotate them and alert on unusual call volumes.
Signed results: verify signatures on age tokens returned by providers or wallets, check expiry and audience, and bind the token to the session so a verified result cannot be replayed or shared between accounts.
Webhooks and callbacks: authenticate callbacks from providers; an unauthenticated "age verified" webhook is an easy bypass.
Presentation and injection attacks: require liveness and injection detection for facial estimation; see the Biometric Liveness and Presentation Attack Detection Guide.
Retention: enforce deletion of images and documents in code and in provider contracts, and test it. Australia makes destruction a legal duty.
Phishing: fake age check pages that harvest ID documents are a known risk; publish which provider you use and from which domain.

Common failure patterns

One global age check built for the strictest content gate, applied to every feature, which over-collects data for design code purposes.
Government ID as the only route, which conflicts with Australia's rules and excludes adults without documents.
Age assurance results stored with the evidence, so the check becomes a store of identity documents.
Provider API keys embedded in mobile apps or front-end code.
No plan for existing accounts when a minimum age law takes effect.
Relying on a law firm snapshot of US state law status months after it was written.

Practitioner checklist

Each market and feature is mapped to a model: design code, content gate or account minimum age.
The age attribute and confidence needed are defined and recorded in the DPIA.
At least one alternative to government ID is offered.
The service receives only an age outcome; evidence is deleted after use and deletion is tested.
Provider credentials are vaulted, scoped, rotated and monitored.
Age tokens and callbacks are signed, verified, time-limited and bound to the session.
Re-check and appeal routes exist for existing users.
US state law status is reviewed at least quarterly.

Standards and references

Related NHI Mgmt Group resources: Age Assurance Guide · COPPA and Children's Privacy Guide · UK Online Safety Act · Digital Services Act Security Obligations Guide. This guide summarises children's online safety and age assurance laws as at November 2026 and is not legal advice.

Age Assurance and Children’s Design Codes: How UK, US and Australian Laws Shape Your Age Check Architecture