Will Germany’s New eIDAS Mobile‑Wallet Rules Force Apps to Rely on Apple and Google?

# Will Germany’s New eIDAS Mobile‑Wallet Rules Force Apps to Rely on Apple and Google?

Functionally, for high‑assurance (AL‑high) identity use cases, Germany’s new Mobile Device Vulnerability Management (MDVM) approach can in practice push real‑world deployments toward relying on Apple and Google’s platform security hardware and attestation APIs—because that’s where widely deployed hardware‑backed key storage (HKS) and scalable device attestation signals are commonly available today. But it’s not a literal mandate to use Apple or Google: the proposal specifies capabilities (hardware key protection plus ongoing device trust verification), not vendors. In principle, other operating systems—or external secure elements—could meet the requirements. In practice, market reach and standardized integration may make iOS and mainstream Android a common path for serving an entire population.

What the German proposal requires (a quick primer)

Germany is implementing an EU Digital Identity Wallet (EUDI Wallet) aligned with eIDAS 2.0, under which every EU Member State must provide at least one wallet for citizens, residents, and businesses to prove identity, store/share credentials, and sign digital documents.

A key pressure point is assurance level “high” (AL‑high). Germany’s wallet is expected to support AL‑high for sensitive flows such as issuing Personal Identification Data (PID) and enabling mobile driving licence use cases. AL‑high is where the technical bar rises: the wallet’s cryptographic keys must be under sole user control and stored in certified hardware‑backed keystores (HKS), reflecting eIDAS 2.0 requirements and related implementing regulations (including references like CIR 2024/2979 Article 5, as cited in the brief).

Germany’s distinctive addition is MDVM (Mobile Device Vulnerability Management)—an architectural framework intended to ensure those high‑assurance keys are only used when the device is trustworthy. MDVM assumes a serious threat model: if vulnerabilities exist in the device’s secure key storage or OS environment, attackers may be able to extract keys or misuse them. So MDVM is built around the idea that AL‑high operations should be gated on ongoing device integrity and vulnerability posture.

The German MDVM concept is described as three pillars:

1. Signal collection: gather device and platform integrity/attestation signals (notably Android KeyAttestation, Google Play Integrity, and Apple App Attest).
2. Device‑class identification: map signals to a verified device model/OS version and assess HKS capability/status against required resistance levels.
3. RASP (Runtime Application Self‑Protection): in‑app runtime monitoring to detect rooting/jailbreak, emulation, tampering, and suspicious behavior—supporting ongoing assessment rather than a one‑time check.

How Apple and Google fit into the MDVM architecture

MDVM’s pillars line up closely with what the dominant mobile platforms already provide at scale:

• On the hardware-backed key storage side, mobile ecosystems typically expose HKS through platform mechanisms (for example, iOS hardware protections and Android hardware‑backed keystore options). The German requirement is not simply “store a key”; it’s store it in certified hardware in a way that supports non‑extractability and strong controls.
• On the attestation side, MDVM explicitly anticipates platform attestation signals such as Apple App Attest, Android KeyAttestation, and Play Integrity. These are mechanisms a backend can use to evaluate whether a key is hardware‑backed and whether the runtime/device environment is in an acceptable state.

This becomes especially concrete in the key attestation flow used during issuance of high‑assurance credentials such as PID. In Germany’s model, the Wallet Backend (WB) is expected to provide the issuing party with evidence—via a key attestation flow referenced in the documentation (with examples in the wider ecosystem including profiles that use OpenID4VCI)—that the wallet’s keys are controlled by an authentication means meeting the relevant security requirements (with the German documentation referencing attacker‑resistance evaluation concepts such as ISO/IEC 18045). Put simply: it’s not enough for a wallet to claim “this key is secure.” The backend and issuer need cryptographic and platform evidence that the key is anchored in appropriate hardware and is being used on a device that hasn’t drifted into an unacceptable risk state.

Because these HKS and attestation capabilities are mature and widely deployed on iOS and many Android stacks, AL‑high implementations may often end up using Apple/Google platform features as the most straightforward way to satisfy MDVM—while alternatives may take time to reach comparable deployment scale.

What this means for developers

For wallet providers, MDVM turns “support eIDAS” into a deeper engineering program:

• You’ll likely need to integrate platform attestation APIs and handle server‑side verification of attestation evidence, not just collect it in-app.
• You’ll likely need runtime protection/monitoring capabilities in the wallet app aligned with MDVM’s RASP pillar to support ongoing integrity assessment (with exact implementation choices varying by wallet design and policy).
• You should plan for fragmentation: devices differ by model, OS version, and hardware security characteristics. MDVM’s device‑class identification pillar implies ongoing mapping and policy decisions about what qualifies.

For relying parties (apps and services that accept wallet-based identity), the dependency can be indirect but real. If you want to accept AL‑high credentials issued under MDVM rules, you may end up depending on the credential issuance and validation chain that uses platform‑attested keys and device trust signals—even if your app never calls Apple/Google integrity APIs itself. Your product requirements may shift toward “accept what the wallet can safely issue,” rather than “accept any device-generated credential.”

Privacy, security, and vendor lock‑in concerns

MDVM’s security logic is straightforward: if AL‑high identity depends on a device-held key, you need confidence the key hasn’t been compromised and the environment isn’t hostile. Hardware-backed storage plus attestation and RASP raise the cost of attack.

But there are trade-offs:

• Privacy: Attestation is built from device signals. Implementers must be careful about what is collected, how long it is retained, and whether signals create linkability between device identifiers and identity attributes. The MDVM model assumes signal collection; privacy‑preserving design choices become pivotal.
• Centralized trust: Commentators note that leaning heavily on platform security stacks and their update cadence can create practical dependencies. Germany’s approach partially mitigates this by tying key use to device posture—if vulnerabilities emerge, the system can restrict use. But it still means the platform’s security model and integrity APIs may be foundational in many implementations.
• Practical dependency risk: The rules don’t name Apple or Google, but external analysis and ecosystem commentary highlight that population‑scale compliance may be easiest where certified HKS and widely integrated attestation services are already available. Until alternatives are widely deployed and standardized, stakeholders warn the ecosystem could behave as if it is dependent on a small number of platform providers.

(For another example of how platform security primitives can create practical dependencies, see How Apple’s New Signed eGPU Driver Works — and Why Mac ML Users Should Care.)

Why It Matters Now

This is timely because Germany is publishing and refining MDVM rules and technical documentation as it implements eIDAS 2.0 requirements for its national wallet. Early architectural choices tend to “set” interfaces: wallet implementations, backend verification services, and relying‑party expectations harden around whatever is required for initial rollout—especially for marquee AL‑high use cases like PID and mobile driving licences.

It also matters now because the MDVM documentation itself acknowledges areas that still need improvement—such as additional plausibility checks and more detailed functional decomposition. That combination—high assurance requirements plus evolving operational detail—means developers and implementers should expect iteration: device classes, acceptable signals, and policy thresholds may need updates as security conditions and platform capabilities change.

Practical paths and workarounds for developers

In the short term, the pragmatic path to AL‑high is:

• Build around iOS and Android platform HKS.
• Integrate and verify attestation signals (KeyAttestation / Play Integrity / App Attest) end‑to‑end, including backend validation.
• Add RASP (or comparable runtime integrity monitoring) and operational processes to react when device vulnerabilities or compromise indicators appear.

In the medium term, to reduce exclusion of users on unsupported devices, implementers can explore alternative channels mentioned in commentary around the ecosystem: support for external secure elements, smartcards, or companion-device models—where they can meet the “sole user control” and certified key storage expectations—alongside multi‑channel issuance approaches.

For ongoing influence, wallet and relying‑party teams should engage with the EU’s digital identity building blocks and technical work to push for clearer, interoperable (and privacy‑preserving) attestation expectations.

For more on the broader edge/security ecosystem pressures that can shape developer roadmaps, see Today’s TechScan: Agents, eGPU Mac Workarounds, and Oddball Open‑Source Wins.

What to Watch

• Whether non‑Apple/Google HKS and attestation options reach certified, widely deployable status for AL‑high use cases.
• Updates to Germany’s MDVM documentation and any clarifications in EU implementing regulations that affect which signals are acceptable and how privacy safeguards should be applied.
• How Apple and Google evolve their attestation APIs and terms, and whether interoperability and privacy‑preserving patterns become easier for national wallet deployments.

Sources: https://bmi.usercontent.opencode.de/eudi-wallet/wallet-development-documentation-public/v0.3.0/architecture-concept/06-mobile-devices/02-mdvm/ ; https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/694487738/EU+Digital+Identity+Wallet+Home ; https://ubos.tech/news/mobile-device-vulnerability-management-mdvm-in-german-eudi-wallet-key-insights/ ; https://www.digitale-verwaltung.de/Webs/DV/DE/digitale-identitaeten/eidas-2-0/eidas-2-0.html ; https://docs.eudi.dev/2.0.6/use-cases/mobile-driving-license/mdl-guides/wallet-provider/wallet-developers-workflow/ ; https://ubiqu.com/building-eidas-2-0-compliant-digital-wallets-the-technical-architecture-choices/