EU age check spec mandates hardware-bound attestation

"Hardware-bound attestation is a requirement of this project, not an implementation detail we can simply drop." That line, from a maintainer of the EU's age verification technical specification, settles a fight that has been running in the project's GitHub tracker since July 2025 and defines the architecture every European website doing age checks will eventually sit behind. The credential proving you are over 18 must be locked to a specific piece of hardware in a specific device. That is not up for discussion.

The uncomfortable part is what sits on the other end of that credential. The passport read, the face match against it, and the liveness check all happen on the user's own phone, and the issuer receives the result without any cryptographic proof that the checks actually ran. So the system binds an unverified claim to trusted hardware, very carefully.

RelatedChrome's Device-Bound Sessions Go Live to Kill Cookie Theft

What exactly is mandated, and what is not?

This distinction gets flattened in most coverage, and the flattening matters. Two different things are being conflated:

• Hardware-bound attestation is required. The credential must be tied to native cryptographic hardware where the device has it, meaning a secure element or equivalent. Maintainers have now stated plainly that this cannot be dropped.
• Google Play Integrity and Apple App Attest are not currently implemented in the reference app, and stricter checks such as root detection are left to individual deployers rather than mandated centrally.

So the sovereignty objection raised in the tracker, that the EU would be routing its own identity infrastructure through two American companies, is a forecast rather than a description of shipped code. It is a reasonable forecast. Once a member state deploying the app decides it wants assurance that the device is not rooted and the binary is not patched, Play Integrity and App Attest are the only mature options on the two platforms that matter, and the spec leaves that door open by design.

Who does hardware binding exclude?

The people locked out are not the ones the policy is aimed at. A hardware attestation requirement is trivially satisfied by a stock iPhone or a Pixel running unmodified Android with Play Services. It is a wall for everyone else.

Note the asymmetry that produces. A privacy-conscious user running a hardened, de-Googled phone specifically to reduce their exposure to American platform vendors may find themselves unable to prove their age, while an attacker running a stock device with a patched APK sails through. The threat model rewards the mainstream configuration and penalises the paranoid one, which is close to backwards.

Has anyone actually broken it?

Twice, and the second time with something a hobbyist assembled. The most recent bypass of the roughly two-million-euro app came via a Chrome extension. Yivi's published security analysis lays out why the app is soft in this direction: because verification runs client-side, an attacker can decompile and modify the APK, or use Frida to hook the functions that evaluate the face-match threshold at runtime, or skip the app entirely and speak the protocol directly. The analysis also flags contradictory requirements between sections 3.3.2 and 4.3 of the specification itself, and notes that no zero-knowledge proofs are implemented.

RelatedCongress Revives KOSA With App-Store Age Checks

The sharpest sentence in that writeup describes borrowing or stealing someone else's passport, defeating the on-device face match, and walking away with a valid credential bound to your own device. Bound, in that scenario, is doing no protective work at all. It has faithfully tied a stolen claim to your hardware.

1. Jul 16, 2025Issue #18 opened, "Do not add Google Play Integrity integration" argues US platform dependency undercuts EU digital sovereignty
2. Jul 10, 2026Latest reference app release Play Integrity and App Attest still not implemented
3. 2026App bypassed a second time this round via a browser extension, not a research team
4. Aug 1-2, 2026Maintainers reaffirm hardware binding as a hard requirement issue converted to discussion #19, debate still open
5. TBDMember-state deployments choose their own integrity checks the point where Play Integrity becomes a real dependency or does not

Our take

Hardware binding is a defensible answer to a real problem. It stops one credential from being shared with a thousand people, and for a system whose entire purpose is preventing exactly that, it is the obvious control to reach for. The criticism worth making is not that the requirement exists but that it is being asked to carry weight it cannot bear. Device binding constrains distribution. It says nothing about whether the underlying claim was ever true, and in this design the underlying claim is established by software running on hardware the attacker fully controls.

Fixing the front door is understood work, not research. Server-side passport validation, an Active Authentication challenge against the NFC chip so the issuer knows a genuine document was present, and zero-knowledge presentation so the credential does not become a tracking identifier. Yivi has been shipping that shape since 2025. Adding attestation on top of an unverified claim raises the cost of participating for people on open platforms while leaving the actual attack surface roughly where it was.

Original analysis by GenZTech, built on the project's own specification, tracker and published third-party security review.