Does Australia's Under-16 Social Media Law Apply to Your App?

Does Australia's Under-16 Social Media Law Apply to Your App?

Probably not - but the reason matters more than the answer. Australia's under-16 restrictions apply to services whose sole or significant purpose is online social interaction, and the named platforms published so far are the large consumer networks: Facebook, Instagram, Kick, Reddit, Snapchat, Threads, TikTok, Twitch, X and YouTube. Most products we are asked about are not on that list and are not close to it. But the law is written as a functional test rather than a fixed register, so "we are not on the list" is a statement about today, not a design decision you can build on.

This matters because the obligation sits on the platform, not on parents or on young users, and the penalty for getting it wrong reaches $49.5 million. If your product has a feed, profiles and follows, the sensible position is to understand the test rather than assume the list protects you.

What the law actually restricts

The Online Safety Amendment (Social Media Minimum Age) Act 2024 took effect on 10 December 2025. It requires providers of age-restricted social media platforms to take reasonable steps to prevent Australians under 16 from creating or keeping an account. It does not ban under-16s from the internet, it does not penalise young people or their parents, and it does not require every app in the App Store to check identity documents.

The regulator is the eSafety Commissioner, which published a compliance update in March 2026 and has since opened investigations into platforms it considers are not meeting the standard. The enforcement posture is active rather than theoretical, which is worth knowing before deciding this is a problem for later.

The functional test is what decides your app

The restriction attaches to a service where online social interaction is the sole or a significant purpose. In practice the features that pull an app toward the restricted side are the ones that make it a social network rather than a tool:

  • public or semi-public user profiles
  • posting and sharing content to an audience beyond a chosen recipient
  • following, friending or other one-to-many connection graphs
  • a feed, and engagement mechanics such as likes and public comments

The features that pull an app away from it are equally clear. Messaging, voice and video calling, online gaming, professional networking, and services whose primary purpose is education or health support are outside the restriction. So is a service that mainly provides information about products or services.

The distinction is not about how social an app feels. It is about whether social interaction between users is the point of the product, or a supporting feature of something else. A fitness app with a community tab is a fitness app. A community platform with a workout library is a different proposition, and the honest answer about which one you are building is usually obvious to the team and occasionally uncomfortable.

What "reasonable steps" means when you are the one building it

The phrase doing the work is reasonable steps, and the guidance has been explicit that self-declared age alone is not enough. A date-of-birth field with no verification behind it is the exact pattern the law was written to end.

For a build, that translates into a small number of concrete decisions:

  • Age assurance is a system, not a field. It has to be applied at account creation and at re-entry, and it has to survive a user deleting and recreating an account.
  • You have to be able to prove what you did. Reasonable steps is an evidentiary standard, so the age-assurance decision needs to be logged and reportable, not just enforced in the interface.
  • Age data is sensitive data. Collecting more identity information to satisfy one obligation creates a privacy obligation under the Privacy Act 1988 and the Australian Privacy Principles. The Office of the Australian Information Commissioner has published specific guidance on this, and the wrong answer is to retain identity documents you did not need.
  • It is a product decision before it is a technical one. Every age check is friction on the signup funnel, and where you put it changes your conversion rate. That is a decision for the product owner, not something to discover after launch.

What to design now, even if you are clearly out of scope

The reason we raise this with clients who are plainly not caught is that the underlying direction is not in dispute. Age assurance is moving from an edge case to an expected capability, and the products that will handle it cheaply are the ones that separated identity, account and profile early.

The pattern that survives is unglamorous: keep age and identity attributes in one place rather than scattered through the user record, make the account lifecycle explicit so deletion and recreation are observable, and treat the social graph as a feature you can gate rather than an assumption baked through every query. Retrofitting that into a platform that assumed every account is equal is the expensive version, and it is the version we usually meet.

We have rescued 15+ platforms in the past 3 years, and the pattern is consistent - the cost is rarely the feature itself, it is that the original architecture made the feature structurally hard to add. Crash rates typically come down 50 to 70 percent within 2 weeks once that is addressed, and feature development runs 60 to 80 percent faster after modernisation. Age assurance is simply the newest example of a requirement that is cheap when the foundation anticipated it and expensive when it did not.

Where the line is on advice

We build to regulatory requirements and we have done it repeatedly, including products handling patient and financial data and a field platform for Flinders University carrying forensic-grade chain-of-custody. What we do not do is tell you whether your service meets a legal definition. That is a question for your lawyer, and where formal verification is required we bring in an independent third party rather than assessing our own work. That is deliberate - it is not good practice for the same team to build a system and certify it, and an independent assessor produces a result that stands up to scrutiny.

If you are scoping a product with a social graph and want the architecture to survive the next version of this legislation, talk to us. If you are further back and still shaping the idea, our community platform and social and dating app work is the closest reference point.

Frequently asked questions

Almost certainly not. The restriction applies where online social interaction is the sole or a significant purpose of the service. A community feature inside a fitness, education or commerce product is a supporting feature, not the purpose of the product. The test to apply honestly is what your app is for - if you removed the social features and the product still made sense, you are on the safe side of the line.

No. The guidance has been explicit that platforms cannot rely on self-declared age alone, and an unverified date-of-birth field is the pattern the law was written to end. Reasonable steps means an age-assurance approach that is applied consistently, survives account deletion and recreation, and can be evidenced afterwards.

It depends almost entirely on whether the platform was designed with it in mind. Adding an age-assurance step to a system that already separates identity, account and profile is a contained piece of work. Retrofitting it into a platform where the social graph is assumed throughout is a structural change, and that is where the cost lands. This is the single biggest variable, and it is decided at architecture time rather than at implementation time.

Collecting more identity information than you need creates a privacy obligation under the Privacy Act 1988 and the Australian Privacy Principles, and identity documents you retain are a liability rather than a protection. The better question is what is the minimum attribute you need to establish, and what is the shortest time you need to hold anything that proves it.

No, and you should be cautious of any development partner who says otherwise. Whether a service meets a legal definition is a question for your lawyer. What we can do is build the platform so that the answer is implementable either way, and where formal verification is required we bring in an independent third party rather than assessing our own work.