What happened on 15–16 April 2026
On 15 April 2026, European Commission President Ursula von der Leyen announced in Brussels that the EU age verification app — often called the "mini-wallet" because it is a narrow subset of the forthcoming EU Digital Identity Wallet (EUDI Wallet) — was technically ready for deployment. Within 24 hours, security consultant Paul Moore published a short video on X claiming he could bypass the app's protections in under two minutes. News outlets picked it up quickly, and the story trended on Reddit with tens of thousands of upvotes across r/europe, r/privacy, r/technology, and r/BuyFromEU.
If you are running a merchant checkout, a verifier backend, or an age-gated platform, the headline "hacked in 2 minutes" sounds alarming. It is also misleading. Here is the technically accurate picture.
The three design flaws the researcher identified
Moore's analysis, drawn from the app's publicly readable Android source at eu-digital-identity-wallet/av-app-android-wallet-ui, focuses on three weaknesses in how the app manages local state on an Android device.
1. PIN decoupled from the identity vault
The app stores an encrypted PIN in its local preferences file. The encryption key, however, is not bound cryptographically to the credential vault where the signed age attestations live. By deleting the PIN-related entries in the configuration file and restarting the app, an attacker can set a brand new PIN while still inheriting the previous user's credentials. The vault accepts the reset PIN as a new legitimate access control, because the PIN and the credentials were never locked together.
This is a real design flaw. A privacy-first architecture should invalidate the stored credentials whenever the PIN is reset.
2. Rate limiting stored as a plaintext counter
The app protects against brute-force PIN guessing with a counter that increments on each failed attempt. That counter sits in the same editable configuration file as the PIN state. Reset it to zero and the app forgets every previous guess.
3. Biometric check gated by a boolean flag
Biometric verification is enabled or skipped based on a single true/false flag in the config. Flip it to false and the biometric step never runs.
The critical caveat the headlines omit
All three bypasses require physical access to a rooted, unlocked Android device. At that point, the attacker already has full read/write access to the app's private storage — the same access level the app itself has. This is not a remote exploit. It cannot be triggered over the network. It does not leak credentials off the device. No third party receives any personal data as a consequence of the bypass.
The top-voted comment on the r/europe thread put it simply: "with physical access to the unlocked rooted device — kinda an important part." That comment reached 140 upvotes inside a few hours precisely because Reddit's technical audience saw through the framing.
What this means for verifiers and merchants
If you are integrating age verification into a checkout or a platform, the relevant question is: can an attacker present a fraudulent age attestation to my backend? The answer, based on the current disclosure, is no. The bypass lets the attacker access their own previously stored credentials under a new PIN on their own compromised device. It does not let them forge a credential, mint a new one, or replay someone else's signed attestation.
The OpenID4VP protocol underpinning the remote presentation flow still works exactly as specified. If you want a deeper look at how that protocol protects verifiers from replay and credential tampering, see our deep dive on OpenID4VP and our technical explainer on how eIDAS verification works.
The legitimate structural concerns
Separate from the "hack" itself, the disclosure has surfaced two structural critiques that are harder to dismiss.
Platform lock-in. Because the app relies on operating-system attestation and signed binaries to prove integrity, it only runs on signed iOS and Android builds. A high-upvote r/privacy post argues that no libre client can ever ship, because any self-compiled binary will fail attestation. This matters if you are a European institution whose digital sovereignty mandate forbids hard dependencies on Apple and Google gatekeeping.
Google Play Services dependency. Hungarian developers on r/programmingHungary pointed out that the Android build requires Google Play Services to function. An EU digital identity tool that cannot be used without accepting a Google End User Licence Agreement sits awkwardly with the EU's stated independence from US hyperscalers.
The technically literate Hungarian discussion also made the most accurate positive observation: the underlying protocol stack — OpenID Verifiable Credentials plus OpenID4VP selective disclosure — is genuinely one of the more privacy-respecting designs currently deployed for age verification. The implementation issues are fixable; the cryptographic architecture is sound.
Why open source wins this round
The disclosure cycle itself is the strongest argument for the EU's open-source choice. The flaws were identified by an independent researcher reading public source code, reproduced inside 24 hours, and are already moving through the normal fix pipeline. A closed implementation would have shipped with the same bugs and nobody outside the vendor would have known until a real breach occurred.
We have written at length about why we picked the same approach for our own SDK — see Introducing OpenEUDI: our open-source verification SDK and the lessons the EU's audit teaches open-source wallet builders.
What merchants should do today
- Do not change your integration plans. The bypass does not affect the OpenID4VP presentation flow your backend verifies. Signed attestations are still cryptographically valid.
- Watch the fix timeline. The EU's reference Android app will be patched; the three issues above are straightforward software fixes.
- Separate age verification from account recovery. If your checkout stores any local state tied to a verified user, apply the lesson: bind access controls (PIN, passkey) cryptographically to the data they protect.
- If you are building your own verifier, use our privacy-first pattern — verify once, store only a boolean, keep no document images. See Privacy-first age verification with OpenEUDI for the reference implementation.
The broader picture
This story tells us three things about where the EUDI Wallet ecosystem stands in April 2026. First, the EU is genuinely shipping auditable code, and researchers are genuinely auditing it. Second, the wallet apps are being built as a substantial dependency on platform attestation — a trade-off with serious implications for sovereignty and portability. Third, the merchant-facing verification flow is untouched by this disclosure. If you were planning to add EUDI Wallet verification to your checkout, nothing about the last 72 hours should change that plan.
For a country-by-country view of where member states stand with their wallet rollouts right now, see our April 2026 EUDI Wallet rollout status. For the legal framework governing how users onboard onto these wallets, see our breakdown of Implementing Regulation 2026/798.
Looking for a verifier integration that is ready for EUDI Wallet today and upgrades to production automatically? See eIDAS Pro's managed plans or read the OpenEUDI SDK quickstart.
This article is also available on Dev.to.
Share this article
Help others learn about eIDAS verification