Submitted the BMI architecture documentation to Hacker News, highlighting that the MDVM (Mobile Device Vendor Mediated) approach requires an active Apple ID or Google account for the wallet to function. The core concern is that a government-mandated identity system for EU citizens cannot operate without US tech company infrastructure.
Argues that the MDVM architecture undermines eIDAS 2.0's stated goals of privacy by design, user control, and technological sovereignty. The editorial emphasizes that outsourcing device attestation to Apple's App Attest API and Google's Play Integrity API means a regulation affecting ~450 million EU citizens is gated by US corporate cloud services.
Acknowledges that device attestation — proving the wallet runs on genuine, unmodified hardware rather than an emulator — is a reasonable security requirement for a government ID wallet. However, the editorial argues the failure is in outsourcing this verification entirely to Apple and Google's proprietary cloud services rather than building sovereign attestation infrastructure.
Notes that the architecture's reliance on Google Play Services means users of custom Android ROMs, de-Googled phones, or alternative mobile operating systems would be unable to use the digital identity wallet. This creates a de facto requirement to maintain a relationship with Apple or Google to exercise rights tied to government-issued digital credentials.
The German Federal Ministry of the Interior (BMI) has published its architecture documentation for the EUDI Wallet — the digital identity wallet mandated by the EU's eIDAS 2.0 regulation. The technical approach Germany chose is called MDVM: Mobile Device Vendor Mediated. The documentation, hosted on the BMI's public OpenCode platform, lays out an architecture where cryptographic key management and device attestation are delegated to the secure hardware and cloud services of mobile device vendors — meaning Apple and Google.
The post hit 300 points on Hacker News, and the reaction was immediate: Germany has designed a sovereign digital identity system that literally cannot function without a US tech company account. On iOS, the wallet relies on Apple's Secure Enclave and App Attest API, both of which require an active Apple ID. On Android, it uses Google's StrongBox keystore and Play Integrity API, which require Google Play Services and, by extension, a Google account.
This isn't a prototype or a proposal. It's the published architecture concept for Germany's implementation of a regulation that will affect ~450 million EU citizens.
The eIDAS 2.0 regulation was supposed to be Europe's answer to fragmented digital identity. The stated goal: every EU citizen gets a wallet that can hold government-issued credentials (national ID, driver's license, health insurance) and present them digitally. The regulation explicitly emphasizes privacy by design, user control, and technological sovereignty. The German MDVM architecture undermines all three.
The attestation dependency is the core problem. Device attestation — proving that the wallet app is running on genuine, unmodified hardware — is a reasonable security requirement. You don't want someone running a government ID wallet in an emulator. But the MDVM approach outsources this verification entirely to Apple and Google's proprietary cloud services. When your government ID depends on a device attestation call to a Google server in Mountain View, you've built a sovereign identity system with a foreign single point of failure.
The privacy implications are substantial. Apple's App Attest and Google's Play Integrity don't just verify hardware — they phone home. Every attestation check is a signal to the device vendor that a specific device is using a specific app at a specific time. For a digital identity wallet, this means Apple and Google will have metadata about when and how often citizens authenticate with their government credentials. The BMI documentation does not address how this metadata exposure is mitigated.
The exclusion problem is equally stark. Not everyone has a Google account — and some people actively refuse one. Privacy-conscious users running de-Googled Android (LineageOS, GrapheneOS, CalyxOS) with F-Droid instead of Google Play are completely locked out. A German citizen who chooses not to have a relationship with Google or Apple cannot use their own government's digital identity system. This isn't a theoretical concern — the de-Googled Android community is small but it's disproportionately composed of exactly the privacy-conscious citizens that eIDAS claims to protect.
The Hacker News discussion surfaced a pointed comparison: imagine if your physical passport required you to have an Amazon Prime membership. The analogy isn't perfect — the security rationale for hardware attestation is real — but the dependency structure is the same.
The MDVM approach isn't the only option. The EU's own architecture reference framework describes multiple security models. The most notable alternative is the SAM (Secure Accessible Module) approach, which uses a separate secure element — either a dedicated chip on the device or a removable smart card — for key storage and attestation. SAMs can be government-issued and government-controlled, eliminating the vendor dependency entirely.
France, for instance, has been exploring a hybrid approach that can fall back to a government-issued secure element. Estonia's existing digital ID infrastructure uses smart cards that work independently of any device vendor. The technology to build vendor-independent secure identity exists and is proven — Germany chose not to use it.
The likely reason is pragmatic: MDVM is cheaper and faster to deploy. Distributing physical secure elements to 80+ million citizens is expensive. Apple's Secure Enclave and Google's StrongBox are already in everyone's pocket. But "cheaper" isn't the same as "sovereign," and the BMI documentation doesn't make this tradeoff explicit.
There's also a standards gap. Apple's Secure Enclave capabilities differ from Android's StrongBox in subtle but important ways — key attestation chains, supported algorithms, and lifecycle management all vary. Developers building relying-party integrations will need to handle two fundamentally different attestation flows, with different trust anchors, different certificate chains, and different failure modes. This isn't a "write once" API.
If you're building services that will accept EUDI wallet credentials — and if you operate in the EU, you eventually will — the MDVM architecture has concrete implications.
First, plan for attestation API complexity. Your verification backend will need to validate attestation tokens from both Apple and Google, each with their own format, rotation schedule, and revocation mechanism. This is not a simple JWT check. Apple's App Attest uses CBOR-encoded attestation objects with a receipt-based fraud detection system. Google's Play Integrity returns encrypted, signed tokens that require server-side decryption via Google's API. You're building two integrations, not one.
Second, watch the political backlash. This architecture is going to face legal challenges. The GDPR implications of routing identity attestation through US tech companies are untested. If a court or regulator forces a redesign mid-rollout, every relying party that built against the MDVM attestation flow will need to rebuild. The smart move is to abstract your attestation verification behind an interface that can accommodate a SAM-based or hybrid flow later.
Third, accessibility testing matters. If your service requires eIDAS wallet authentication, you need to account for users who can't complete the flow — whether because they're on a de-Googled device, have an older phone without the required secure hardware, or simply don't have the right vendor account. Fallback flows aren't optional; they're a legal requirement under EU accessibility directives.
The German MDVM decision is a bellwether. If it stands, it sets a precedent that EU digital sovereignty is negotiable when deployment convenience is at stake. If it gets reversed — and the political and legal pressure is building — it will force a costly mid-stream architecture change that ripples through every relying party in the ecosystem. Either way, developers building for eIDAS should treat the current attestation architecture as provisional and design accordingly. The regulation's goals are sound. The implementation has handed the keys to the wrong landlords.
I attestation should be abolished altogether. An app should have absolutely no way of knowing what kind of device it’s running on or what changes the user has made to the system. It is up to each individual to ensure the security of their own device. App developers should do no more than offer recom
What if you „lose“ your google / apple account, like this sanctioned judge of the international criminal court? Crazy to imagine that we are still baking in dependency on US providers in european societies, even though there is clear indications we should be doing the opposite?
This is about mass surveillance and control.https://en.wikipedia.org/wiki/Edward_Snowden#RevelationsThe existence of eIDAS itself is already a big problem. They're going to try to gradually push laws to make it so that you'll need a government issued signature to do any
I am shocked that there isn’t more opposition from the general public to policies like this that erode privacy and freedom. I am a parent and can appreciate the need to control what children do on the internet, but at some point parents need to parent. I fear we’re giving up a lot of freedom and add
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
German implementer here. We have to use some kind of attestation mechanism per the eIDAS implementing acts. That doesn't work without operating system support.The initial limitation to Google/Android is not great, we know that, and we have support for other OSs on our list (like, e.g., Gra