A single line in a technical specification is turning into one of the messiest fights in the EU’s push for digital identity. The document lays out how age verification apps for the EU Digital Identity Wallet are supposed to work, and buried inside it is a hardware requirement that has developers accusing the project of quietly building a system that only works if you own an Apple or Google device.
- What’s happening: the EU’s age verification app spec requires apps to use a phone’s built in secure hardware chip whenever one is available.
- The problem: that hardware is only reliably reachable through Apple’s iOS or Google’s Android, often through Apple and Google’s own proprietary verification layers on top of it.
- Who’s affected: Linux phones, custom ROMs, rooted devices, and privacy focused builds like GrapheneOS.
- Where the fight is happening: a GitHub issue on the project’s official repository, closed by a maintainer as “completed” while the argument kept going for weeks.
The Line That Started It All
The rule at the center of the fight is short. Age verification apps built under the EU Digital Identity Wallet framework are required to rely on a phone’s native cryptographic hardware, things like Apple’s Secure Enclave or the Trusted Execution Environment (TEE) and StrongBox found in newer Android phones, whenever that hardware is present. It’s the same kind of chip that protects your fingerprint data or your banking app’s login keys. On paper, that’s good security practice.
The catch is what “available” ends up meaning once real devices are involved.
A Developer Flagged It, and the Maintainer Shut the Door
In April, a contributor going by 0xE70000000 opened issue #117 on the project’s Android wallet repository, arguing that leaning on hardware only found in a narrow set of locked down devices would make it effectively impossible to ever support open platforms. Their suggested fix was blunt: drop the hardware bound approach entirely.
A maintainer, manecke, replied about a month later. Hardware bound attestation, they said, is a requirement of the project, not something that can simply be dropped. They invited concrete proposals against the technical spec and promised a security review and threat model covering the tradeoff would be published soon.
Then they closed the issue as completed.
That did not end the conversation. It just moved it into the comments, where it kept going for weeks.
Why This Is a Linux Problem
The practical effect of the rule is where things get uncomfortable. Hardware backed security chips exist across the industry, but the software layer that actually certifies a device as trustworthy is controlled almost entirely by two companies. Commenters on the thread walked through what that means for anyone not running a fully stock, fully locked device:
- Rooted phones lose the ability to pass verification, regardless of how the rooting was done
- Custom ROMs like LineageOS are excluded by default
- Even GrapheneOS, a security focused Android fork built specifically to be more private than stock Android, can hit the same wall
- Linux phones and any non Apple, non Google mobile OS have no path to compliance at all
One commenter put it in the most concrete terms possible: households running Linux or a Raspberry Pi for their kids would have no way to access any site or service that requires this kind of age check.
The GrapheneOS Wrinkle
GrapheneOS is the example everyone in the thread kept coming back to, because it breaks the assumption that this is simply about hardware. GrapheneOS runs on Google’s own Pixel phones and does support hardware bound attestation using the same secure chip Google ships. What it fails is Play Integrity, a separate proprietary Google system layered on top that checks whether the software itself matches what Google considers an approved, unmodified build. Apple runs an equivalent check called App Attest.
That distinction, hardware attestation versus Play Integrity, is the crux of the entire argument. One is a security capability built into silicon. The other is a private company’s opinion about which operating systems deserve to be trusted.
There’s a technical nuance worth adding here too. According to one detailed breakdown in the discussion, these checks may only matter at the moment credentials are first issued, not every time the app is used afterward, since a trusted authority hands out a batch of proofs that the app then burns on its own. Whether that assumption survives a device being compromised later is a fair question, and one the commenter raising it admitted was shaky. But it does mean the dependency on Google or Apple’s servers may be less constant than the headlines suggest.
“Not Mandatory” Is Doing a Lot of Work
Partway through the thread, a commenter quoted the project’s actual documentation, which draws a narrower line than you’d expect. Stricter checks like root detection, Play Integrity, and App Attest are not required by the reference implementation itself. Whether to add them is left up to whoever actually deploys the app, whether that’s a national government or a private verification provider.
That sounds like a meaningful carve out until you think about the incentives. If you’re a government agency responsible for proving a user is actually an adult, and one of the checkboxes available to you is “reject anything that might be a modified or rooted device,” you’re going to check that box. Nobody deploying an age verification system is going to leave the stricter option off out of respect for de-Googled phones.
Several commenters made the same point from a different angle: attestation only works as a security guarantee if it applies consistently. If a device can simply claim it lacks the required hardware and skip the check, the whole system loses whatever protection it was supposed to provide. So the real choice is between requiring it everywhere or not having it at all. “Optional depending on availability” doesn’t hold up as a middle ground.
The Irony the EU Might Be Missing
A Law Built to Stop This Exact Thing
What makes this land harder is timing. The EU has spent years building legal tools aimed at reducing its dependence on Apple and Google, the Digital Markets Act (DMA) chief among them, forcing both companies to open up their platforms to competitors. Commenters pointed out the contradiction directly: a flagship EU digital identity project may end up requiring, in practice if not on paper, the exact proprietary systems the DMA was built to weaken. One reply noted that even the DMA’s win on iOS is limited, since Apple still approves every app and there’s still no way to run a different OS on an iPhone at all.
Open Source, as Long as You Don’t Look Too Close
There’s also a branding problem. The wallet app’s source code is public, which lets the project call itself open source. But if the actual trust decision, the part that decides whether your device is allowed to participate at all, routes through a closed and unauditable system controlled by a foreign company, publishing the interface code doesn’t change who’s really in control. More than one commenter called this open source washing. Another pointed out that even a self compiled, unmodified build of the app would fail verification unless it carries an official government signature and gets installed through the Play Store with a Google account attached, neither of which has anything to do with whether the code itself can be trusted.
The Alternatives Nobody’s Using
None of this is happening in a vacuum where hardware bound attestation was the only option on the table. Over on Reddit, one popular reply pointed to U2F, the open authentication standard already used for high security government logins. It’s fully certified, available from multiple vendors, several of them European, and some implementations are open source down to the firmware.
Back on GitHub, another proposal centered on the chip already sitting in most EU citizens’ wallets: the electronic ID card. The idea would use a USB or NFC reader to generate an age proof straight from a government issued ID, through an open protocol anyone could reimplement. Critics of that approach raised their own concerns, mainly around what happens if a compromised computer gets access to the same reader used to sign legal documents. But it at least avoids requiring anyone to own a specific brand of phone.
What Happens Now
The maintainers still owe the community that security review and threat model they promised. Issue #117 is marked closed, but nothing about the underlying disagreement is actually resolved, and new comments were still landing weeks later. For now, the honest answer to whether a Linux phone, a rooted Android device, or a privacy focused build like GrapheneOS will work with the EU’s age verification system is that it depends on choices individual deployers haven’t made yet, using a spec that gives them every reason to lock things down as hard as possible.
If you care about running hardware you actually control, this is worth watching closely.
Do you think hardware bound attestation can work without handing Apple and Google the keys, or is this the moment Linux and de-Googled phones get locked out of half the internet? Let us know in the comments.
