The reference implementation stores every age credential's keys in tamper resistant chips on the phone — Android's Trusted Execution Environment (TEE), Google's StrongBox secure element, or Apple's Secure Enclave — so they cannot be exported to
The EU's open-source age-verification project treats hardware-bound device attestation as a mandatory architectural requirement, according to a project maintainer's comment on the project's own GitHub repository. The choice moves the trust root for every age credential from auditable software into vendor-controlled silicon. With it, the project also decides which devices and which apps a society treats as trustworthy.
The reference implementation generates the keys backing an age credential inside the phone's secure hardware: Android's Trusted Execution Environment (TEE) and StrongBox on Google devices, and Apple's Secure Enclave on iPhones. The intent is narrow: prove a user is over a threshold age without revealing a name, exact date of birth, or the full identity document. The mechanism is broad. No community build, custom Android, or Linux desktop can recreate the keys, because the keys are not exportable from the chip that generated them.
"Hardware-bound attestation is a requirement of this project, not an implementation detail we can simply drop," the maintainer wrote on the project's issue tracker. The framing was a direct response to contributors asking whether the requirement could be relaxed for non-Google, non-Apple, or otherwise unapproved devices.
That distinction, between the required hardware root and the stricter deployer-side checks, is the architectural hinge the project's own spec preserves. The reference blueprint does not universally mandate root detection, Google Play Integrity, or Apple App Attest, and leaves those to the entities actually issuing the age credential. Hardware-backed key storage does not, by itself, force a server to approve the whole device, operating system, or app build.
A second decision runs in parallel. Proof of Age providers are expected to issue real EU-issued age credentials only to applications that appear on a list curated by the European Commission. Publishing the source code does not, on its own, place a community build on that list. "Open source" here becomes a code-availability claim rather than a system-trust claim.
Linux is not explicitly banned: a desktop Linux user can open a website, scan a QR code with a supported mobile wallet, and complete an age check that way. The architecture does not include a native Linux wallet, and alternative mobile operating systems that cannot meet the required trust conditions may struggle to obtain EU-issued credentials directly. Phones running independently built versions of Android (LineageOS, GrapheneOS, or any other custom ROM) fall on the same side of the line as a Linux PC, because the trust root they would need is not a build they control.
The second-order stakes reach the EU's broader EUDI digital wallet strategy. The same architectural posture, with keys in vendor silicon and an app list curated by the Commission, is the shape the EU's general-purpose digital identity wallet is taking. If the age-verification project ships its current trust model and the larger wallet follows, the open-source community's relationship to EU-issued identity credentials becomes a matter of negotiating with the European Commission's roster of approved apps, not of auditing the wallet code.
The discussion paper on Wallet Unit Attestation in the EUDI Architecture and Reference Framework sits at v0.4, a working draft rather than a finalized spec. The maintainer's commitment to publish a dedicated security review and threat model, plus the open invitation on issue #117 for alternative architectural proposals, is the next concrete artifact. The architecture ships when that document does.