Identity verification for age assurance on platforms accessible to minors

What platforms accessible to minors ask of age checks

For a social service, a game with chat or a community for hobbyists, the difficult question is not whether children use it. They do. The question is which parts of it should be closed to them, and how the service tells the two groups apart without turning every sign-up into a passport inspection. The answers on offer sit on a ladder. At the bottom a user says how old they are. In the middle a tool guesses a range from a face or a pattern of behaviour. At the top a document or a trusted source gives the age. Each rung costs the user more and tells the service more.

The platform described here sits on the top rung, and it only answers one question, whether the user falls within the age window that the service has set. The rest of the service is the service's own affair: which rooms need it, what happens at the edge, how a refused user is told. A good flow keeps the check short, keeps the data the service receives narrow and makes it hard to borrow someone else's papers.

• Read the date of birth from an identity document, not from a typed field.
• Make the document alone insufficient by matching a live face to its portrait.
• Spot generated and swapped faces in the verification selfie.
• Pass the outcome to the service without personal data.
• Choose how long the personal data is kept.

The flow

1. Access rule. The service decides which sections, features or content need an age check, and where in the journey the user meets it. This rule is yours.
2. Start. Your backend creates a session when the user reaches the restricted part, and opens the web widget. A user who starts on a desktop can finish on a phone with a QR code.
3. Document and age. The user photographs an identity document. The date of birth is read from it and compared with the age window of the scenario, which is configurable from 16 to 100. A service whose minimum age is below 16 sets its restriction by other means, because the window starts at 16.
4. Same person. The selfie is matched to the document portrait and active liveness confirms a live person. Deepfake and face-swap detection runs inside the selfie and liveness steps.
5. Outcome. The webhook tells your system the session is complete, and it has an option that does not send personal data. Your system keeps what it needs, and it can keep only the outcome. A separate session and a callback without personal data do not make the method an anonymised age token issued by an independent third party, which is what paragraph 41 of the guidelines describes; the document and the selfie are processed in the session.
6. Data. Retention is a setting you choose per scenario, and erasure on request is available through the API.
7. Explanation. The service tells users, in plain words, that a third-party tool carries out the check and why it is used. The platform does not write this text.

Where this differs from the dating and social page

The dating and social page covers age and identity at a service where adults meet, and it quotes the Digital Services Act and the UK Online Safety Act on children. This page is about the platform itself and the method it uses. Where the other pages ask what the law requires, this one asks what a regulator expects of the age-assurance method: how to compare self-declaration, estimation and verification, and what a verification flow may keep. The text below is a Commission communication that sets out those expectations.

Modules used

• Age check and the age verification use case.
• Document verification, face verification and liveness, including deepfake and face-swap detection.
• Web SDK and widget with QR hand-off.
• Webhooks, including the option that does not send personal data.
• Data controls for retention and erasure.

Regulatory frame

One European Union text: the Commission's guidelines on measures to ensure a high level of privacy, safety and security for minors online, pursuant to Article 28(4) of Regulation (EU) 2022/2065, published in the Official Journal on 10 October 2025 as C/2025/5519. They are a communication from the Commission and state what the Commission considers, not a regulation.

• Paragraph 29 says that the most common age assurance measures fall into three broad categories: self-declaration, age estimation and age verification.
• Paragraph 30 says that the main difference between age estimation and age verification is the level of accuracy, in that age verification provides certainty about the age of the user, while age estimation provides an approximation of the user's age.
• Paragraph 39 says that age verification should be treated as a separate, distinct process that is not connected with other data collection activities exercised by online platforms, and that it should not entitle providers to store personal data beyond information about the user's age group.
• Paragraph 41 says that methods which rely on verified and trusted government-issued IDs, without providing the platform with additional personal data, may constitute an effective age verification method, in so far as they are based on anonymised age tokens.
• Paragraph 51 says that age assurance solutions which can be easily circumvented should not be considered as ensuring a high level of privacy, safety and security for minors.
• Paragraph 52 says that the Commission does not consider self-declaration to be an appropriate age assurance method to ensure a high level of privacy, safety and security of minors in accordance with Article 28(1) of Regulation (EU) 2022/2065.

This block describes the text, not our service. For information; not legal advice.

Sources

• Communication from the Commission, Guidelines on measures to ensure a high level of privacy, safety and security for minors online, pursuant to Article 28(4) of Regulation (EU) 2022/2065, C/2025/5519, Official Journal text, fetched 27 October 2026.

Next

Try the interactive tour, read the age verification use case or compare with the dating and social flow.