The Hidden Data Trail Created by Online Age Checks

Quick Verdict

Online age checks have a legitimate purpose. They can prevent children from accessing pornography, gambling, alcohol sales and other age-restricted services. They can also help platforms separate child and adult experiences, apply stronger privacy settings to younger users and avoid processing data from children who are not permitted to use a service.

The concern is not simply that an age check exists. The concern is how much information is collected, which organisations receive it, whether the check can be linked to the site being visited, how long records are retained and whether the result is reused for advertising, profiling or unrelated identity checks.

Age Assurance, Estimation and Verification Are Not the Same

“Age assurance” is the broad term for methods used to determine whether someone belongs to an age or age-range category. It can include a simple declaration, an estimate based on a face or account history, or a formal verification using identity evidence.

Regulators do not treat every method as equally effective. For example, Ofcom lists open banking, photo-ID matching, facial age estimation, mobile-network checks, credit-card checks, digital identity services and certain email-based estimation systems as methods capable of being highly effective when implemented properly. Self-declaration alone is not considered highly effective.

The Data Trail Behind a Single Age Check

A well-designed website may receive only a yes-or-no result. That does not mean no data was processed elsewhere. The verification provider may still need enough information to make the decision, detect fraud and demonstrate that its system works.

This is why role separation matters. A verifier may need to know enough to confirm age, while the website may need to know only that the threshold was met. Neither side necessarily needs the full picture.

What Each Age-Check Method Can Reveal

The Benefits of Effective Age Checks

The case for age assurance is not limited to blocking access. It can be used to change what a child sees, how an account is configured and which forms of data processing are permitted.

• Reduced access to adult material: effective checks can make it harder for children to encounter pornography, gambling and age-restricted products.
• Age-appropriate design: services can apply safer defaults, limit contact features or restrict targeted advertising for younger users.
• Lower risk of unlawful child-data processing: a service that excludes underage users can avoid collecting information it may have no lawful basis to process.
• Clearer accountability: an auditable system gives regulators and users more evidence than a simple “I am over 18” tick box.
• Less disclosure can be possible: modern credentials can prove a threshold without giving the website a full date of birth or identity document.
• Reusable proof can reduce repeated uploads: a trusted wallet may allow one verification to support several services without sending a passport each time.

Privacy and Security Risks

Age checks create risk when the system collects more information than is needed, retains it for too long or allows several parties to combine their records.

Data minimisation reduces these risks but does not eliminate them. Even a yes-or-no result can become identifying when combined with an IP address, account login, timestamp or unique token.

Real-World Security Incidents Involving Verification Data

Public evidence shows that verification records are attractive targets, but the incidents are not all equivalent. Some involved confirmed access to identity images. Others involved exposed credentials or development files where the provider says no customer data was reached. Keeping those categories separate is essential.

What users can learn from these incidents

• Third parties expand the attack surface: a platform can secure its main service while support contractors, identity vendors and archived storage remain exposed.
• Support workflows can retain more than the main verification flow: an ID deleted by an automated verifier may still exist in an appeal ticket or manual-review system.
• Legacy data is still sensitive: records collected under an old process can remain vulnerable years after the process changes.
• Not every security report is a customer-data breach: exposed code, inactive credentials and test environments should be reported accurately rather than automatically described as stolen IDs.
• Numbers need attribution: use figures confirmed by the affected organisation or regulator and clearly label larger attacker claims as unverified.

Accuracy, Fairness and Exclusion

Stronger evidence can improve confidence, but it often increases friction and data collection. Less intrusive methods can be easier to use but may produce more errors.

• People close to the threshold: facial estimation is most likely to be disputed when a 17-year-old and a 19-year-old appear similar.
• Unequal model performance: systems must be tested across relevant ages, skin tones, disabilities, camera qualities and demographic groups.
• Document access: not every adult has a current passport, driving licence, credit card or conventional bank account.
• Shared accounts: phone plans, payment cards and household devices may belong to one person but be used by another.
• Digital exclusion: people with older devices, limited connectivity or low technical confidence may struggle with camera and wallet systems.
• Appeals: users need an accessible alternative when a system makes an incorrect decision.

What Privacy-Preserving Age Assurance Looks Like

European and UK regulators increasingly emphasise data minimisation, proportionality and separation between proof issuance and the website requesting the result. The European Commission is also developing anonymous proof-of-age systems that can confirm a threshold without disclosing a full identity.

1. Collect only the attribute needed: a site asking whether someone is over 18 should not automatically receive a name, address or exact birth date.
2. Separate the verifier from the website: the verifier can inspect evidence while the website receives only a signed outcome.
3. Prevent linkability: tokens should not allow the verifier or several websites to build a history of where the user presented proof.
4. Use short retention periods: raw IDs, selfies and videos should be deleted as soon as they are no longer necessary.
5. Process locally where practical: on-device estimation can reduce the transfer and central storage of face images.
6. Publish clear retention rules: users should know what is collected, why, who receives it and when it is deleted.
7. Provide alternative methods: no adult should be excluded solely because they lack one document, bank account or compatible device.
8. Support challenges: users need a straightforward way to correct an inaccurate decision.
9. Commission independent testing: security, privacy, fairness and accuracy claims should be evaluated by qualified third parties.
10. Prohibit secondary use: age-check data should not become an advertising identifier or general-purpose identity profile.

What Users Should Check Before Verifying Their Age

• Who is performing the check? Look for the verifier’s legal name rather than trusting only the website’s branding.
• What is being requested? A request for a full passport should have a stronger justification than a request for an anonymous age token.
• Will the website receive identity data? A good notice should explain whether it receives only a result or also receives the underlying evidence.
• How long is information retained? “We protect your privacy” is less useful than a specific deletion period.
• Is the face image stored? Check whether processing is local, temporary or retained for model training and fraud detection.
• Can the check be reused or linked? Reusable credentials should prevent unrelated services from correlating presentations.
• Is another method available? A legitimate process should offer an alternative when the first method fails or is inaccessible.
• Is the page genuine? Verify the domain before uploading an ID, opening a banking flow or activating a camera.

The legal position differs by country and by the type of service. Our earlier Utah VPN age-check guide explains one example of how location masking and age-verification duties can interact.