In June 2026 a group of researchers published the first exploratory security assessment of the age-verification systems that regulators across Europe have spent two years mandating. They mapped the ecosystem across four countries, built an adversary model, and tested what adult sites had actually deployed: document reads, biometric age estimation, indirect signals, and the workflow glue that stitches a third-party verifier to a website. The paper is titled “X-rated Compliance Theater”, and the title is the finding. The systems showed systemic weaknesses under realistic threat assumptions, including failures against low-cost, widely accessible attacks, and the authors pose the question every operator running one of these flows should be asking: do these mechanisms deliver protection commensurate with the privacy risk they introduce, or do they mostly perform compliance?
The uncomfortable part is that the regulations these systems answer to are not naive about privacy. The opposite. The standard they increasingly converge on is one of the more demanding privacy properties in production anywhere: double anonymity. France’s ARCOM referential requires it. The EU’s Age Verification Blueprint is architected around it. The problem the study documents is not that the rules ask for too little. It is that the deployed systems claim a property they do not have, and the claim is close enough to true that nobody checks the half that is false.
What double anonymity actually means
Double anonymity is two separations, and the word “double” is doing precise work. The first separation is the one everybody markets: the website must not learn who the user is. It learns one bit — over 18, or over 15, or over 13 — and nothing else. No name, no date of birth, no document image. This is the property most vendors mean when they say “privacy-preserving,” and most of them genuinely deliver it. A site that receives a signed age attestation and no identity has satisfied the first half.
The second separation is the one that gets lost: the verifier must not learn which site the user is on. The provider that reads the document and estimates the age knows exactly who the user is — that is its job — but it must not know that this person is, at 11pm on a Tuesday, proving their age to a specific pornography site. As France’s regulator frames it, the site knows the age without identifying the user, and the provider knows the identity without knowing the service being accessed (Biometric Update, April 2025). Both halves have to hold at once. A system that nails the first and drops the second is not “mostly private.” It has built a log that pairs a legal identity with sexual intent, which is close to the worst single record a data-protection regime recognises.
That is the reason double anonymity is not privacy garnish. The special category here is not “age.” It is the cross-link. Age alone is boring; identity alone is ordinary; the two joined to a category of content is the thing GDPR treats as sensitive and the thing a breach turns into extortion. We wrote about what happens when that record gets kept in the age-verification breach wave, and about the architectural version of the same mistake in the Persona–Discord incident. Double anonymity is the design that makes the dangerous record impossible to assemble in the first place, rather than promising to guard it well after it exists.
There is a third property sitting behind the two separations, and it is where the subtle failures hide: unlinkability across visits. Even if no single transaction reveals identity to the site or the site to the provider, a reused token or a predictable attestation lets colluding relying parties stitch one user’s visits together into a profile without ever knowing the name attached. Double anonymity that holds for one request and leaks across many is still a surveillance system, just a slower one.
The standard is now written down
This is not aspirational. Two of the most consequential frameworks in the space have already encoded double anonymity as a requirement, not a nice-to-have.
France moved first and most bluntly. ARCOM’s referential, published in October 2024 and fully in force since 11 April 2025, requires that a service host at least one age-check method meeting the double-anonymity standard, run the check through an independent third-party provider, verify before each session, and harden the flow against deepfake and injection attacks (Osborne Clarke). It goes further than most teams realise on one point: the double-anonymity method must combine at least two independent proofs of age — for example a document-based check and an age-estimation check — so that neither the identity leg nor the site leg is a single point that can quietly collapse the separation. We walked through the operational shape of that regime in how Xident meets the France ARCOM standard; the referential is the clearest legal statement anywhere that the second separation is mandatory rather than optional.
The EU’s Age Verification Blueprint takes the same property and turns it into an architecture. It is built on Proof of Age attestations, relying parties, attestation providers, age-verification apps, and trust lists, aligned with the European Digital Identity Wallet, and its explicit design goal is to prevent profiling and tracking by avoiding linkable transactions. The mechanics are worth reading closely, because they are what double anonymity looks like when someone actually engineers it rather than asserting it. Attestations are single-use. They are issued in batches — thirty at a time is the recommendation — so that a user does not present the same credential twice and hand colluding sites a join key. Validity timestamps are deliberately coarsened to strip linkability clues, following the ISO/IEC 18013-5 guidance to set the same time value across a batch. And critically, the website never contacts the issuer: it only checks that the attestation was signed by a trusted party and is still valid, which means the issuer never learns where, or whether, the attestation was used (EU Age Verification Blueprint, technical specification). Zero-knowledge proofs are on the roadmap to strengthen the same guarantee. We covered the operational lessons for platforms integrating against it in the EU blueprint security write-up and the rollout mechanics in the EU age-verification app relying-party integration piece.
Notice what both frameworks are really doing. They are removing the ability of any single party to hold the cross-linked record, by design, so that double anonymity is a structural fact rather than a matter of trusting a data-retention policy. That is the bar. The study is about how far production falls below it.
Where the deployed systems break
The failures the “Compliance Theater” study describes are not exotic. They are the predictable result of bolting a third-party verifier onto a website with the same casual integration patterns used for analytics and payments, and they cluster in a few places.
The most common is the referrer leak. A site redirects the user to a verifier, and the redirect carries the origin — in the URL, in the Referer header, in a return parameter — so the verifier now knows exactly which site sent this identified person. The first separation held; the second one never existed. This is the age-verification equivalent of embedding a third-party pixel and being surprised it phoned home, and it is the single easiest way to convert a “double-blind” vendor into a surveillance intermediary without changing a line of the vendor’s own code.
The second is the token that is secretly a session key. A verifier returns a “proof” that is really a per-transaction identifier the site can correlate with everything else it knows about the session — the IP, the account, the device. The attestation is anonymous in isolation and fully re-identifying the moment it lands next to a logged-in profile. Unlinkability across visits fails the same way: a token that is stable, or a timestamp precise to the second, hands colluding relying parties the join they need. The EU blueprint’s batch issuance and coarsened timestamps exist precisely to close this, which tells you the designers expected exactly this failure.
The third is the estimation-and-delete theatre. A provider takes a selfie for age estimation, promises to delete it in seconds, and treats that promise as if it were the privacy property. The study is explicit that rapid selfie deletion does not neutralise the threat — the leak, the misuse, and the cross-linking of identity and intent are the central risks whether or not the image is retained, because the linkage can be logged, inferred, or reconstructed from everything around the image. Deleting the selfie is good hygiene. It is not double anonymity, and marketing it as equivalent is the exact move the paper calls theatre.
None of these require a nation-state adversary. They fall to a curious engineer with browser dev tools open. That is what “failures against low-cost, widely accessible attacks” means, and it is why the gap between the standard and the deployment matters: a system that is private against no one in particular is a liability wearing the costume of a control.
Double anonymity is falsifiable — treat it that way
The genuine contribution of the study is that it turns a marketing claim into a measurable one. “Privacy-preserving” is a vibe. Double anonymity is a property with a truth value, and you can sit down and test it against a specific implementation. Three questions do most of the work, and every operator running an age gate should be able to answer them with evidence rather than a vendor’s assurance.
Does the site ever receive anything beyond the age bit — an identifier, a name, a token that correlates with a session? Does the verifier ever learn which site the user came from — through a referrer, a return URL, a per-site API key that tags the request, or a redirect that leaks the origin? And are two visits by the same user linkable by anyone who can compare notes — the same site over time, or two different sites colluding? If the honest answer to any of the three is yes, the system is not double-blind, regardless of what the datasheet says. This is the same discipline we argued for in proving age assurance works rather than asserting it: the claim has to be falsifiable, and the burden is on the system to demonstrate the property, not on the regulator to disprove it.
The architecture that passes this test is not subtle, and it is the same architecture that keeps the breach wave from being your incident. Collect as little as the check requires, and collect it as late as possible — most age gates need a cheap age signal, not a document, and a document read should be reserved for the narrow set of cases that genuinely need identity. Discard the source material the moment the decision resolves; a passport scan you never keep is a passport scan that cannot leak. And for the returning user, bind them to a reusable, cryptographically bound credential so that re-proving is a lookup against something the user holds, not a fresh upload that manufactures the dangerous record all over again. This is the same privacy-first posture we laid out in age verification without surveillance and the zero-knowledge-proof approach to age; double anonymity is what those principles look like when you hold both separations at once instead of one.
What Xident does here, and what it does not
We are deliberate about this boundary because double anonymity is exactly the kind of property a vendor can imply and not deliver. Xident runs two operations and keeps them apart. A Check is the cheap, fast path — a browser-based age signal, a liveness pass, a returning-user lookup — and it is designed to hand the relying party a decision, not an identity. A Verification is the heavy path, a document read and face match, reserved for the cases that actually need to establish identity rather than an age band. Each returns a structured decision with an audit trail, and the discipline that makes this safe is the discipline the paper is really about: what we keep is the decision and the proof it was made correctly, not the pairing of a person with the site they were proving their age to.
That distinction — decision-and-proof kept, identity-and-destination not assembled — is the difference between an audit trail and a surveillance log, and it is the whole game. An audit trail lets you answer a regulator’s information request and demonstrate the gate was working during a window under review. A surveillance log is the record double anonymity exists to prevent. They are not the same artefact, and a system that conflates them has failed the second separation while believing it passed.
What Xident does not do is decide whether you are in scope, in which jurisdictions, or which of your flows need identity rather than an age signal. That is a legal and product judgment that belongs with your counsel and your team, reading your traffic against the current law. Nor should any vendor, including us, be trusted on the double-anonymity claim on the strength of a datasheet. Run the three questions against whatever you deploy — ours included. The point of the “Compliance Theater” study is that the property is testable, and the only version of the claim worth anything is the one that survives the test.
Double anonymity is not a stricter version of “we care about privacy.” It is a specific, falsifiable architecture that keeps the one record you most need never to hold from ever being assembled. The regulations have written it down. The engineering to meet it exists. The gap the study found is the distance between the two — and closing it is a matter of building the separations in, not printing them on the box.
