Australia’s Online Safety Codes: Age Assurance and Content Duties for Designated Services

The Australian social-media minimum-age rule got the headlines. The industry codes sitting behind it are the part that will actually change how you build your service — and they ask for detection, age assurance and reporting, not just a birthday field.

If your only mental model of Australian online-safety regulation is “under-16s off social media”, you have read the press release and skipped the regulation. The eSafety Commissioner’s industry codes and standards, made under the Online Safety Act 2021, reach a much wider set of services than the big social platforms, and they impose obligations — content detection, access controls, age assurance, annual reporting — that a minimum-age gate does not begin to satisfy. This is a reading for the people who have to decide what to build, on what timeline, for a service that may be caught without anyone in the business having noticed.

Codes and standards are two instruments, not one

The first thing to get straight is that there are two kinds of instrument, and the difference matters. A code is drafted by industry and registered by eSafety. A standard is a legislative instrument that eSafety writes itself, used where the regulator judged an industry-drafted code inadequate. Where both could apply, the standard prevails. In practice that means the Designated Internet Services Standard and the Relevant Electronic Services Standard — the two areas eSafety took over directly — carry the sharpest obligations, and they are law, not guidance.

The scheme also splits by content class. Phase 1 covers the most serious “class 1A” and “class 1B” material — child sexual exploitation, pro-terror content, extreme crime and violence, and the like. Phase 2 covers “class 1C” and “class 2” material: online pornography, other sexually explicit material, high-impact violence and simulated gambling — the age-inappropriate rather than the plainly unlawful. The Phase 1 instruments have been in force in stages, with the Designated Internet Services and Relevant Electronic Services Standards commencing in December 2024. The Phase 2 age-restricted codes are the ones now landing: the first tranche commenced late December 2025 and the remainder on 9 March 2026. That is the deadline your programme is really working to.

First job: work out which section catches you

The codes divide the online industry into eight sections. Most firms assume they fall into none of them, and most firms are wrong. The sections are:

• Social media services
• Relevant electronic services — messaging, chat, and interactive functions, including chat inside games
• Designated internet services — the broad catch-all for websites and apps that are not social media or messaging
• Search engine services
• App distribution services
• Hosting services
• Internet carriage services
• Equipment — device manufacturers and suppliers

The “designated internet services” category is deliberately wide. A subscription content site, a storage-and-sharing app, a forum, a gaming platform with a store attached — these are not social networks in the ordinary sense, but they sit squarely inside the scheme. The mapping exercise is not academic. It determines which instrument binds you, what you must build, and by when. Do it as a documented assessment, signed off, not as a hallway conversation, because it is the first thing eSafety will ask you to show.

Age assurance is a control you have to evidence

The Phase 2 codes are explicit that self-declaration — a checkbox asserting “I am over 18” — does not count as age assurance. eSafety points to methods it regards as capable of doing the job: facial age estimation, credit-card checks, and photo-identification matching, with digital identity another route. The obligation is not merely to deploy one of these; it is to test and monitor that it actually works, and to keep the evidence. An age-assurance measure you cannot demonstrate the effectiveness of is, for regulatory purposes, an age-assurance measure you do not have.

This is where the architecture decisions bite. Facial age estimation raises biometric and data-minimisation questions of its own. Identity verification pulls in the same privacy and retention considerations that sit behind Australia’s own digital-identity work — a subject we cover in more depth in the reading on the Digital ID Act 2024 and the Government Digital ID System. The broader design tension — proving age without hoarding sensitive data, and choosing a method proportionate to the risk of the content behind the gate — is the same one we work through for the Children’s Online Privacy Code and the social-media minimum age. The engineering answer is rarely to build your own; it is to select an accredited provider and integrate it so the sensitive data never lands in your estate.

Detection and access controls go past the gate

An age gate answers one question: is this user old enough. The codes ask several more. Where a service permits age-restricted material, it has to combine age assurance with access controls — defaults, parental controls, feature restrictions — and monitor that they hold. Where the material is not permitted at all but the risk of it appearing is real, the service is expected to run systems that detect and remove it. That is a detection-and-response capability, not a registration form: content classification, flagging, escalation and takedown, with the ability to reconstruct what happened after the fact.

The codes lean on a risk-tiering logic — services self-assess into higher or lower risk bands, and the obligations scale with the band. That is sensible in principle and a trap in practice, because the tier you assign yourself is a claim you will have to defend. Under-tiering to reduce your build is the kind of decision that reads badly in an enforcement file. Tier honestly, document why, and size the controls to match.

The reporting duty is the one firms forget

Detection and age assurance are the visible obligations. The quieter one is reporting. Services identified by eSafety can be required to report periodically on how they are meeting their obligations, and providers are expected to notify the regulator of material changes that shift their risk profile. Unresolved user complaints can be escalated to eSafety. This is the part that turns a one-off compliance build into an operating capability: someone owns the annual return, the change-notification trigger, and the complaints pipeline, and can produce the evidence on demand. Enforcement is not theoretical either — the civil penalties for breach run into the tens of millions of dollars for a body corporate, alongside formal warnings, directions and enforceable undertakings.

The playbook, in order

1. Map every service you operate against the eight sections, and write the assessment down.
2. Identify whether a code or a standard binds each service, and which content classes are in play.
3. Assign a risk tier you can defend, with the reasoning recorded.
4. Select an accredited age-assurance method proportionate to the content, and integrate it so sensitive data stays out of your systems.
5. Build the detection, access-control and takedown capability, and the logging to evidence it.
6. Stand up the reporting, change-notification and complaints processes, with a named owner.

The minimum-age rule is a line in a statute. The codes are an operating obligation, and they do not care how good your launch demo looked. If your service is caught and your answer to “show us it works” is a birthday field and a policy PDF, you are not compliant — you are hoping nobody asks.