Every children's regime eventually asks the same question: how does the service know a user is a child? The answers range from a birth date typed into a form to a passport photo matched against a live selfie. This article compares the four families of method, self-declaration, age estimation, age verification and parental attestation, and sets out what the UK Children's Code, the UK Online Safety Act and the EU Digital Services Act each expect. It is written for product, privacy and trust-and-safety leads who have to pick a method and defend the choice. The recurring theme is proportionality: the method should match the risk, and no method should collect more data than that risk justifies.
The four families
Self-declaration. The user states their age or confirms they are over a threshold. It costs nothing, collects almost nothing, and is trivially defeated. Its value is not in stopping a determined child but in avoiding the design error of nudging a child to lie: a neutral age screen that does not signal the "right" answer is what COPPA's mixed-audience guidance expects, and a service that then applies a declared under-age result honestly gains real information from the users who tell the truth.
Age estimation. The service infers an age or an age range from a signal, without establishing identity. Facial age estimation from a selfie is the best known; estimation from voice, from typing or interaction patterns, or from an email address's history are others. Accuracy is a distribution, not a yes or no: an estimator that is reliable at telling a 10-year-old from a 25-year-old may be poor at the 17 to 19 boundary. A buffer above the threshold is the standard mitigation. Estimation from behavioural data is itself profiling and raises its own data protection questions.
Age verification. The service confirms age by reference to an authoritative source: a government identity document, a credit card that only adults can hold, a mobile network operator's record, a bank through open banking, or a digital identity wallet. It is the most accurate family and the most expensive in data, friction and exclusion, since not every adult has a document or an account, and the data involved is sensitive. Deletion immediately after the check, and use of a third party that returns only a yes or no, are the standard mitigations.
Parental attestation. A parent confirms the child's age or gives consent for the child's use. This is the COPPA model, where the method has to verify that the person is the parent, and it is also a route the UK code names as account holder confirmation. It works where a parent is genuinely in the loop, such as a young child's device, and fails where a teenager is the account holder in practice. The COPPA consent methods guide covers the accepted verification methods in detail.
What the UK Children's Code expects
Standard 3 of the code asks a service to establish age with a level of certainty appropriate to the risks that arise from its data processing, or to apply the code's standards to all users instead. The ICO's list of approaches includes self-declaration, artificial intelligence estimation, third-party age verification services, account holder confirmation, technical measures and hard identifiers. The point is the fork: a low-risk service can accept self-declaration and design for everyone; a service that profiles, shares data or exposes children to contact needs more certainty. A service that cannot justify its method should choose the second branch and apply the protections to all users, which is often the cheaper and more honest answer.
What the UK Online Safety Act expects
The Act uses a higher bar where the harm is greatest. Services that allow pornographic content or other primary priority content harmful to children must use age assurance that is highly effective at correctly determining whether a user is a child. Ofcom's guidance describes the criteria as technically accurate, robust, reliable and fair, and lists methods capable of meeting them: photo identification matching, facial age estimation, mobile network operator checks, credit card checks, digital identity services, open banking and email-based age estimation. Self-declaration and debit card checks do not qualify. For the rest of the children's duties, the Act asks the service to consider age groups and to take proportionate measures, which leaves room for estimation and for applying protections broadly. The children's duties guide sets out the sequence.
What the EU Digital Services Act expects
Article 28(1) requires appropriate and proportionate measures for the privacy, safety and security of minors, and Article 28(3) says compliance must not oblige a platform to process additional personal data to assess whether a recipient is a minor. The Commission's July 2025 guidelines then set the expectation by risk: verification where the risk is high, for instance content restricted to adults by law; estimation where the risk is medium; and self-declaration not sufficient on its own for the higher-risk cases. The Commission's EU age verification app is intended as a privacy-preserving reference method that proves an age threshold without revealing identity. The reader should verify the guidelines' specifics before relying on them; the Article 28 guide covers the themes.
Proportionality and data minimisation
Three regimes, one principle. The strength of the method should rise with the risk to the child, and the data collected should be the minimum the method needs. That yields a practical order of preference. First, ask whether the service can simply apply children's protections to everyone and avoid the question. Second, if a threshold matters, use a method that returns a yes or no rather than a date of birth or a document. Third, delete verification data as soon as the check completes and keep only the result. Fourth, offer more than one method, because every method excludes someone. Fifth, document the choice, the accuracy evidence and the review date. ISO/IEC 27566, which the explorer also covers, provides a vocabulary for describing assurance levels and is a useful way to write that documentation.
A worked example
Lanternfield, a fictional company, runs a music practice app for 8 to 16 year olds and an adult community forum under the same brand. For the practice app the team applies the code's protections to every account and uses a neutral age screen only to select the age-banded interface; no verification data is collected. For the forum, which allows adult-only discussion threads, the team needs a highly effective method under the UK Act. It contracts a third-party service offering facial age estimation with a buffer at 25, and photo identification matching as an alternative for users the estimator cannot place, receiving only a pass or fail and no image or document. The forum records the accuracy figures the vendor publishes and sets a review for twelve months. The two products share one written age assurance policy.
How Landfall helps
Landfall asks about the age assurance in place as a questionnaire input rather than assuming one, and the answer decides which obligations fire across the children's frameworks: the code's standard 3 fork, the Act's highly effective age assurance items where primary priority content is declared, and the DSA's proportionality and data minimisation limbs. The generated backlog shows the same design decision once, with the citations from each framework attached, so a team is not asked to justify the method three times. Browse the underlying obligations in the UK AADC, UK OSA and EU DSA explorers.