Regulation explainerDecentralised Identity (DID)

What eIDAS2 asks of relying parties, and how to prepare to accept the EU Digital Identity Wallet

The amended eIDAS Regulation gives people in the EU a European Digital Identity Wallet and obliges many online services to accept it. This explainer covers who must accept the wallet and from when, what registering as a wallet-relying party involves, which credential formats and protocols a verifier must handle, and a practical preparation plan. Dates reflect the texts at this page's review date; confirm them on EUR-Lex.

Reviewed 8 min read

On this page
  1. What the amended eIDAS Regulation changes for services that check identity
  2. The legal texts a wallet-relying party must read
  3. Wallet deadlines run from the implementing acts, not from the amending Regulation
  4. Does mandatory wallet acceptance apply to your service?
  5. A relying-party preparation plan
  6. Wallet framework terms used on this page
  7. Hypothetical: a bank onboarding customers from the wallet
  8. Where ledgers fit in the wallet framework, and where they do not
  9. Questions and answers
  10. Sources

What the amended eIDAS Regulation changes for services that check identity

Regulation (EU) 2024/1183 amends the original eIDAS Regulation, Regulation (EU) No 910/2014, and is widely called eIDAS21. It adds the European Digital Identity Wallet: an app each member state provides or recognises, which holds person identification data and electronic attestations of attributes and presents them to relying parties under the user's control1.

For a relying party, three things change. Some services become obliged to accept the wallet. Every service that wants to use it must register and declare in advance what data it will request. And the user sees each request, can refuse it, and keeps a dashboard logging every transaction, from which they can ask a relying party to erase data or report it to a data protection authority1.

Wallet deadlines run from the implementing acts, not from the amending Regulation

Does mandatory wallet acceptance apply to your service?

  • If

    You are a public sector body and your online service requires electronic identification.

    Then

    Accept the wallet alongside your existing electronic identification means.

    Article 5f(1) extends existing identification requirements for public services to the wallet1.

  • If

    You are a private relying party required by law or contract to use strong user authentication, in a sector such as banking, transport, energy, health, telecommunications or education.

    Then

    Accept the wallet on the user's voluntary request by the Article 5f(2) deadline, unless you are a micro or small enterprise.

    The duty targets services that already authenticate strongly1.

  • If

    You are designated a very large online platform under the Digital Services Act.

    Then

    Accept and facilitate the wallet for user authentication whenever a user asks.

    Article 5f(3) applies to these platforms whatever their sector1.

  • If

    You are a micro or small enterprise, or none of the cases above applies.

    Then

    Treat acceptance as an optional onboarding channel and weigh it against the cost of registration and integration.

    The wallet can still replace manual document checks, but no deadline applies.

A relying-party preparation plan

  1. Choose the journeys and the attributes

    List where the wallet would replace or supplement an existing check, such as onboarding, login, age confirmation or proof of address, and the minimum attributes each journey needs. This list becomes your registration, so challenge every attribute that is merely convenient.

    Owner
    Product, compliance, data protection officer

  2. Register and obtain certificates

    Register in the member state where you are established and plan for the access certificate your verifier presents to wallets, plus the registration information wallets show users about you2.

    Owner
    Compliance, security

  3. Select verifier software

    The reference framework requires wallets to support SD-JWT VC and the ISO/IEC 18013-5 format, uses OpenID4VP for remote presentation and ISO/IEC 18013-5 for proximity5. Choose a verifier that handles both formats over the channels you need and validates issuer signatures and status.

    Owner
    Engineering

  4. Connect trust lists and status checks

    Configure which identification data providers and attestation issuers you accept, sourced from member-state trusted lists rather than a hard-coded set, and how revocation status is checked at every presentation.

    Owner
    Security

  5. Design the journey and the fallbacks

    Support same-device and cross-device flows, explain why each attribute is requested, and keep another route for people without a wallet or whose presentation fails. Using the wallet is voluntary for users1.

    Owner
    Product, design

  6. Decide what you keep

    Store the attributes you need and evidence of which issuer vouched for them and when, with retention set in advance. Route erasure requests from wallet dashboards into your data-subject process.

    Owner
    Data protection officer

  7. Test with real wallets

    Test each wallet your customers are likely to use as member states release them, including revoked credentials and withheld attributes.

    Owner
    Engineering, quality assurance

Wallet framework terms used on this page

Person identification data (PID)
Core identity attributes, such as name and date of birth, issued to a wallet by a provider the member state designates.
Electronic attestation of attributes
An attestation in electronic form that allows attributes to be authenticated, such as a qualification, a licence or an account relationship1.
Qualified electronic attestation of attributes
An attestation issued by a qualified trust service provider that meets the requirements in Annex V of the amended Regulation1.
Wallet-relying party
A relying party that intends to rely on wallet units to provide public or private services through digital interaction2.

Hypothetical: a bank onboarding customers from the wallet

Where ledgers fit in the wallet framework, and where they do not

The wallet framework does not use a blockchain. Trust rests on certificates and trusted lists, and credentials pass directly between wallet and verifier. Teams already using W3C verifiable credentials can still connect, because the reference framework allows the W3C VC Data Model as an optional format for non-qualified attestations5; our credential format comparison sets out the trade-offs.

Ledgers have a narrower role. The amended Regulation recognises electronic ledgers as a trust service; a qualified one must be run by qualified trust service providers, establish the origin of its records, order them chronologically and make later changes detectable1. That suits issuer registers and audit trails, never the personal data in a wallet. The decentralised identity hub explains how the two approaches meet.

Questions and answers

Is accepting the EU Digital Identity Wallet mandatory for our company?

It depends on who you are. Public bodies whose online services require electronic identification must accept it. Private relying parties obliged by law or contract to use strong user authentication, in sectors such as banking, transport, energy, health or telecommunications, must accept it on the user's request unless they are micro or small enterprises. Very large online platforms must accept it for authentication. Others may accept it voluntarily.

Can we keep our current KYC or identity verification provider?

Yes. The wallet is an additional way for customers to present verified data, not a replacement for your compliance process. Ask your provider whether and when it will support wallet presentations, and who holds the relying-party registration. You remain responsible for customer due diligence decisions, the attributes you request and the data you keep, whoever operates the verifier.

Does the European Digital Identity Wallet use blockchain?

No. Wallets, issuers and relying parties rely on certificates, trusted lists and registers run by member states and the Commission, and presentations go directly from wallet to verifier. Distributed ledgers appear in the amended Regulation only as a separate trust service, the qualified electronic ledger, which can hold records such as issuer registers outside the wallet.

What happens if a customer refuses to share an attribute we requested?

The user decides at every request, so your journey must cope with partial presentations. If the attribute is legally required, explain why and offer another way to provide it; if it is not, it probably should not be in your registration at all. Refusals and abandoned presentations are useful evidence for trimming each journey to the attributes it truly needs.

Sources

  1. Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework — EUR-Lex · checked 10 October 2026
  2. Commission Implementing Regulation (EU) 2025/848 as regards the registration of wallet-relying parties — EUR-Lex · checked 10 October 2026
  3. Commission Implementing Regulation (EU) 2024/2982 as regards protocols and interfaces to be supported by the European Digital Identity Framework — EUR-Lex · checked 10 October 2026
  4. Regulation (EU) 2016/679 (General Data Protection Regulation) — EUR-Lex · checked 10 October 2026
  5. EUDI Wallet Architecture and Reference Framework: data model and data exchange protocols — European Commission · checked 10 October 2026

More in Decentralised Identity (DID)

Back to Decentralised Identity (DID)

Next step

List the journeys where you would accept the wallet

Send us the journeys, the attributes each uses today and your member state of establishment. We will reply with a view on whether acceptance is mandatory for you and what to prepare first.

Discuss wallet acceptance