An age check needs one bit: is this person an adult? Yes or no. Yet the standard flow asks for a government ID, processes it, then keeps it somewhere. That gap, between the single bit the question needs and the full identity that gets retained, is what this article is about, and part of the wider identity-verification crisis. Zero-knowledge proofs promise to close it by letting someone prove they’re over 18 without handing over a document. But ask where the trust they claim to remove lands. Answer it as a question of breach economics.
What is a breach honeypot, and why does storing an ID to answer one yes/no question create one?
A breach honeypot is a store of high-value identity data that becomes the payoff if someone breaks in. That’s a different meaning from the decoy honeypot security teams run to lure attackers and record what they do. The data-store version is the prize.
A platform needs one thing: is this person over 18? A government ID carries name, date of birth, document number, address and a photo. Store the ID and one breach leaks all of it, far more than the yes/no ever asked for. Every identity vendor that keeps verified data in a central database is building one of these, and when it’s breached it exposes everyone at once.
Does verifying once still create a honeypot? Yes, if the record is held onto afterwards. Throw the document away once processing is done and the honeypot never forms; keep it “just in case” and a one-time question becomes a permanent database of licences. This is why verification architecture is a systemic problem, and why mandates outpace implementations.
In October 2025 attackers compromised Discord’s support vendor 5CA through a Zendesk portal, taking roughly 70,000 ID images users had uploaded for an age check. Persona, AU10TIX, Meta’s platforms and Pornhub’s parent Aylo all process ID at similar scale.
What happened in the IDScan.net breach, and why does a 153M driver’s-licence trove matter?
In late 2026 IDScan.net, a New Orleans identity-verification company, became the apparent source of Nexus, a dark-web service selling scans of more than 153 million US and Canadian driver’s licences plus millions of ID cards and travel documents. The company runs more than 21 million verifications a month across 20,000-plus locations, for clients including Hertz, Target and FedEx.
The records, advertised on the Russian forum Exploit, surfaced with front-and-back scans under ordinary, infrared and ultraviolet light. Named victims included security journalist Brian Krebs and US Defence Secretary Pete Hegseth. The FBI opened an investigation and confirmed to TIME it was looking into it, while the RCMP monitored as Canada’s privacy commissioner opened an inquiry.
What makes this one different is scale and sensitivity together. A password can be reset; a licence photo is biometric, and you can’t reissue a face. Leaked ID images feed synthetic identity fraud and deepfake IDs, and researchers expect the trove to hold value for years. That’s why a driver’s-licence database is worth stealing.
How do zero-knowledge proofs work in an age-verification context?
The proposed answer is a proof that reveals nothing. A zero-knowledge proof lets someone prove a statement is true without revealing the data behind it. In age verification the statement is “I am over 18”. The holder’s wallet takes a signed credential from an issuer (the body that verifies the age and signs the credential), turns it into a proof, and the verifier checks it in milliseconds, learning only yes or no. The raw document never reaches the service.
That’s the difference from hashing. A hash-and-store approach still holds the raw document server-side, so it’s still a honeypot. A ZKP lets the holder practise selective disclosure and data minimisation: reveal “over 18” and nothing else.
Microsoft Research’s Vega prototype generates a proof in about 92 milliseconds, producing 108 KB of proof data that verifies in 23 ms, with no trusted setup. Device binding ties each proof to the holder’s phone via a fresh nonce, so a leaked credential alone can’t be replayed. See which methods avoid storing a document.
Why do regulators say zero-knowledge proofs don’t remove trust, but only relocate it to a central issuer?
Because a ZKP still depends on an issuer: the body that defines what “adult” means, signs the credential, and sits behind every proof. In practice relying parties accept only a narrow set of “high assurance” issuers, giving one or two of them visibility into every presentation.
Revocation makes it worse. If checking a credential’s status phones home to the issuer each time, the issuer can track where and how often it is used, undercutting the unlinkability and unobservability a wallet is meant to provide. The W3C’s credential rules explicitly reject phoning home on every use.
So ZKPs move trust from the data-storing verifier to a central issuer and a trusted list (the short list of issuers a service is allowed to accept). An issuer-based scheme also gates access for the estimated 850 million people worldwide without formal ID, and the EU’s own threat model lists “issuer and verifier collude” and “trusted list compromise” among its risks.
Scytales, T-Systems and Zyphe run the issuer side, which shows how trust flows through a small set of operators. Whether a scheme is actually private or just relocating trust is a question you can now ask.
How does the EU’s age-verification “mini-wallet” actually work inside the EUDI Wallet, and why are its ZKP proofs disabled in the shipped build?
Inside the EUDI Wallet, a service requests an age threshold, the wallet notifies the user, generates a proof from a trusted-issuer credential, and shares only the yes or no. The data model builds on ISO mDoc/mDL, with issuance over OpenID4VCI and presentation over OpenID4VP, per the EU’s Age Verification Manual.
But in the shipped build the ZKP features aren’t turned on outside a closed demo. The app is designed to work without ZKP, and even when developed it stays an optional extra countries can disable. The same report describes a Chrome extension that tricked the app into repeatedly accepting the same over-18 token: a token not bound to a device or session lets one proof be linked across services, defeating the unlinkability the design promises. Google ties its own approach to Google Play Integrity and Android platform integration.
Is it actually private? Better than re-uploading an ID to every service, yes: a reusable credential means dozens of sites never hold a user’s document. But it’s not fully unlinkable in the current build; the EU’s Age Verification Manual and EUDI Wallet specifications are where you check the promise against the shipped artefact.
Where trust actually lands
Stop grading verification on whether the vendor “stores” anything. A vendor who says it doesn’t store anything can still be routing a user’s identity to a central issuer that watches every presentation. Ask where trust lands and what a breach there would cost your business. That is the storage-and-trust layer of the crisis, and the measure to use when you assess a vendor’s storage claims.
Frequently Asked Questions
Does age estimation avoid the breach honeypot problem?
Not entirely, but it shrinks it. Age estimation infers a likely age from a face or a selfie rather than reading a document, so there is no licence number or address to leak. The trade-off is that it handles your biometric, which cannot be reissued if it is compromised, and accuracy is weaker near the threshold.
How fast are zero-knowledge age proofs, and will they slow down sign-up?
They are fast enough to be invisible. Microsoft Research’s Vega prototype generates a proof in roughly 92 milliseconds, produces about 108 KB of proof data, and verifies it in about 23 milliseconds, with no trusted setup. That sits well inside the latency of an ordinary login, so in practice the check adds no perceptible delay.
What happens if the issuer of my digital credential is breached or shuts down?
Either event exposes the weak point of trust relocation. Because proofs depend on a signed credential from an issuer, a breach there or a shutdown can strand holders or expose the record of what was issued. That is why the issuer, not the verifier, becomes the single point of failure in a wallet-based scheme.
Is a reusable digital credential really more private than re-uploading my ID?
Yes, on the whole. A reusable credential lets you prove “over 18” from a wallet without handing the document to each service, so dozens of businesses never hold your ID. The caveat is that the credential still comes from a central issuer that may observe each presentation, so you avoid many honeypots but not the trust concentration.
What is synthetic identity fraud, and how does a leaked ID image enable it?
Synthetic identity fraud builds a fake person from a mix of real and invented details. A leaked ID image is prime material because it carries a genuine document number, date of birth and photo, letting a fraudster assemble or deepfake an identity that passes checks. That resale value is exactly why a driver’s-licence trove attracts attackers.
What can I do if my driver’s licence image is already part of a leaked trove?
Start by treating it as an identity problem, not a password problem. Because a licence image exposes biometrics that cannot be reissued, request a replacement document, place a fraud alert or credit freeze, and watch for synthetic identities opened in your name. You can change a password; you cannot change your face.
Do regulators legally accept zero-knowledge proofs for age checks?
Increasingly, yes, though usually as one accepted method among several. Frameworks such as the EU Age Verification Blueprint and the EUDI Wallet are designed around privacy-preserving proofs, yet many markets still accept conventional ID upload. Legal acceptance is therefore less settled than the privacy argument, and it varies by jurisdiction.
Does Australia’s age-verification push carry the same honeypot risk?
Yes, whenever it is built on storing documents. Any Australian regime that asks a platform or processor to hold ID images inherits the same breach economics as IDScan.net. The risk falls with retention and concentration, not with the nationality of the law, so the architecture matters more than the mandate.
Where can I read the EU Age Verification Blueprint and EUDI Wallet specifications?
Both are published as primary technical documents. The EU Age Verification Blueprint sets out the architecture, and the EUDI Wallet specifications detail the credential formats and protocols such as ISO mDoc/mDL and OpenID4VCI/OpenID4VP. Reading them alongside a shipped app is the quickest way to spot a promise the build does not yet keep.
When is storing an ID actually justified?
Rarely, and only when the storage itself is the required service. Regulated cases such as law enforcement or a bank’s legal record-keeping can justify retention. For a simple “is this person an adult?” question, storage is never necessary, so the honest answer is that the store exists for the platform’s convenience, not the user’s.
What should I ask a vendor before signing an age-verification contract?
Ask where trust lands and what a breach there would cost. Concretely, request the retention period, whether any raw document is stored, who the issuer is, and whether status checks phone home on every presentation. If a vendor says only “we do not store anything,” you still need to know where your identity is being routed.
