The EUDI Wallet ecosystem, at a decision level

The chapters map onto the questions to ask before signing anything: which role are we in, which credentials do we need, which formats does the proposed solution parse, how does it establish trust, how is it certified, and what does it do when a presentation fails. A proposal that cannot answer these in its own words is incomplete.

Less than the full set. Article 5b and Article 5f of the regulation define the acceptance obligation and the limits on what may be requested. CIR 2025/848 governs registration. CIR 2024/2980 governs the interfaces you will be talking to. CIR 2024/2977 matters when you need to know what an attribute means and how it is named. Everything else is primarily the concern of wallet providers, issuers and certification bodies.

CIR (EU) 2026/1731, adopted 15 July 2026, is the most consequential change so far. Because the ARF had evolved substantially since December 2024, the Commission updated the referenced standards across CIRs 2024/2977, 2024/2979, 2024/2980 and 2024/2982 rather than leaving implementers to reconcile the difference. Notable points: the wallet instance attestation is defined, credential format annexes are replaced with current ETSI and ISO references, and online cross-device flows are addressed explicitly, including which local communication channel gatekeepers should enable.

CIR (EU) 2026/1730, adopted the same day, is the registration counterpart, updating the standards that national registers and the certificates issued to relying parties have to follow.

Both went through public consultation as a single draft between 5 February and 5 March 2026. Draft acts are published for feedback before adoption, usually for four weeks, and reading the draft is the earliest reliable signal that an integration will need to change. Where a draft is open at the time of a review it is added here; the Commission's own page is the authoritative view of which acts are adopted, in preparation or under consultation.

The ARF is not law, but it is where the technical detail is worked out, and it moves faster than the acts. Only the releases that changed something substantial are listed. Every version remains published, which matters when a vendor claims conformance: the useful question is conformance to which release.

A wallet provider is either a Member State, a body mandated by one, or a private provider recognised by one. What it provides is a certified wallet solution; what a person holds is a wallet unit, a specific installation bound to that person and to secure hardware. The provider is certified, supervised, and required not to have visibility into the transactions the user performs.

A PID provider issues the identity data itself, under the authority of a Member State and at assurance level high. Attestation providers issue everything else: qualified attestations if they are qualified trust service providers, public-sector attestations if they are the public body holding the authentic source, and non-qualified attestations otherwise. An issuer is responsible for the accuracy of what it issues and for publishing status information so a verifier can tell whether an attestation is still valid.

A relying party is any service requesting data from a wallet. It has to register before it can do so, and it may only request what its registration covers. An intermediary acts on behalf of relying parties, which shifts integration effort but not accountability: the relying party remains the one whose purpose is declared and whose name the user sees. Using an intermediary also means a third party sits in the path of the data, which is a data protection decision as much as a technical one.

Member States designate supervisory bodies for trust services and wallets, accredit conformity assessment bodies, and publish trusted lists of who is entitled to act in each role. The Commission maintains the surrounding infrastructure that makes those lists resolvable across borders. For a relying party, this layer is mostly invisible until something fails, at which point it determines whether a presentation from another Member State validates or not.

Organisations that already hold authentic data about people, such as employers, universities, insurers or professional chambers, can also issue attestations. That is a different role with its own obligations: attribute semantics, revocation, retention, and in the qualified case, becoming or contracting a qualified trust service provider. The decision to accept credentials, to issue them, or both, should be taken early, because the two projects have little in common beyond vocabulary.

For a credential to be interoperable, the parties have to agree not only on the format but on what each attribute means and how it is identified. That is what rule books do: PID and mDL have had them the longest, and further rule books arrive as sectoral use cases mature. If an attribute you need is not covered by a rule book, expect bilateral agreement and reduced portability across borders.

Start from the legal requirement, not the data model. If a regulated identification is required, PID is the answer. If you need a fact about the person rather than their identity, look for an existing attestation type before assuming you need identity data at all: an age check does not need PID, and an entitlement check often does not need a name. Requesting less is not only a privacy position, it also widens the set of wallets and Member States your flow works in.

Selective Disclosure for JSON Web Tokens was published as RFC 9901 in November 2025. The mechanism is simple in principle: the issuer replaces claim values with salted hashes and hands the actual values to the holder separately, so the holder can reveal a subset while the issuer's single signature still verifies. SD-JWT VC builds credential semantics on top of that, and the issuance and presentation protocols reference a frozen draft version of it, which is why version pinning matters in procurement documents.

The mdoc format assumes the verifier may be offline and the exchange may happen over NFC or Bluetooth, so it is compact, binary, and carries its own device authentication. ISO/IEC 18013-5 covers the in-person case and 18013-7 extends it to online presentation. Because mDL deployments predate the wallet outside Europe, this is also the format where interoperability with non-EU verifiers is most realistic.

It hides the values that are not presented. It does not, on its own, hide that a presentation happened, which issuer signed the credential, or that two presentations came from the same credential. Reducing that last property, linkability, requires additional measures such as issuing batches of single-use credentials or using zero-knowledge proofs, and those are design choices made per credential type rather than properties of the format.

A credential can be suspended or revoked, and a verifier is expected to check. Status is published by the issuer, typically as a status list that the verifier fetches, which introduces a privacy trade-off of its own: fetching status for one credential reveals interest in it. Expect the interoperability profile to constrain how status is expressed and how issuer keys are resolved, because that is where verifiers most often diverge.

The base protocols are flexible by design, and two conformant implementations can still fail to interoperate. The OpenID4VC High Assurance Interoperability Profile, HAIP, exists to remove that flexibility: it selects the flows, the credential formats, the crypto suites, the issuer key resolution mechanism and the attestation requirements that participants must implement. When a vendor says they support OpenID4VP, the useful follow-up question is which profile and which version.

Same-device means the wallet and the service are on the same phone, or the browser mediates the exchange on a desktop. Cross-device means the service shows a QR code and the wallet on another device scans it. Cross-device is convenient and is also where the known attacks live: a QR code can be relayed to a victim who then approves a request they did not initiate. This is why verifier authentication and registration are not bureaucratic overhead, they are the mitigation.

Presentation requests are expressed in a query language that lets a verifier ask for specific claims across credential formats, rather than for whole credentials. Requests can also bind to transaction data, so what the user approves in the wallet is tied to a specific action, such as a payment or a signature, rather than to a generic consent. Both features are the difference between a demo and something that survives a security review.

Registration happens with the body designated by the Member State where the relying party is established, and it records who you are, what attributes you intend to request and for what purposes. The registrar publishes that information, and wallets consult it. Two consequences follow: an unregistered verifier does not work at all, and a request that exceeds the registration is visible as such, both to the wallet and to the user.

Each Member State publishes lists of the entities entitled to act in each role: wallet providers, qualified trust service providers, PID providers, registrars. Those lists are the root of the trust decisions made at runtime. For a verifier, the operational consequence is that trust anchors are configuration that changes, needs monitoring, and has to be refreshed without a code release.

If any of these fail, the user sees a warning or nothing at all, and no data leaves the wallet. From the outside this looks like an integration bug, which is why registration and certificate handling should be verified before functional testing starts.

The regulation requires that a wallet issued in one Member State works in all of them. Making that true depends on national trust infrastructure being live and mutually resolvable, and on registrars being reachable across borders. ARF v3.0.0 sharpens this area, including more complex registry arrangements. Until it is proven in production, testing against more than one Member State's environment is the only reliable way to know whether a flow is genuinely cross-border.

Wallet attestation lets a wallet prove that it is a genuine instance of a certified wallet solution. Key attestation lets it prove that a specific key lives in hardware that meets the required standard. Both are why a stolen credential file is not useful to an attacker, and both are why a wallet cannot be reimplemented as an ordinary application. For a verifier, the relevant part is that these attestations must be validated, not merely received.

Wallet solutions are certified against national schemes operated by conformity assessment bodies accredited in each Member State, and the ARF now separates cybersecurity evaluation from functional conformance. The functional conformance framework introduced in v3.0.0 provides shared, reusable test cases so that interoperability can be assessed consistently rather than demonstrated ad hoc. Relying parties are not certified in the same sense, but they are registered and supervised, and in regulated sectors their use of the wallet will be audited like any other identification control.

Certification freezes an assessment, not an environment. Operating system changes, rooted devices, malware and the app store distribution path all remain live risks, and the public bypass of an early age verification demonstrator showed that a reference implementation is a starting point rather than a hardened product. Verifiers should assume that some presentations will be attempted from compromised devices, and rely on attestation validation rather than on the wallet being trustworthy by definition.

Linkability is the risk that two separate presentations can be recognised as coming from the same person or the same credential, even when no identifying attribute was shared. It arises from reused signatures, reused credential identifiers, and status checks. The countermeasures in use today are batches of single-use credentials and per-verifier pseudonyms; zero-knowledge approaches, which would allow reuse without correlation, are being added but should not be assumed to be available yet.

A request can indicate whether the verifier intends to retain the data, and that intention has to match both the registration and the legal basis you rely on. Verifying an attribute and storing it are separate decisions: many flows need the check and not the value, and keeping less is the cheapest available risk reduction. Where retention is genuinely required, for example under anti-money-laundering rules, the reason should be recorded once and referenced afterwards.

Wallet, issuer and verifier components are published as open source and track the ARF. This is the right place to establish baseline conformance: whether your requests are well-formed, whether you parse both credential formats, and whether your validation logic is complete. It is not a certified wallet and it does not represent any Member State's trust infrastructure.

Several Member States operate their own test environments alongside their wallet projects. These are where country-specific trust anchors, registration procedures and credential availability become visible, and they differ from each other in ways that matter for a cross-border service. If your users are concentrated in a few countries, these are the environments that predict your production behaviour.

Aggregator playgrounds let one verifier integration be exercised against several wallet implementations at once, which is the fastest way to find out that a flow works with one wallet and not another. They are particularly useful for format coverage and for cross-device behaviour.

The obligation attaches to public sector bodies, to very large online platforms under the Digital Services Act, and to private parties that are required by law or contract to use strong user authentication for online identification, which covers banking, payment and e-money institutions, telecommunications, and sectors with statutory identification duties. An ordinary online shop is not obliged, and may still integrate: acceptance is a floor, not a ceiling.

Wallets will appear in onboarding flows during 2026 whether or not an obligation binds yet. The work that pays off in this window is scoping attributes per flow, completing registration, and testing validation against more than one wallet. Organisations that wait for the obligation date will be procuring, registering and integrating at the same time as everyone else.