When the mandate lands, it lands as three words: implement age verification. Your first move is to shortlist methods and vendors and pick the strongest. That is a reasonable first move, but where the data lands afterwards is where the liability lives for your business.
Mandates have landed across the UK, EU, US and Australia, with more than forty US state bills in the pipeline. Age checks touch gaming, social media, marketplaces and fintech. The real liability is that many document-centric vendors answer a yes-or-no question by storing a full government ID, which builds a breach honeypot. In October 2025 a Discord support vendor leaked roughly 70,000 ID images from an age check.
By the end you can place any method on the assurance continuum, test any vendor against data minimisation, and know which exposures you accept versus transfer. That is the work of the identity-verification crisis, and it starts with the method itself.
How should I assess whether a verification method fits my platform’s threat model before I commit to it?
Start by naming what you are defending against: a curious minor, a determined evader, a regulator, or a breach actor. Each makes a different method risky. Then run four checks: does the method create a breach honeypot, how much data does it return, does it clear the regulator’s bar, and does it survive a friction-versus-abandonment test?
Because a method is only ever good relative to what you are defending against, judge it against the adversary you actually face. A curious minor lies, a determined evader borrows a credential, a regulator asks for evidence, and a breach actor wants whatever you store. The honeypot test asks whether the method leaves you holding stored government IDs. The data-minimisation test asks you to keep the least personal data the obligation requires: one verified attribute, with a whole identity being more than you need. The more a method returns, the worse its posture.
Separate a method that clears the regulator’s bar from one that just sounds plausible. Alignment means clearing Ofcom’s four criteria of accuracy, robustness, reliability and fairness. Ofcom’s “highly effective” methods include photo-ID matching, facial age estimation, Open Banking and mobile-network-operator checks; self-declaration and a plain date-of-birth field sit outside. The method comparison behind the assessment maps that spectrum, from the weakest self-declaration up to liveness detection and document verification. Accuracy is not a given: facial age estimation carries error rates as high as 73% among teens.
Weigh friction against abandonment. Every extra step applies to adults too: proving someone is over 16 means every adult must prove they are not a child. Nearly seven in ten users have abandoned onboarding because the check was too slow, intrusive or demanded documents. A gate that piles on steps, in the style of the Steam age check, is the cautionary example: a secure method that drives adults away is a revenue and trust failure.
Layering reconciles the two. A multi-method workflow lets clear adults pass at low friction while borderline cases escalate, with facial estimation first and uncertain results falling through to document verification. Passive signals such as account-age analysis, behavioural monitoring and cross-transaction risk analysis belong in the threat model too, but each imports its own privacy liability, so weigh them as signals.
Whatever a method returns still has to land somewhere, and that is where the vendor enters the picture.
What questions reveal whether a vendor actually stores a government ID versus returning only an attestation?
Interrogate the vendor on five points: does it retain the document image or template, does it return a raw date-of-birth or identity payload or a signed attestation, how long is anything held, where does it reside, and what happens on breach. The answers split the marketplace into those that keep no copy and those that build a honeypot.
A method that clears the regulator bar can still become a honeypot if the vendor stores the ID, and that gap never shows on the marketing page. A signed attestation is minimisation-consistent: you receive only a low-entropy age bracket, with no birthdate or government ID changing hands. The EU’s double-blind attestation carries only the age statement. A raw identity payload is the opposite, and the difference is explained in why storing an ID creates a honeypot. Zero-knowledge proofs sit at the far end, where the verifier learns only that a claim is true.
Next, assess breach posture and data residency. These are liability questions before they are logistics. Ask for audit rights, a current subprocessor list, the hosting location of retained artefacts, and SOC 2 or a completed security questionnaire. Ask for breach notification terms, because where retained artefacts live is a breach criterion as much as a logistics detail.
The age assurance marketplace splits down the middle: document-centric incumbents centralise the PII and accept the honeypot, while verify-without-storing providers return an attestation and keep no copy. Underneath sits the truth that a vendor which stores IDs has relocated the honeypot. The risk follows the data to whoever ends up holding it.
How do I decide whether to build age assurance in-house or buy it, given engineering cost and liability?
Compare three-to-five-year total cost of ownership: build cost plus maintenance, security patching, compliance audit prep, incident response and risk, against licence plus integration, then weigh liability transfer. Buying does not outsource the threat model; the honeypot question stays yours either way.
Model the full cost over three to five years, in cost-per-approved-customer rather than cost-per-transaction. The initial build is the cheap part: three to six developer-months, or roughly $150,000 to $400,000. Then come maintenance of half to one engineer a year, security patching, roughly $50,000 to $200,000 in annual compliance audit prep, incident response and unplanned features. That same three-year comparison puts DIY at roughly $1.1 million against about $210,000 for a maintained framework.
Buying can look cheaper and can transfer some liability through contract and indemnity, but the threat model remains yours, which is why this is an ownership decision more than a procurement formality.
Compliance threshold mapping pins what counts as good enough to the two bars you face: “highly effective” age assurance in the UK versus commercially reasonable verification in the US. Mapping the thresholds you must hit decides whether you are over- or under-engineering.
None of this is binary. The strongest option for many teams is a middle path: buy the foundation, run it in your environment, and extend it where you need something specific. The question to weigh is what else your team could be shipping in the hours that maintenance consumes.
Where does the identity data land?
This assessment collapses into one question: where does the identity data land, and who is left holding it after the check is over? Whichever branch you take, the threat model stays your own. Procurement is where engineering cost meets liability, which is the front of the verification crisis. Prove the claim, keep the audit trail, store no document, and you meet the obligation without the liability.
Frequently Asked Questions
Is age verification the same thing as age estimation?
No, and conflating them distorts the assessment. Age verification confirms an age against a trusted document or credential, while age estimation infers an age from signals such as facial features without establishing identity. The assurance continuum runs from self-declaration through estimation to full verification, and each rung returns different data and carries different liability.
What is a breach honeypot in age verification, and why does it matter?
A breach honeypot is any store of identity data so concentrated that breaching it hands an attacker a trove of government IDs. It matters because the platform holding it inherits the liability. The Discord/5CA leak of roughly 70,000 ID images is the worked proof point. A method is only as safe as what it leaves behind.
If I buy age assurance from a vendor, do I still own the breach risk?
Yes. Buying transfers some liability through contract and indemnity, but it does not outsource your threat model. A vendor that stores government IDs relocates the honeypot, it does not remove it, so the exposure follows the data to whoever keeps it. Ask where the ID lands and who is left holding it after the check.
What should I look for in a vendor’s breach posture and data-residency model?
Look for evidence on retention, residency, and incident history, not reassurance. Ask for audit rights, a current subprocessor list, the hosting location of any retained artefacts, and SOC 2 or a completed security questionnaire. Request their breach notification terms and a record of past incidents. Where retained artefacts live is a breach criterion, not a logistics detail.
What separates a regulator-aligned method from one that just sounds plausible?
A regulator-aligned method clears a published accuracy, robustness, reliability and fairness bar, such as Ofcom’s “highly effective” age assurance standard. A method that merely sounds plausible has none of that evidence behind it. Test the claim against the threshold you must actually hit, not against how secure the marketing copy feels.
How do I reason about friction versus abandonment for a genuine adult?
Model the abandonment cost, not just the assurance gain. Every extra step loses some legitimate adults, and the Steam-style gate is the worked example of what over-friction does to a real adult population. A secure method that drives abandonment is a revenue and trust failure. Layered flows reconcile the two: clear adults pass fast while borderline cases escalate.
Can zero-knowledge proofs remove the honeypot risk entirely?
Zero-knowledge proofs go furthest toward removing it, because the verifier learns only that a claim is true and never sees the underlying ID. That is the double-blind extreme of the marketplace. The caveat is that the proof still depends on something issuing the credential and on honest implementation, so it shrinks the honeypot rather than abolishing all trust.
What happens if a regulated platform relies on self-declaration?
It fails the standard. Self-declaration sits at the low end of the assurance continuum and is widely discredited, because a curious minor can simply lie. Regulators such as Ofcom expect methods that are highly effective, not tick boxes. If someone is determining compliance, self-declaration is unlikely to clear the bar on its own.
How much does building age assurance in-house actually cost?
Assess it as three-to-five-year total cost of ownership, measured per approved customer rather than per transaction. Build cost alone understates it; add maintenance, security patching, compliance audit prep, incident response, feature additions, and breach probability times cost. Compare that whole figure against licence plus integration before deciding the build is cheaper.
What are passive age signals, and can they replace verification?
Passive signals such as risk signals, account-age analysis, ongoing behavioural monitoring and cross-transaction risk analysis infer age from behaviour rather than checking a document. They complement verification but rarely replace it, because none produces the evidence a regulator wants. Each also imports its own privacy liability, so weigh them in the threat model rather than treating them as free.
Does one verification method work across the UK, EU, US and Australia?
No, because the thresholds differ by jurisdiction. The UK and Ofcom expect “highly effective” age assurance, while much US regulation asks for commercially reasonable verification, and Australia is phasing in its own regime. A method that clears one bar may fall short of another. Map each target market’s threshold before you commit to a single configuration.
How long should a vendor be allowed to retain identity data?
Ideally not at all, and that is the test worth applying. A verify-without-storing provider retains nothing and returns only a signed attestation, while a document-centric vendor holds the image or a template for as long as its policy allows. Ask for the retention window in writing and treat anything beyond the check itself as an accumulating liability.
