There is a contradiction sitting at the center of every age assurance project in 2026, and most teams don’t notice it until a regulator — or a breach disclosure — forces them to.
On one side, you are legally required to check age. The UK’s Online Safety Act, the EU’s Digital Services Act, half of US states, and Australia’s eSafety framework all demand that platforms keep minors away from content and features that aren’t for them, using methods regulators call “highly effective.” Do nothing, and you face fines, investigations, and in some jurisdictions personal liability for executives.
On the other side, you are legally required to not collect more personal data than you need. GDPR’s data minimisation principle, the UK GDPR, CCPA’s purpose limitation, and the children’s design codes all push in the opposite direction: gather the least data possible, keep it the shortest time possible, and never repurpose it.
For years, teams treated these as separate compliance workstreams owned by separate people. That era is over. On 25 March 2026, the UK’s Information Commissioner’s Office (ICO) and Ofcom published a joint statement on age assurance that does something the two regimes had never formally done together: it tells you that satisfying one obligation does not excuse you from the other. You have to do both, at the same time, in the same flow.
This post breaks down what the dual obligation actually requires, why the obvious implementation (upload an ID, store it, move on) is now the riskiest possible choice, and how to architect an age check that makes both regulators happy by design.
The Joint Statement, in Plain Terms
The ICO and Ofcom rarely speak with one voice. Ofcom owns online safety; the ICO owns data protection. The fact that they coordinated a single statement is itself the signal — they were seeing organisations use “Ofcom made me do it” as a justification for collecting and retaining far more personal data than age assurance actually needs.
The statement’s core expectations are worth reading literally, because they map directly onto engineering decisions:
Collect only what’s needed to establish age or age range. Not identity. Not a full document. The regulators are explicit that age assurance should confirm age, not identity, unless there is a clear and proportionate justification for something more intrusive. A platform that needs to know “is this user 18 or over?” has no lawful basis to walk away with a name, a home address, and a document number.
Don’t repurpose age assurance data. If you collected a face scan or an ID to check age, you cannot quietly feed it into fraud models, marketing segmentation, or an identity graph. Purpose limitation applies the moment the age check is done.
Be necessary and proportionate to the risk. The method has to fit the harm. A general-interest forum does not get to demand passport uploads from every visitor “to be safe.” The intrusiveness of the check must scale with the actual risk of the content or feature behind the gate.
Apply storage limitation. Keep age data only as long as you genuinely need it, then delete it. Indefinite retention “in case of an audit” is not a lawful default.
Run a DPIA where processing is high-risk to children. A Data Protection Impact Assessment is no longer a nice-to-have for these flows — it’s the expected baseline, and it should be done before you ship, not reconstructed after an incident.
Give users a way to challenge wrong decisions. Age estimation gets people wrong. An 18-year-old who looks younger needs a route to appeal, and that route can’t itself become a data-harvesting funnel.
None of this is new law. What’s new is the explicit, coordinated message that the Online Safety Act is not a shield against data protection liability — and vice versa. You can be fully age-assurance-compliant and still be fined for how you did it.
Why the Obvious Implementation Is Now the Dangerous One
When a deadline lands, the fastest path to “we check age” is to bolt on a document-upload step: ask every user to photograph their ID and a selfie, run a match, and store the result. It demonstrably works, it satisfies an auditor’s checklist, and it ships in a sprint.
It is also, in 2026, the implementation most likely to end with your company in a headline.
The reason is structural. Every ID document and biometric template you collect is a liability that sits on your books indefinitely. You cannot reduce the blast radius of data you’ve already gathered — you can only avoid gathering it. And the breach history of the last twelve months reads like a warning label:
A cybersecurity researcher found that age verification vendor Persona had left frontend infrastructure exposed in February 2026 — and, more tellingly, that the verification process ran far more checks and collected far more data than the stated purpose of confirming age required. Discord disclosed a breach that exposed government ID images belonging to roughly 70,000 users through a compromised third-party provider. In both cases the damage wasn’t a clever attack on a hardened system; it was the simple fact that the personal data existed, in one place, in a form that maps back to a real human.
This is the asymmetry that the joint statement is reacting to. When your password leaks, you reset it. When the cryptographic representation of your face or the scan of your passport leaks, you cannot issue yourself a new face or a new passport. Over-collection isn’t just a compliance technicality — it’s an irreversible harm transferred onto your users, and increasingly onto your balance sheet.
There’s a quieter cost too. A coalition of hundreds of security researchers has publicly warned that the dominant “upload your ID” model creates systemic privacy and security risk at internet scale. Regulators read those letters. The direction of travel is unambiguous: the document-vault approach is being treated less as a solution and more as the next category of incident.
The Resolution: Verify the Attribute, Not the Person
The contradiction between “check age” and “don’t collect data” dissolves once you stop conflating age assurance with identity verification. They are different problems, and most platforms only have the first one.
Identity verification answers “who is this exact person?” Age assurance answers a much narrower question: “does this person meet an age threshold?” The second answer is a single boolean — age_over_18: true — and a well-designed system can produce it without the platform ever touching the underlying identity data.
Three architectural patterns make this real, and they map cleanly onto the joint statement’s expectations.
Data minimisation by threshold disclosure. Instead of receiving a date of birth (from which age, birthday, and a unique identifier can all be derived), your platform receives only the answer to the specific threshold it asked about. A liquor retailer asks “21 or over?” and gets a yes or no — never the customer’s actual age, never their name. This is data minimisation enforced by the protocol, not by a retention policy you have to remember to honour.
Storage limitation by not storing. The strongest storage-limitation posture is having nothing to limit. When the verification produces a signed attestation rather than a stored document, there is no ID vault to breach, no retention schedule to defend, and no deletion request to fulfil because no personal document was ever persisted. You keep the decision and the audit trail; you discard the evidence.
Purpose limitation by design. If the only artefact that crosses into your systems is a scoped age result tied to a specific purpose, there is structurally nothing to repurpose. You cannot accidentally feed an ID into a marketing model that you never received in the first place.
The technologies that deliver this are no longer theoretical. Zero-knowledge proofs let a user prove “I am over 18” without revealing any underlying value. Mobile driver’s licenses and EU Digital Identity Wallets support selective disclosure, transmitting a cryptographically signed age attestation and nothing else. On-device facial age estimation can return an age band from the user’s own hardware without an image ever leaving the device. Each of these turns “minimise data” from a discipline you enforce into a property the system has.
A DPIA That Actually Reflects Your Architecture
The joint statement expects a DPIA for high-risk children’s processing, and most DPIAs for age assurance are weak because they assess a document-upload flow as if its risks were manageable. They aren’t — they’re just being documented.
A stronger DPIA starts from the architecture and asks, at each step, what is the least intrusive method that still meets the required assurance level for this specific risk? The answer is rarely “collect a full ID from everyone.” More often it’s a tiered approach: estimate first, escalate only when necessary.
Concretely, a proportionate stack looks like this:
- On-device or zero-knowledge age estimation for the lowest-risk thresholds, where being over the line by a comfortable margin can be confirmed without any document.
- Wallet-based selective disclosure (mDL, EU wallet) for users who have a provisioned credential — highest assurance, minimum data, fastest experience.
- Document plus liveness only as a fallback, only for users who can’t satisfy the higher tiers, and only with immediate deletion of the document once the result is produced.
Each tier is more intrusive than the last, and your DPIA can justify each escalation as necessary and proportionate — which is exactly the language the regulators used. Critically, this also gives you the challenge mechanism the statement requires: a user wrongly flagged by estimation can escalate to a stronger method rather than being locked out.
What This Means Across Borders
The ICO and Ofcom statement is a UK instrument, but the principle it crystallises is global. The EU’s GDPR has always required data minimisation, and the European Data Protection Board has repeatedly stressed that age assurance must not become a vector for mass identity collection. The EU’s own age verification approach is being built around a privacy-preserving wallet model precisely to avoid the over-collection trap. In the US, state laws increasingly pair an age-check mandate with explicit data-handling and deletion requirements — Louisiana’s law taking effect 1 July 2026 is one of several that bundle the two.
The pattern repeats everywhere: the mandate to verify arrives first, and the data-protection guardrails follow close behind. Platforms that built document vaults to satisfy the first wave are now discovering they’re non-compliant with the second. Platforms that built attribute-based verification satisfy both waves with one architecture — which is the entire point. Designing for the strictest interpretation isn’t gold-plating; it’s the only design that survives contact with two regulators who now talk to each other.
How Xident Implements the Dual Obligation
Xident was built around the assumption that age assurance and data protection are the same project, not competing ones. The default flow returns a verified age result and an audit trail — not a stored identity document.
The API exposes the tiered, proportionate model directly, so the least intrusive method that meets your required assurance level runs first:
import { Xident } from '@xident/sdk';
const result = await Xident.verify({
method: 'minimal-first', // estimation → wallet → document fallback
ageThreshold: 18,
purpose: 'social-account-creation',
retainDocuments: false, // nothing to breach, nothing to delete
});
if (result.verified) {
// You receive: { verified: true, threshold: 18, method: 'zkp', auditId }
// You do NOT receive: name, date of birth, document image, or biometric template
}What you keep is the decision and a tamper-evident audit record that demonstrates a compliant check happened — the evidence a regulator wants to see. What you never keep is the personal document that turns an audit into a breach. Data minimisation, storage limitation, and purpose limitation are enforced by the integration rather than by a policy someone has to remember.
That posture is what lets a single integration answer to Ofcom and the ICO — and to their counterparts in Brussels, Canberra, and a growing list of US state attorneys general — without choosing which regulator to disappoint.
If you’re scoping an age assurance project and want it to pass a DPIA the first time, read our documentation or get in touch. The cheapest data to protect is the data you decided not to collect.
This article is for general information and does not constitute legal advice. Consult qualified counsel about your specific obligations under the Online Safety Act, UK and EU data protection law, and applicable US state requirements.
