Waag argues that the 'high' Level of Assurance mandated by Regulation (EU) 2024/1183 can only be met today by storing cryptographic keys in vendor-controlled hardware — Apple's Secure Enclave and Google's StrongBox-backed Keystore. Because remote attestation flows through DeviceCheck/App Attest and Play Integrity API, two American companies with no treaty obligation to the EU become de facto gatekeepers of European digital identity.
By submitting Waag's critique to Hacker News where it accumulated 490 points, donohoe amplified the argument that a regulation marketed as European digital sovereignty has architecturally entrenched dependence on exactly two US vendors. The high engagement signals broad agreement that this is a meaningful policy failure.
The editorial highlights that EIDAS 2.0 never names Apple or Google but specifies a security level that resolves to exactly those two vendors. This mirrors the FIDO2 platform-authenticator pattern where 'passwordless' became 'whichever passkey provider syncs to your phone OS' — a recurring failure mode where neutral-sounding standards collapse onto duopoly implementations.
The editorial notes that a SIM-based secure element alternative would require coordinated MNO rollout across 27 countries, making it impractical on the 2026 timeline. Even Germany's BSI technical guidance (TR-03159) acknowledges the dependence issue but offers no concrete path off Apple and Google's attestation infrastructure.
Waag Futurelab published a sharp critique of the European Digital Identity Wallet (EUDI Wallet), the smartphone app every EU member state must offer citizens by 2026 under Regulation (EU) 2024/1183. The piece, which hit 490 points on Hacker News, makes a narrow technical argument with broad political consequences: the regulation's mandated 'high' Level of Assurance can only be met today by storing cryptographic keys in hardware the operating system vendor controls — meaning Apple's Secure Enclave and Google's StrongBox-backed Keystore.
The mechanism is remote attestation. Before a wallet can present a verifiable credential — your driver's license, your degree, your over-18 token — the relying party wants proof the key signing that credential lives in tamper-resistant silicon on a non-compromised device. On iOS this proof comes from DeviceCheck and App Attest. On Android it comes from the Play Integrity API, which checks `MEETS_STRONG_INTEGRITY` against a Google-signed manifest. Both APIs are gated services. Both vendors can throttle, revoke, or change them at will. Neither has any treaty obligation to the EU.
Waag's conclusion: a regulation marketed as European digital sovereignty has, in its implementation requirements, deepened the bloc's dependence on exactly two American companies. The German BSI's own technical guidance (TR-03159) acknowledges the issue but offers no path off it.
The interesting part isn't the politics — it's the architectural trap, and how cleanly it was set. EIDAS 2.0 doesn't name Apple or Google anywhere; it names a security level, and the security level resolves to two vendors. This is the same pattern as the FIDO2 platform-authenticator story, where 'passwordless' became 'whichever passkey provider syncs to your phone OS.'
The alternatives don't currently exist at consumer scale. A wallet built on a SIM-based secure element would require coordinated MNO rollout across 27 countries and a key-provisioning ceremony no carrier has shown appetite for. Standalone smartcards work — Estonia and Belgium have shipped them for two decades — but the EUDI regulation explicitly mandates a smartphone form factor for the baseline credential. EU-funded projects like NLnet's GNU Taler wallet and the OpenWallet Foundation reference implementations can produce the credentials, but they cannot produce the attestation. Without attestation, a credential signed on a rooted Pixel running GrapheneOS is cryptographically valid and operationally rejected.
Hacker News commenters pushed on this and arrived at uncomfortable specifics. Play Integrity already breaks on every major custom Android distribution: GrapheneOS, CalyxOS, LineageOS, /e/OS. It breaks on rooted devices used by security researchers. It has, on at least three documented occasions in 2024-2025, broken on stock devices for hours at a time when Google rolled out backend changes. The same outage on a wallet day would mean nobody in the EU can prove they're 18 to buy a beer.
The deeper point Waag draws out is one practitioners building anything attestation-dependent should sit with: you have offshored your trust root to a company whose business model includes deprecating APIs on 12 months' notice. SafetyNet was sunset in early 2025 after a decade of being load-bearing for banking apps; everyone migrated to Play Integrity because there was no other option. The migration was forced, the timeline was Google's, and there's no reason to expect the next migration won't be the same.
There's also a state-power asymmetry worth naming. If a member state government wants to issue a credential, it must do so through an API surface controlled by a US company subject to US extraterritorial law (CLOUD Act, export controls, OFAC). A future US administration with a grudge against, say, Hungary has a kill switch nobody in Brussels signed off on.
If you're building anything that touches EUDI Wallet — and the regulation's relying-party scope is broad: banks, telecoms, social platforms, age-gated services, employment platforms — treat Play Integrity and DeviceCheck as production dependencies with the same SLO discipline you'd give to Stripe or Twilio. They're external services. They fail. Build a graceful degradation path that doesn't lock users out entirely when attestation is unavailable, because over a five-year horizon it will be unavailable for some non-trivial number of hours.
For mobile teams: stop assuming attestation is a free signal. Every attestation call is a permissioned API hit against a vendor that can rate-limit you, and Google has already started enforcing quotas on Play Integrity for high-volume callers. Budget for the cost. Cache the verdicts where the security model permits. Have a story for the 3-5% of your users who run GrapheneOS or whose OEM ships a non-GMS Android build.
For anyone doing identity work in the EU specifically: the OpenWallet Foundation's reference implementation and the EU's ARF (Architecture and Reference Framework) are the documents to read. The protocol layer is open (OpenID4VC, mDoc, SD-JWT). The trust layer underneath is not. Knowing which is which determines what you can fork and what you can't.
The EU has until late 2026 to resolve this before the wallet becomes mandatory infrastructure, and the politically convenient answer — fund a European secure-element initiative, mandate hardware-backed Keystore implementations open to non-GMS Android — is also the expensive and slow one. The path of least resistance is to ship on Apple and Google's terms and hope the dependency never gets weaponized. That's roughly the same bet European cloud policy made on AWS and Azure a decade ago, and the receipts on that one are still coming in.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.