Introduction
At a high level, EUDI can easily be described as a digital identity framework that lets citizens use a digital wallet to prove who they are (and what they’re entitled to) across EU borders. The legal backbone is eIDAS 2.0, while the technical blueprint is captured in the Architecture and Reference Framework (ARF).
But there’s a practical detail hidden in plain sight: for most citizens, the EUDI wallet experience will be smartphone-based.
That means the core EUDI functionalities, e.g. managing credentials, authenticating with biometrics, and managing cryptographic keys, will largely run inside iOS and Android.
And these operating systems aren’t neutral pipes. Apple and Google already operate their own wallet ecosystems, with their own security models, UX patterns, and platform rules. Long before the first EUDI draft, they’ve been shipping:
- wallets for passes and payments,
- digital ID programs based on ISO mdoc/mDL,
- and recently, browser + OS APIs (Digital Credentials) that can change how credentials are requested and presented on the web. [3] [4]
In this blog, we’ll follow a simple storyline:
- What Apple and Google have already built.
- Where that overlaps with what EUDI wants to achieve.
- Where standards stop and platform power starts.
What Apple and Google have already built?
Both wallets seem to have started with the same general idea. In short, they aim to make your digital wallet have all the functionalities of its physical counterpart, e.g. facilitating payments, holding various documents, etc.
Evolution of the Apple Wallet
Apple’s path is relatively linear, shaping their wallet product one step at a time. At first, they were dealing with storing various barcode-like credentials (e.g. concert tickets, boarding passes), then they added payment capabilities, and finally introduced holding and presenting some real-world identity credentials.
2012: Apple Passbook
Apple introduced Passbook as part of its iOS 6 preview in June 2012, positioning it as a place to store boarding passes, movie tickets, and store cards.
Passbook established the two patterns Apple still uses today:
- A system-integrated container (pre-installed, first-party UX)
- A developer ecosystem around “passes” (issuers can add items via supported formats and APIs)
2014: Apple Pay
Two years later, Apple announced Apple Pay, describing an architecture built around NFC, a dedicated Secure Element, and biometric authentication.
That move changed Apple Wallet’s role. It wasn’t just a place to store barcodes anymore, it became a platform where banks, card schemes, and merchants can build upon Apple’s security and UX choices.
2021+: IDs in Wallet
Apple later announced it was working with US states to add driver’s licenses and state IDs to Wallet.
Under the hood, Apple ties the model to ISO/IEC 18013-5 (mobile driving license / mdoc). Apple’s platform security documentation states that IDs in Apple Wallet may use reader authentication “using the protocol defined in ISO/IEC 18013-5” and that session encryption is used to protect the data exchanged during presentation.
Evolution of the Google Wallet
Google’s path has been less linear than Apple’s (more rebrands and product splits), but the direction is similar.
2011: Google Wallet
Google’s original Wallet was payments-first and explicitly NFC-driven. Google’s own blog framed it as “make your phone your wallet”.
So the original wallet brand at Google was not tickets and passes first. It was tap to pay.
2018: Google Pay consolidation
In 2018, Google consolidated Android Pay and Google Wallet into Google Pay, explicitly describing it as bringing different payment experiences under a single brand.
2022: Google Wallet returns
In 2022, Google revived Google Wallet as the container app for cards, passes, and IDs (with Google Pay continuing as a payment service/brand). Google described Wallet as the place to store a wide range of items you’d normally keep in a physical wallet.
2023+: Wallet supports mdoc-based Digital IDs
Google’s digital ID work is now strongly tied to ISO mdoc/mDL.
Their developer documentation states that IDs in Google Wallet are implemented according to ISO 18013-5, and it describes in-person acceptance patterns (offline) and the reader/engagement model.
Google also maintains a Verify with Google Wallet developer program for organizations that accept IDs from the Wallet.
Overlap with EUDI
Now to the key question, how much of what they’ve built is EUDI-shaped?
While the overlap is real, it’s also easy to overestimate.
ISO mdoc / mDL is already a production reality on both platforms
ISO/IEC 18013-5 is the global standard behind mobile driving licenses (mDL) and mdoc-style mobile IDs.
Both Apple and Google are building their ID ecosystems on top of this:
- Apple’s security documentation for IDs in Apple Wallet references ISO/IEC 18013-5 reader authentication and session encryption.
- Google’s acceptance documentation states that IDs in Wallet are implemented according to ISO 18013-5.
And this intersects directly with EUDI, as the Architecture and Reference Framework explicitly mandates following the ISO/IEC 18013-5 standard for proximity presentation flows. Therefore, both Apple and Google already implement this branch of the required protocols and its corresponding cryptographic primitives.
For example, some US states already issue official documents in Apple and Google wallets.
Hardware-backed key custody is a platform primitive
The ARF introduces the Wallet Secure Cryptographic Device (WSCD) as trusted hardware that provides secure storage for cryptographic assets (e.g., keys) and an execution environment for security-critical functions. The important bit is that ARF treats this as an assurance boundary, not just an API, i.e. it’s about where keys live, how they are used, and what security level can be claimed.
In the “local WSCD” architecture type, it describes a WSCD embedded in the user device and accessed via OS-provided APIs. In practice, this maps to the hardware-backed key custody primitives exposed by iOS and Android.
This overlaps cleanly with how both platforms already expose hardware-backed key management to apps:
- On iOS, the Secure Enclave is described as a hardware-based key manager; when a private key is protected by the Secure Enclave, the app never handles the plaintext key material.
- On Android, the platform provides hardware-backed keystores.
In other words, a core ARF assumption, i.e. wallet keys being generated, stored, and used inside device-backed secure hardware, is already aligned with the native security primitives on both iOS and Android.
However, the ARF is also explicit that not every “hardware-backed keystore” is automatically a WSCD suitable for all key types (notably PID keys at LoA High), because WSCD/WSCA carry additional security and assurance expectations beyond generic keystore usage.
Two-step user authentication is a platform primitive
The ARF is explicit that Wallet Units must rely on two user authentication mechanisms:
- an OS-level mechanism used before any Wallet Unit operation, and
- an additional WSCA/WSCD-level mechanism that gates cryptographic operations for PIDs (and other High-security attestations).
Concretely, the ARF describes OS-level authentication as something the Wallet Instance forces the device OS to have active (multi-factor, with optional wallet-specific PIN), and it expects this mechanism to also be able to unlock the keystore(s) used by the wallet.
This maps directly to how both major platforms already work:
- iOS: apps can invoke system authentication via LocalAuthentication (Face ID / Touch ID / passcode), and can protect keychain items and private-key usage with access-control constraints such as userPresence (biometry or passcode) or biometryCurrentSet.
- Android: apps use BiometricPrompt (system-provided biometric UI), and can generate keystore keys that are only usable after user authentication via
setUserAuthenticationRequired(...).
So one of the ARF’s core operational assumptions — “wallet actions are gated by OS auth, and high-value crypto is gated again at key-use time” — is already aligned with the security primitives shipped by iOS and Android.
Platform attestation services can support wallet authenticity
The ARF treats wallet authenticity as an explicit prerequisite for wallet activation and subsequent credential issuance.
During Wallet Unit activation, the Wallet Provider must be able to authenticate the Wallet Instance (i.e., ensure it’s a genuine instance of that Wallet Solution, not a fake app), and then issue Wallet Unit Attestations (WUAs) and Wallet Instance Attestations (WIAs). The ARF is also explicit that it does not prescribe how the “Wallet Provider authenticates the Wallet Instance” step is implemented.
This maps naturally onto something mobile platforms already ship at scale, i.e. app/device integrity attestation services that can provide strong input signals to a backend during activation and issuance.
- Apple (App Attest / DeviceCheck): Apple describes App Attest as a way for an app to assert its validity so a server can more confidently grant access to sensitive resources, using Apple-attested keys and server-side verification.
- Android (Play Integrity API): Android positions Play Integrity as a backend-verifiable signal that requests are coming from an unmodified app, installed via Google Play, running on a genuine Android device.
So while WUAs and WIAs are EUDI-specific objects signed by a Wallet Provider, a major part of the plumbing needed to make them meaningful in practice, e.g. collecting and validating device/app integrity signals during activation and issuance, already exists as a native, widely deployed platform capability.
What stops Apple and Google from offering plug-and-play EUDI solutions?
The protocol-level overlap (ISO mdoc, OpenID-based flows, hardware-backed keys) is absolutely real, however the ARF couples those protocols with a regulated trust infrastructure and lifecycle controls that naturally sit outside the OS.
Therefore, in practice, offering a plug-and-play solution would also mean integrating with (and being constrained by):
Relying Party registration and purpose scoping. Relying Parties are expected to register and authenticate using access certificates, and (where issued) provide a registration certificate per intended use that constrains what attributes they are entitled to request. Wallets can compare what’s requested against what was registered, and inform the user if something doesn’t match.
Trust anchors distributed via Member State / EU mechanisms. Key ecosystem actors (Wallet Providers, PID Providers, Access Certificate Authorities, etc.) are trusted via Trusted Lists, with Member State-level lists and an EU-level aggregation model described in the supporting ecosystem services. This is operational infrastructure (publication, signatures, update cadence), not something a platform vendor can replace with “we support the standard.”
Revocation and “who is allowed to participate” enforcement. Wallet flows assume certificate-chain and status checks during transactions, not just successful cryptography. And Member States can suspend/cancel a Wallet Provider, moving it to Invalid status, after which issuers and relying parties refuse to interact with wallet units from that provider.
In short, Apple and Google can absolutely implement more of the technical stack, but being “EUDI-compatible” is not only a matter of speaking the correct protocols. It also requires participating in the EU/Member State trust fabric, i.e. registration, certification, trusted lists, and lifecycle enforcement.
These reasons make it less likely for Apple and Google to position themselves on the EUDI market as providers of the full, plug-and-play, standards and regulation compliant suite.
Where standards stop and platform power starts
The overlaps above mostly live at the “plumbing” layer, i.e. standardized data models, standardized protocols, and device security primitives that already exist on both platforms.
But for businesses and public-sector relying parties, what often matters just as much is how those protocols are invoked, what user experience is enforced, and which apps are allowed to participate. That boundary is where platform decisions start to matter more than standards.
Browsers as an Entry Point for Remote Flows
EUDI Remote Flows assume a relying party can request a verifiable presentation from a wallet over the internet, with the user consenting to what is shared. The ARF tracks the Digital Credentials API as the emerging “bridge” between wallets and the web.
The Digital Credentials API itself is a W3C specification that extends the navigator.credentials surface so that a user agent can mediate presentation and issuance of digital credentials “from a user agent or underlying platform.” In practice, that means the browser becomes the standardized way for a website to trigger a wallet interaction.
It’s also worth noting that “supporting Digital Credentials” does not yet imply a single uniform interoperability profile. The ARF’s own discussion of the Digital Credentials API highlights that implementations can differ across ecosystems, and that the exact payload format and protocol binding (e.g. ISO mdoc profiles vs OpenID4VP payloads carried over the API) matters for relying party integration.
Both major platforms are already building around this pattern:
- Apple: Apple’s “Verify identity documents on the web” session describes requesting information from IDs in Wallet via the Digital Credentials API, and Apple’s documentation introduces IdentityDocumentServices for apps that want to participate as identity document providers in these web presentment flows.
- Google/Android: Android describes digital credentials support via Credential Manager’s DigitalCredential API, with native support for OpenID4VP (presentation) and OpenID4VCI (issuance). The platform presents a selection UI and then routes the OpenID4VP request to the wallet that holds the chosen credential.
So even if the core EUDI protocols remain open and standardized, Apple and Google have a chance to position themselves so that the dominant way websites will integrate is via the two mobile browsers that sit on top of iOS and Android.
Additionally, even if websites call the same W3C API as described in the previous section, the user experience and routing semantics are largely platform-defined. Therefore, Apple and Google shape:
- what the selection UI looks like,
- which providers can participate (and under what authorization/entitlement model),
- and how policy decisions are surfaced to the user.
Distribution and eligibility are still platform-controlled
Even if EUDI standardizes protocols, most wallet deployments will still run through mobile platform distribution and permission models.
That means Apple and Google influence which wallet apps are easy to install, how they are reviewed, and what entitlements/privileges they can access (e.g. proximity UX, secure hardware usage, background behaviors, and system UI integration). This doesn’t change ARF requirements, but it strongly affects deployment reality for Wallet Providers.
Conclusion
Apple and Google haven’t built “EUDI wallets”, but they have built much of the environment EUDI will run in.
At the protocol and device-security layer, the overlap is already tangible, i.e. ISO/IEC 18013-5 proximity presentation is already implemented, hardware-backed key custody is a mature platform primitive, OS authentication is tightly integrated with key use, and platform attestation services map naturally onto the “wallet authenticity” problem.
At the ecosystem layer, EUDI remains fundamentally different: it is not a wallet feature, but a regulated trust network with Member-State governance (registration, trusted lists, lifecycle enforcement). That infrastructure is not something a platform vendor can easily substitute.
Where Apple and Google are likely to matter most is in the middle, i.e. the operational layer where issuers, relying parties and end-users actually experience EUDI.
Additionally, If Remote Flows on the web converge on the Digital Credentials API, then Safari/Chrome (and the OS frameworks behind them) become the default gateway between services and wallets.
In other words, the EU will standardize and govern the trust ecosystem, but Apple and Google will still heavily shape how easily that ecosystem can be reached, and under what constraints, from the devices people actually carry.