Most people think EU Age Control apps are about identifying users. The sales pitch is all zero-knowledge proofs of age. You prove you’re over 18 without the site learning your name, exact birthday or anything that can link one proof to another. The math works. SD-JWT or real ZK lets you release just the boolean while the verifier checks it against the government key.
That part actually works. Or can work, no production apps are released yet.
The whole story falls apart on several layers. Let’s stat by looking at what platforms are allowed to do under the DSA.
The DSA fallback nobody talks about
Big platforms must verify age for certain content. They can use the fancy EU wallet with its privacy features. They can also just plug in a normal KYC provider that scans your full passport, runs liveness checks and sees everything. Which path do you think most companies will actually take when the “privacy-preserving” option requires integrating with systems that barely exist yet across 27 countries?
It’s marketing sleight of hand. They push the privacy angle hard while the rules quietly allow the non-private fallback. The privacy part is optional. (I think they mainly know the apps will not be ready by the end of the year).
KYC companies have been avoiding real electronic IDs for years. I have a Slovak eID chip that’s been in my wallet forever. It has proper cryptographic keys and can prove who I am far more cleanly than a photo of my driver’s license plus video call. Yet almost every KYC provider still does the bitmap and liveness routine.
The reason is simple. Integrating with 27 different national eID systems — and then scaling that to the rest of the world — is a nightmare. Maintaining a database of what every country’s physical ID looks like is cheaper and works everywhere. The cryptographic route doesn’t. It could in theory (after all, it’s math), but in reality, it doesn’t. Which is not too bad of a thing – identity is still somewhat decentralized.
So the EU solution only “works” if platforms decide to do all that integration work themselves. Right now the official trusted list has zero production apps. The reference implementation is still half-baked. Some countries have national digital ID apps or local pilots they’re trying to bend into the EUDI shape. There are betas and tests running. Believing this turns into clean interoperability across all EU countries by the end of 2026 is wishful thinking (on the side of EU, our wish is they utterly and completely fail).
How verification actually works
Let’s look at how the verification actually works in the reference implementation.
The main high-assurance path in the reference app uses an NFC passport. You first scan the MRZ code (the machine-readable zone printed at the bottom of the photo page of the document). The MRZ gives the keys needed to read and decipher the data on the NFC chip. That chip contains signed data including a JPEG photo of the holder. The attested app then takes a live photo of the person standing in front of it and runs a local AI model to match the live face against the JPEG from the chip. This photo match is there to stop abuse — a kid scanning their parent’s passport to get a credential for themselves, for example. The app is open-source so you can read every line, but changing even one bit would break the hardware attestation. The binary must match exactly what Google or Apple signed. No GrapheneOS, no custom Linux phones.
Attestation locks it down. Funny, it’s the same EU that hates these American corporations and wants EU alternatives for everything. Yet no one can make a phone that would be usable for age verification without the blessing of Google (or Apple theoretically, but Apple does not certify third party devices for iOS at all). Bought a nice Huawei phone that you are happy with? Sorry. Bought a nice EU-friendly / made-in-EU Android or even non-Android phone? Out of luck. Use a Daylight computer (non referal link, it’s just a neat device) that does not break your circadian rhythm and is usable outdoors? Back to the office with junk lights and get a proper device!
OK, back to the reference app. There is a simpler route that only uses the MRZ scan. You can literally photograph someone’s ID card and the system can work with that. No NFC read nor photo match required. This path exists in the reference implementation but real national apps may not support it and the blueprint (reference app) recommends the high assurance path. Countries might and probably will force the stronger chip-based route (passport, eID or national ID card with chip). It’s a trojan horse to digital ID anyway, right?
(Side note: Even if countries supported the MRZ path, they would validate document data against the internal database of citizens and their documents – which the reference app doesn’t do, because they don’t have access to this database, it’s a reference app that shows countries how to use the libraries to create the proofs, not to do actual verification).
What’s private and what isn’t
The overall flow is local-first, but still needs a server to issue credentials. Scanning and initial checks happen on the phone. Because the app is attested the issuing server can be reasonably confident what exact code actually executed. The server verifies the document signatures (so even if you find a way around the attestation requirement, the electronic passport and ID card have cryptographic signatures which you can’t forge) and issues a signed credential or statement. That credential can then be turned into a local ZK proof or SD-JWT of age when talking to websites.
So from the provider’s (say a porn site or a social media platform) point of view this is truly unlinkable. You send them just proof that you are over 18, which they can’t (in case of ZK proof format) link to any previous proof. They can of course infer that you are an EU country citizen (and possibly which country). But they can’t tell which accounts are yours. This is the part that – if implemented in production – works.
From the issuer point of view – you get the credentials by presenting your ID in one form or another. They decide if you are in good standing and issue you the credential. The issuer does not know if you’ll use it for social media, porn, or anything like that. Not even how many times you’ve used it.
A cleaner design would eliminate the server (issuer) for the age proof entirely — a pure local ZK proof that the passport or eID signature is valid and the holder is over 18. No centralized issuer in the loop at all. This can be easily done with today’s tech. Slightly better, but not much – but at least it would still work if the issuer’s server is down. Now someone could DDoS the issuer infrastructure and deny people access to services needing age verification.
The Trojan Horse
In any case, this is the trojan horse.
Start with “protect the children from porn and scary social media.” Create enough friction that people reach for the convenient attested wallet. The app itself must be attested — which in practice means Google or Apple decide what runs. The credential can be killed by the issuer.
The reference app leaks face photos, although only locally. Twenty-seven countries will each build their own version. With their own privacy bugs.
Then you get the Hawthorne effect. Every controversial site that makes you pull out the wallet creates self-censorship, even if the proof is supposedly anonymous. Governments have a terrible track record protecting this data. Any data. History is full of examples.
(Want to watch porn? Criticize a politician? Are you really going to open the EU country’s ID app to verify that you are over 18 and believe it’s unlinkable ZK proof – even if it really is?)
Later they link it to Digital Euro and everything else. Suddenly a big chunk of your life can be switched off remotely. Didn’t pay a parking ticket on time? Well, let’s temporarily revoke your credentials, when you can’t login anywhere, you will come and pay the ticket.
The cryptography is solid. Or at least can be — there’s nothing released yet to production. The architecture and politics are the usual control layer with fresher paint.
We don’t need revocable digital IDs as the price of entry to the internet. We were doing just fine.
The privacy theater hides the wolf. The wolf is still there.
Are the published hacks real?
There have been several “hacks” mostly by people who don’t understand how this is supposed to work. Leaving files on disk in reference app is something that will be fixed in reference, but the reference app will not be used by any country directly, they will have their own bugs. The reference app is not to be used by any end user. It is for countries to know how to generate the proofs and how everything works in order to stay interoperable. It doesn’t even matter you can fool it into giving you a test credential – because the primary verification path will be countries’ eID systems, not their mock-up of unchecked MRZ scanner. That part already exists in many countries and will be unique to each country anyway.
There was a “hack” that created a custom Chrome extension. That would fail app attestation (the backend can’t verify it yet, because the app is not in stores yet, but app attestation verification is mandatory and if the phone’s CPU does not attest that it’s running unmodified official app and unpatched OS, the attestation would fail). Also, the MRZ path does not connect to real backend, because there’s no real backend on EU side, the registries of valid documents are competence of countries, so they will have to validate it per country.
I’m 99% sure that even though I consider EU completely incompetent, these particular class of hacks won’t work in production apps – and if they do, they fail the spec. And will be fixed quickly.
So this “haha, I hacked the app with my Claude Max subscription” doesn’t mean anything. They’re hacking a mock-up showing a use of a library. Yes, Frau Ursula called it “EU Age Verification app”, but it’s not an “EU Age Verification app” – there will not be an EU app, there will be Slovak app, Hungarian app, German app, Dutch app, French app, …
But Why?
Many of us naturally ask why people want this. I think it’s a mistake to think they don’t. There is demand for this. Internet is scary, parents think they can’t protect their children from many bad things happening and someone came to provide a “solution”. Doesn’t matter that I am sure that the kids will go around it easily. The clients (the voters) are not the children being protected, but their parents, feeling good.
I think a very good and deep explanation is in my novel Tamers of Entropy. Have a look. It is very cypherpunk / lunarpunk and explains also the psychology behind these dystopias. And a way outside. Plus it’s fun to read. Check it out at tamersofentropy.net (you can sign-up to learn when it’s out – very soon actually). The characters also have Nostr accounts.
Conclusion
The EU fancy zk apps will not be ready.
Platforms will use normal KYC providers, AI face age estimators and other means.
Fancy ZK apps will have bugs, but different bugs than the reference mock-up.
When done according to spec, the age verification app can’t track you, the platforms do not know your identity, or link your accounts, or track you in any way. The proofs are unlinkable.
The apps will not work unless you have a Google or Apple approved device. Forget Linux, GrapheneOS, Huawei, after-market firmwares (Calyx), … It’s part of the security model.