Talk to usTry the demo

Age Assurance and Age Verification: What Regulators Ask

Regulation and standards

For: Product owner or compliance lead of an online service that must restrict access by age

A product owner's reading of what the EU, the UK, Australia and France ask of a service that checks age: definitions, risk-based duties, privacy principles and the methods regulators discuss.

For information; not legal advice.

You run or build an online service that has to keep children away from certain content, accounts or features, and you want to know what regulators actually ask when they say "age assurance". This article reads the primary texts and regulator pages of the European Union, the United Kingdom, Australia and France and answers one question: which definitions, duties, privacy principles and method choices do these authorities put in front of a service that checks age?

One word, three techniques

Regulators use "age assurance" as an umbrella. The European Data Protection Board takes the term from a research report on age assurance typologies and defines it in its own statement as the umbrella term for the methods used to determine the age or age range of an individual to varying levels of confidence or certainty. The same statement names three primary categories of age assurance: age estimation, age verification and self-declaration.

The United Kingdom writes the same split into statute. Section 230 of the Online Safety Act 2023 defines the two terms for the purposes of the Act:

"Age verification" means any measure designed to verify the exact age of users of a regulated service.

"Age estimation" means any measure designed to estimate the age or age-range of users of a regulated service.

The section then adds a rule that matters for product design:

A measure which requires a user to self-declare their age (without more) is not to be regarded as age verification or age estimation.

Read together, these texts give a working vocabulary. Verification aims at an exact age, estimation at an age or an age range, and a bare statement by the user is, in the UK statute, neither of the two. The EDPB adds that robustness has little meaning for self-declaration, since the reliability of that method depends mostly on the goodwill of the user.

The European Union

The duty and the guidelines

The starting point in EU law is a duty for platforms. Article 28(1) of the Digital Services Act requires providers of online platforms accessible to minors to put in place appropriate and proportionate measures to ensure a high level of privacy, safety and security of minors on their service. Article 28(2) bars those providers from presenting advertisements based on profiling, using personal data of the recipient of the service, when they are aware with reasonable certainty that the recipient is a minor. Article 28(3) says that compliance with the obligations of the Article shall not oblige providers to process additional personal data in order to assess whether the recipient of the service is a minor. Article 28(4) allows the Commission, after consulting the Board, to issue guidelines to assist providers in the application of paragraph 1.

On 14 July 2025 the European Commission published guidelines on the protection of minors under the Digital Services Act. The Commission describes them as a non-exhaustive list of proportionate and appropriate measures. They apply to all online platforms accessible to minors, with the exception of micro and small enterprises. The Commission says it will use the guidelines to assess compliance with Article 28(1) and that following them is voluntary and does not automatically guarantee compliance. The same page states that the guidelines, like the Act, adopt a risk-based approach, because platforms may pose different risks to minors depending on their nature, size, purpose and user base.

Which technique for which risk

The Commission's summary recommends effective age assurance methods provided that they are accurate, reliable, robust, non-intrusive and non-discriminatory. It recommends age verification methods to restrict access to adult content such as pornography and gambling, or when national rules set a minimum age to access certain services, such as defined categories of online social media services. It recommends age estimation in other cases, such as when terms and conditions prescribe a minimum age lower than 18 because of identified risks to minors.

The text of the guidelines was not opened for this article, so the description above is limited to the Commission's own summary page.

The blueprint and the wallet

The Commission's own page on its approach to age verification describes the practical side. It states that the Commission made available a blueprint for an age verification solution on 14 July 2025 and that the solution became feature ready on 15 April 2026. According to that page, the solution allows users to prove they are over 18 without sharing any other personal information, and it can be adapted to other age ranges, for example 13+ or 65+. It is built on the same technical specifications as the European Digital Identity Wallets that are to be rolled out by the end of 2026 in all Member States. The Commission has also adopted a recommendation that lays down actions for Member States to roll out age verification by the end of 2026, including using the blueprint, drawing up implementation plans and ensuring compliance with relevant cybersecurity and privacy standards through third-party scrutiny. The page adds that the Commission will create an EU Age Verification Scheme, with a list of trusted proof-of-age providers and a list of trusted age verification solutions.

The same page records a legislative proposal. It states that in September 2026 the Commission adopted a proposal for the EU KIDS Act, which requires digital services to be safe by design and sets 15 as the minimum age to create an independent account. A proposal is not law, so treat it as a signal of direction and not as a duty.

The data protection layer: the EDPB statement

Age assurance processes personal data, and sometimes biometric data. The EDPB adopted Statement 1/2025 on age assurance on 11 February 2025 to set out high-level principles from the General Data Protection Regulation. It lists ten principles. The following reading follows its headings.

Rights, proportionality and risk

The statement opens with the full and effective enjoyment of rights and freedoms and then turns to proportionality. In its words, age assurance should always be implemented in a risk-based and proportionate manner that is compatible with natural persons' rights and freedoms. It states that in many cases age assurance poses a high risk to the rights and freedoms of data subjects, which would require a Data Protection Impact Assessment under Article 35 of the GDPR before processing. It gives a concrete example of failing the test:

a service provider processing personal data to check the age of all their users when accessing all their content or services, even when the content or services are suitable for all audiences and devoid of any risk, would not pass the necessity and proportionality tests.

No extra means of identification or tracking

The second principle is the prevention of data protection risks. Age assurance, the statement says, should not provide additional means for service providers to identify, locate, profile or track natural persons. A person required to verify their age to access adult content would not expect the provider to use age assurance to determine their identity or precise geographical location. The statement also says that the age assurance process should not enable the further targeting or profiling of users, for commercial purposes such as personalised advertisements and for malicious ones such as grooming, bullying, stalking or harassment. It asks for viable alternatives for users who cannot or do not wish to use a specific method.

Purpose limitation and minimisation

The statement says that providers and third parties should only process the age-related attributes that are strictly necessary for their specified, explicit and legitimate purpose. It defines an age-related attribute as any attribute indicating that a natural person is a certain age, over or under a certain age or within an age range. Its example of minimisation is a threshold result: the service provider may only need to know whether the user is over or under an age threshold, which could be implemented by a tokenised approach based on the participation of a third-party provider, in which the service provider only sees the functional result.

Effectiveness, in three parts

The fifth principle asks that age assurance demonstrably achieve a level of effectiveness adequate to its purpose. The statement evaluates effectiveness on accessibility, reliability and robustness. On accessibility, it says that where certain categories of individuals are at risk of being discriminated against by a method, for example because they do not own a suitable identity document or mobile phone or because of a disability, alternative methods should be made available when reasonably possible. On reliability, it ties the requirement to the accuracy principle of Article 5(1)(d) of the GDPR and asks for appropriate redress mechanisms when users can be significantly affected by automated decision-making. On robustness, it says that age assurance should be able to deal with unexpected situations and resist reasonably likely attempts to trick or bypass the system.

Lawfulness, transparency and automated decisions

The statement requires an applicable legal basis under Article 6 of the GDPR and, if relevant, an exception under Article 9(2). It lists what users must be told before any personal data is processed for age assurance: what data will be processed and how, whether third parties are involved and who they are, whether data will be shared or transferred to a third country, how long data is retained or the criteria for the retention period, and what rights users have, including how to challenge an incorrect decision. It warns that fully automated age assurance can produce legal effects or similarly significant effects, and it asks providers to offer remedies and redress mechanisms for users whose age-related attributes are not properly established.

Design, security and accountability

On data protection by design and by default, the statement recommends giving due consideration to technologies and architectures that favour user-held data and secure local processing, allowing unlinkability and selective disclosure under the control of the data subject. It adds that approaches such as batch issuance of single-use credentials or zero-knowledge proofs should be made available where age assurance may involve high risks to privacy. On security, it says that fulfilling the storage limitation principle and using short retention periods may be essential, and that a no-log policy may be a valuable safeguard, meaning that once the user's age is verified, no record of the personal data used for the process is kept. The last principle is accountability: age assurance should operate under a governance framework in which all processes and systems are designed, implemented, revised, documented, assessed, used, maintained, tested or audited so that they meet data protection regulations and other legal requirements.

Separate from age assurance for access control, the GDPR sets an age for consent. Article 8(1) provides that where consent is the legal basis and an information society service is offered directly to a child, the processing is lawful where the child is at least 16 years old, and below that age only if consent is given or authorised by the holder of parental responsibility. Member States may provide by law for a lower age, provided it is not below 13 years. Article 8(2) then says:

The controller shall make reasonable efforts to verify in such cases that consent is given or authorised by the holder of parental responsibility over the child, taking into consideration available technology.

The United Kingdom

The statute: highly effective

The Online Safety Act 2023 creates safety duties protecting children for regulated user-to-user services likely to be accessed by children. Section 12(3) requires proportionate systems and processes designed to prevent children of any age from encountering primary priority content that is harmful to children. Section 12(4) then ties that duty to age assurance techniques:

The duty set out in subsection (3)(a) requires a provider to use age verification or age estimation (or both) to prevent children of any age from encountering primary priority content that is harmful to children which the provider identifies on the service.

Section 12(5) removes the requirement where a term of service prohibits that kind of content for all users. Where the requirement does apply, the quality bar is in subsection (6):

the age verification or age estimation must be of such a kind, and used in such a way, that it is highly effective at correctly determining whether or not a particular user is a child.

Subsection (7) adds that age verification or age estimation to identify who is or is not a child user, or which age group a child user is in, are examples of measures that may be taken for compliance with other duties even when subsection (4) does not require them. The statute therefore does three things at once: it names the two techniques, it makes at least one of them mandatory for the category it calls primary priority content, and it sets an outcome standard instead of a list of approved products.

The data protection regulator: how certain, and what for

The Information Commissioner's Office takes a different angle in its Age Appropriate Design Code, which addresses the personal data of children. Its standard on age appropriate application tells services to take a risk-based approach to recognising the age of individual users. A service should either establish age with a level of certainty that is appropriate to the risks to the rights and freedoms of children arising from its data processing, or apply the standards of the code to all its users instead.

The code lists methods and says that the list is not exhaustive. It names self-declaration, which it says may be suitable for low risk processing or when used together with other techniques. It names the use of artificial intelligence to estimate age from how the user interacts with a service, with three conditions: tell users upfront, collect only the minimum amount of personal data needed, and do not use the data for other purposes. It names third party age verification services that typically work on an attribute basis, where the service provides a yes or no answer, which reduces the personal data the service has to collect itself. It names confirmation by an existing account holder known to be an adult, technical measures that discourage false declarations, and hard identifiers such as a passport. On hard identifiers its advice is cautious: the ICO recommends avoiding giving users no choice but to provide them unless the risks of the processing really warrant it, because some children do not have access to formal identity documents and requiring them may have a disproportionate impact on the privacy of adults.

The ICO also acknowledges a tension. It recognises that age assurance could increase the risk of intrusive data collection, says it does not require organisations to create these counter risks, and concludes that age assurance and the GDPR are compatible if privacy by design solutions are used.

Australia: reasonable steps for under 16s

Australia's approach is a minimum age for accounts. The eSafety Commissioner states that as of 10 December 2025 age-restricted social media platforms need to take reasonable steps to prevent Australians under the age of 16 from creating or keeping an account. It describes the measure as a delay to having accounts and not a ban, and it says there are no penalties for under-16s who access an age-restricted platform or for their parents or carers. Platforms may face civil penalties if a court finds they have not taken reasonable steps, with fines of up to 300,000 penalty units for corporations, currently equivalent to $109.2 million AUD.

On method choice, eSafety published regulatory guidance to help platforms decide which methods are likely to be effective and to comply with the Online Safety Act. It says the guidance draws on the Australian Government's Age Assurance Technology Trial and on stakeholder consultations. For a product team the lesson is the same as in Europe: the legal duty is framed as an outcome, reasonable steps, and the method is left to the platform, to be judged against guidance and evidence. The page adds that a compliance update of March 2026 was informed by compulsory information-gathering notices given to the 10 age-restricted platforms publicly identified by eSafety. Regulators in this model will ask a platform for evidence of what it did.

France: the CNIL on methods and trust

The French data protection authority, the CNIL, published an analysis of the main types of age verification systems on 22 September 2022. Its page is older than the texts above, so read it as the position published on that date and check for newer French guidance before relying on it. It remains useful because it compares methods one by one and states its criteria clearly.

Principles

The CNIL recalls its recommendation that age verification systems be structured around six pillars: minimisation, proportionality, robustness, simplicity, standardisation and third-party intervention. For sites that disseminate pornographic content, it set out three principles in an opinion of 3 June 2021: no direct collection of identity documentation by the publisher of the site, no age estimates based on the user's web browsing history, and no processing of biometric data for the purpose of uniquely identifying or authenticating a natural person, for example by comparing a photograph on an identity document with a selfie through facial recognition.

The CNIL also recommends a trusted independent third party. Age verification, in its model, is divided into the issuance of a proof of age and the transmission of that proof to the site, so that the entity providing the proof knows the identity of the user but not which site the user visits, and the site knows the age or the majority of the user but not the identity.

The methods compared

The CNIL lists several solutions in decreasing order of maturity from its point of view. Payment card validation relies on infrastructure already deployed, but it is circumventable because minors may hold payment cards, and it is not accessible to all because some adults may not have such a card. Age estimation based on facial analysis is described as often sufficient to keep young people away from an adults-only service because the margin of error is concentrated on minors close to 18 years of age and on young adults, but it needs an alternative method for people who dispute the estimate and should be conditional on operating, reliability and performance standards that are independently verified. The CNIL prefers that an age estimate performed locally on the user's own device be favoured to minimise the risk of data leakage.

Analysis of identity documents is treated in two steps. A system that only analyses a document copy is easily circumvented by using another person's document, so it is both unreliable and not very respectful of personal data. A system that compares the document photograph with a live capture is described as much more reliable, but as soon as it processes biometric data its use should in principle be provided for by a specific legal standard or be based on the freely given consent of the individuals.

For inferential systems the CNIL is blunt about importing browsing history, which it calls too intrusive for the simple purpose of age verification, and it advises avoiding a maturity questionnaire because of its high circumvention rate and the bias it can introduce.

The conclusion: no perfect method

The CNIL states that all the solutions then proposed can easily be circumvented, giving the example of a VPN. Its overall finding is that no solution then satisfied the three requirements it applied, namely sufficiently reliable verification, complete coverage of the population, and respect for privacy and security. That finding explains why the later European texts emphasise tokens, wallets and independent scrutiny.

What the authorities have in common

Read side by side, the sources converge on a small number of themes.

  • Risk decides the technique: the Commission's guidelines separate verification from estimation by risk, the ICO asks for certainty appropriate to the risks of processing, and the EDPB asks for a risk-based and proportionate approach.
  • The duty is stated as an outcome: highly effective in the UK statute, reasonable steps in Australia, appropriate and proportionate in the Digital Services Act.
  • Self-declaration alone is not enough where risk is real: it is outside the statutory definitions in the UK Act and described as insufficient for high-risk and medium-risk cases in the guidelines.
  • The result should carry as little as possible: a threshold answer or an age token instead of an identity, with the EDPB asking that the age process not become a means to identify, locate, profile or track people.
  • No one should be locked out by the method: the EDPB asks for alternatives for people without suitable documents or phones, and the ICO warns against making hard identifiers the only path.
  • Wrong decisions need a way back: the EDPB asks for redress mechanisms, and the CNIL asks for an alternative for those who dispute an estimate.

A checklist for a product team

These questions restate the sources as design prompts.

  • Which parts of the service carry the risk, and can age checks be limited to those parts instead of the whole site?
  • Does the law or the terms of the service set a minimum age, and which technique does the relevant authority associate with that case?
  • Does the check need an exact age, an age range or only a threshold result, and can the service receive only that result?
  • What alternative does a person have if they have no suitable document, no phone, or a disability, or if an estimate is wrong?
  • How are accuracy, reliability, robustness, non-intrusiveness and non-discrimination measured for the method you chose, and by whom?
  • What do users read before the check about data, third parties, retention and their rights?
  • How long is any evidence kept, and can the service work with a no-log approach after the result is known?
  • Who is accountable for the age assurance process, and can authorities audit it?

Where this sits in a verification flow

Some services meet an age requirement through identity verification, where a document and a selfie are already part of the flow. A flow built on NeuroVision KYC places these steps in one session: document, selfie, liveness and face match, with the scenario assembled in an editor. The face match step compares the selfie with the portrait on the document in a one-to-one comparison, and includes foreign-face detection and an age check against the date of birth. The liveness step is active: the person moves the face closer through two ovals. Erasure endpoints, a callback option that omits names, document data and images from the session event while keeping the session identifier, which links to the session, and encryption of the callback body give the integrating team controls for deletion and data minimisation, and retention in days is a setting of each scenario. The check results of database checks stay in the callback whatever that option says.

To see how these steps look in your own scenario, contact the team.

Sources

All sources were fetched on 27 October 2026.

Ready to talk?

Tell us what you are building and we will help you plan the integration.

Talk to us