What is eIDAS 2.0? A Practical Primer for Product and Compliance Teams - Arbiter Blog

If you work in regulated finance or healthcare in Europe, you have probably been hearing about eIDAS 2.0 in roughly the same sentence as KYC, Strong Customer Authentication, patient portals, and "we should probably look into that." This piece is meant to give you orientation before your next planning cycle, without the marketing fog.

Let us start with what eIDAS 2.0 actually is.

eIDAS 2.0 is a regulation, not a product

eIDAS 2.0 is the colloquial name for Regulation (EU) 2024/1183, which entered into force on 20 May 2024. It amends the original eIDAS regulation, Regulation (EU) No 910/2014. The thing that confuses people: the regulation does not ship as software. It tells member states to provide European Digital Identity Wallets ("EUDI Wallets") and tells certain relying parties they must accept those wallets in defined situations.

So when someone says "are you eIDAS 2.0 compliant," they are usually mixing two questions. One is regulatory: do your processes meet the obligations the regulation places on your sector? The other is technical: can your systems accept a presentation from an EUDI Wallet using the protocols and credential formats the ecosystem has settled on? Both matter, and they are not the same project.

Why the EU rewrote eIDAS

The original 2014 regulation defined trust services (qualified signatures, seals, timestamps) and a notification mechanism for national electronic identity schemes. The trust services part worked. The cross-border eID part did not.

In practice, very few people used their national eID outside their home country. Member states notified schemes at uneven paces. Acceptance by relying parties was inconsistent. Meanwhile, private-sector identity (sign in with a large US platform, upload your passport to a verification vendor) filled the gap. The Commission's view, which you can read in plain language on the official EUDI regulation page, was that Europeans needed a portable, user-controlled, privacy-preserving alternative.

eIDAS 2.0 is the answer. It is opinionated in two important ways. Member states must provide wallets. And specific relying parties must accept them.

The EUDI Wallet, briefly

The wallet is a mobile application. Each member state issues at least one, either directly or under its authority. A wallet is not "an app from Brussels," and it is not Apple Wallet or Google Wallet with new branding. It is a regulated piece of national digital infrastructure with strict interoperability requirements set by the EU.

The wallet carries three categories of data. The first is Person Identification Data (PID): the core identity attributes a citizen needs to prove who they are, issued by a member state authority. The second is Electronic Attestations of Attributes (EAAs): credentials about you that are not your core identity, such as a professional qualification, a student status, a driving entitlement, or an insurance membership. The third is Qualified Electronic Attestations of Attributes (QEAAs), which are EAAs issued by a Qualified Trust Service Provider and carry a higher legal weight.

A useful mental model: PID is who you are, EAAs are what about you. Both live in the same wallet on the same device, and the user controls what is shared, when, and with whom.

Who has to accept wallets, and roughly when

Here is the part product and compliance leads usually care about most. Member states have to make wallets available within roughly 24 months of the relevant implementing acts being adopted. Once wallets are available, specific private-sector relying parties have to accept them in defined contexts.

The regulation calls out sectors directly. The table below is a sketch, not legal advice. Confirm scope with counsel before you build a roadmap on it.

Sector	Why it is in scope	Typical wallet use case
Very large online platforms (VLOPs under the DSA)	Strong identity assurance for users on dominant platforms	Account verification, age assurance
Banking and financial services	Customer onboarding, SCA, regulated transactions	KYC at account opening, payment authentication
Telecommunications	Subscriber identification, regulated service provisioning	SIM registration, prepaid identity checks
Energy and utilities	Account creation for regulated services	Switching providers, opening a supply contract
Transport	Ticketing, vehicle registration touchpoints	Driving entitlement attestation, ID at hire
Postal services	Identity for registered delivery and certified processes	Pickup of registered parcels
Healthcare	Patient identification, cross-border health services	Portal access, eligibility checks
Education	Student status, credentials, mobility	Enrollment, library and exam access

The sector list comes from the recitals and articles of Regulation (EU) 2024/1183. Member states will define the operational detail, and implementing acts will land in stages.

What is actually inside the wallet at a practical level

For a product team trying to scope work, the contents matter more than the abstract categories.

Most wallets will hold the PID first, because that is the credential the state issues to bootstrap everything else. Beyond PID, expect sectoral credentials to arrive in waves: bank account ownership and KYC attestations, mobile driving licences (in ISO 18013-5 mdoc form), health insurance membership, professional qualifications, and educational diplomas. Many implementations will also support pseudonyms, which allow a user to sign in with a wallet-bound identifier that does not reveal who they are. Pseudonyms are useful where authentication is required but identification is not.

This is where selective disclosure becomes practical instead of theoretical. A bar does not need your date of birth, only proof that you are eighteen. A pharmacy does not need your full identity to confirm a valid prescription belongs to you. The wallet lets the user release only the attribute the relying party actually requires, and the credential formats the ecosystem has chosen support that directly rather than as an afterthought.

The stack underneath, without the jargon

You will see four acronyms in any technical document about EUDI Wallets. Here is what each one does, in plain language.

OpenID4VP, short for OpenID for Verifiable Presentations, is the protocol your application uses to ask a wallet for a credential and receive the response. OpenID4VCI, OpenID for Verifiable Credential Issuance, is the protocol an issuer (a bank, a university, a state authority) uses to put a credential into the wallet in the first place. SD-JWT VC is a credential format that supports selective disclosure, letting the wallet reveal only the fields a verifier asks for. ISO/IEC 18013-5 mdoc is the credential format used by mobile driving licences and by many credentials presented offline, often over Bluetooth or NFC.

The reason these matter to a compliance lead is not technical taste. It is portability. If your verification flow is built on these open standards, the same integration can accept wallets from any member state, and you avoid being locked to a single vendor's bespoke flow. The reference for all of this is the Architecture Reference Framework maintained by the Commission. The ARF is updated continuously, and the four large-scale pilots funded by the Commission (POTENTIAL, EWC, NOBID, DC4EU) have been working through the rough edges in production-shaped settings.

Misconceptions worth clearing up

A few myths come up in almost every kickoff conversation.

eIDAS 2.0 is not opt-in for member states. They are required to provide a wallet. It is also not "public sector only." The whole point of the acceptance obligations is to make wallets useful in everyday private-sector situations: banks, telcos, energy, transport, healthcare.

The wallet does not replace national eIDs overnight. Existing national schemes continue. The wallet sits alongside them and, over time, becomes the way most people present their identity online. The transition is real, but it is a transition.

And the wallet is not a rebrand of Web3 self-sovereign identity. There is no blockchain at the centre of this. The trust model is rooted in member-state authorities and qualified trust service providers, with cryptography that supports selective disclosure and unlinkability. It is closer to a regulated public-key infrastructure than to a token ledger.

What changes for you in the next two quarters

If you are a product or compliance lead at a regulated company, here are the implications that survive the marketing.

First, your onboarding flows will gain a new channel. A user who has an EUDI Wallet will expect to be able to use it where you ask for identity today. Your roadmap needs a place for that channel, even if you are not building it yet.

Second, data minimization stops being aspirational. With selective disclosure available, you will have a harder time justifying the collection of full identity documents when an attribute would do. Your data protection officer will notice.

Third, your vendor diligence questions need to change. "Does it support eIDAS 2.0" is too coarse. Better questions: which credential formats, which protocol profiles, what trust list handling, which member-state wallets have been tested end to end, and how is the trust framework refreshed as implementing acts land.

Fourth, treat 2026 and 2027 as a sequencing problem rather than a hard deadline. Wallets will become available in waves, and sector acceptance follows. The real risk if you wait is that you end up scoping an identity project under audit pressure instead of at normal planning cadence.

So, do you need to do something this quarter

Honest answer: probably yes, but the work is mostly scoping, not building. Map the workflows in your product where identity is asked. Decide which ones are obvious wallet candidates. Decide which credential formats you would need to accept. Read the Commission's regulation page, skim the ARF, and have one conversation with whoever owns identity in your stack. That is enough to make the next planning cycle a real one instead of a guess.

If you want help structuring that scoping work, request a briefing and we can walk through it with your team.