Age checks used to be a checkbox and a date picker. In 2026 that is no longer enough for a growing number of platforms. Regulators, rating bodies and app stores are all asking for age assurance that actually works, and product teams are being asked to deliver it without wrecking conversion.
The common response is to collect more: a date of birth, a photo of an ID document, a selfie. That solves the assurance problem and creates a data problem. There is a narrower way to meet the requirement.
What changed: age assurance moved from policy to duty
In the UK, the Online Safety Act 2023 places duties on in-scope online services to protect children, and Ofcom's codes and guidance expect highly effective age assurance where services allow certain categories of harmful content. Self-declaration does not meet that bar. Which services are in scope, and which content triggers which duty, depends on the service and is set out in Ofcom's guidance.
Games face a related shift. PEGI, the European age rating system, has updated its criteria so that games offering paid random items, such as loot boxes, receive a higher minimum age rating. A rating is not itself a verification law, but it changes who a game is rated for, and platforms that sell or distribute those games increasingly want a reliable way to respect it.
Other jurisdictions are moving in the same direction with their own rules. The specifics vary widely by country, sector and content type. Treat this as general context, not legal advice, and consult counsel on what applies to your service.
The hidden cost of collecting a date of birth
A date of birth looks harmless. It is a single field, users are used to giving it, and it answers every age question at once. That is exactly the problem: it answers far more than you asked.
- It is a stable identifier. Combined with a name or postcode, a date of birth narrows a person down quickly, and it is a common input to account recovery and identity fraud.
- It never expires. Once stored, it stays accurate for life, so a leaked date of birth stays useful to attackers indefinitely.
- It invites reuse. Data collected for an age gate tends to drift into marketing, analytics and personalisation, which creates new obligations and new risk.
- It is unverified on its own. A typed date proves nothing. To make it trustworthy, teams add an ID image, and now they hold a document scan as well.
ID images make the problem sharper. A document photo carries a name, a number, a face, a date of birth and often an address. Stored after an age check, it turns a simple compliance step into a store of identity documents, which is precisely the kind of data that fuels identity fraud.
Data minimisation points the same way
Privacy law tends to reward the narrow answer. Under the GDPR, Article 5 sets out data minimisation: personal data should be adequate, relevant and limited to what is necessary for the purpose. Many other privacy regimes contain similar principles. If the purpose is to confirm that a user is over 16 or over 18, a full date of birth and a document image are hard to justify as necessary.
That does not mean regulators accept weak checks. It means the strength of the check and the amount of data you keep are separate questions. You can have a strong check and keep very little.
The pattern: ask “is this person over N?” and get yes or no
The cleaner design reframes the question. Instead of asking the user for their birthday, the platform asks a verifier one thing: is this person over the threshold that matters here? The verifier checks the age against a trusted source and answers yes or no.
The platform stores the answer, not the evidence. It can still enforce the rule, show auditors how the rule is enforced, and apply different thresholds to different features. What it does not hold is the raw material that makes age data risky.
For the pattern to be worth anything, three things need to be true:
- The source is trustworthy. The age has to come from something stronger than self-declaration, such as a government-issued document whose authenticity can be checked.
- The person is the document holder. A valid document belonging to an older sibling or a parent should not pass, so the check needs to tie the document to the person in front of the camera.
- The answer is bound to the account. The yes or no has to attach to the user's account in a way that cannot be shared or replayed across accounts.
Questions to ask an age verification vendor
- What does my platform receive after a check: a full identity record, a date of birth, or only an over-threshold answer?
- Where does the age come from, and how is the document's authenticity verified?
- How is the document tied to the person completing the check?
- What happens to the document images and the selfie after the decision?
- Can I set different age thresholds for different features without re-collecting data?
- Can a returning user be recognised without repeating the full check?
The answers tell you whether a vendor is solving your age assurance problem or quietly moving it into a different database.
How JERIX approaches it
JERIX answers the age question as yes or no. The client sets the age threshold it needs, and receives whether the person is verified and whether they meet that threshold. It does not receive the date of birth, the name, the ID number or any image.
For passports, the age comes from the NFC chip, whose signature is verified to the issuing state's root certificate, offline. The face stored on the chip is matched against a live selfie, which ties the document to the person. After the check, no images or biometrics are retained. Each client receives its own one-way token for the person, so a returning user can be recognised without exposing them across platforms.
If an age-assurance deadline is on your roadmap, we would be glad to show you what a yes/no integration looks like in your flow.