eIDAS 2.0 Is Not an IAM Solution. It Is a Shift in Who Owns the Identity

eIDAS 2.0 is not an upgrade to your identity and access management stack. It is a regulation that changes who owns user identity at a structural level. Under traditional IAM, your platform owns the identity record. Under the EU Digital Identity Wallet model, the user owns the identity and brings it to your platform as a verified credential. Your platform becomes a verifier, not an owner anymore.

When product teams first encounter eIDAS 2.0, most file it under IAM. They look at the technical surface area (digital identity, authentication, credential management) and assume this belongs to the identity team. Most of them get the integration right, update the SSO config, and believe everything is done. But this misreads what eIDAS 2.0 actually changes.

This is not an upgrade to how you manage identity within your platform. It is a structural shift in who holds identity in the first place. The product decisions that flow from each framing are completely different, and teams that miss the distinction will build the wrong thing, or underestimate how much the right thing changes.

What IAM Does

IAM (Identity and Access Management) describes the stack that handles two related but distinct problems.

The first is authentication: proving who someone is. The second is authorization: deciding what that person can do once they are authenticated.

Most IAM infrastructure, whether you run it yourself or use a managed service, creates and stores a record of each user on your platform. When someone signs up, your system creates an identity. That identity lives in your database. When they return, they prove they are who they claim to be - via password, passkey, biometric, or social login token, and your system grants them access to the data they are allowed to access.

Even federated identity models, the “Sign in with Google” or “Sign in with LinkedIn” approach, keep identity in the hands of a company. The identity provider holds the authoritative record of who that user is. Your platform delegates the authentication step to them, but the identity still lives in a corporate database operated by someone else.

The baseline assumption of every IAM model, centralized or federated, is this: identity is something a company holds about a person.

The Ownership Shift Created By eIDAS 2.0

The EU Digital Identity Wallet works differently at a foundational level.

Under eIDAS 2.0, the government issues each citizen a verified identity credential, called Person Identification Data (PID), containing their name, date of birth, nationality, and other attributes, all cryptographically signed by the issuing authority. That credential lives in the user’s EUDI Wallet, on their device and not on a server or a database that any company controls. It is on the user’s phone, under their control.

When your platform needs to verify who a user is, you do not check your own database, and you do not call Google. You send a Presentation Request to the user’s wallet via OID4VP (OpenID for Verifiable Presentations). The user reviews exactly what you are asking for, approves the specific attributes you need, and sends you a cryptographically signed response. You verify the signature against the eIDAS Trusted Lists, extract the attributes, and the interaction is complete.

Your platform never owned the identity. You received a verified claim about it. The user held it and decided what to share.

This is not an incremental improvement to IAM, but a different ownership model entirely.

The principle has a name in the identity community: self-sovereign identity. The idea is that your identity (your name, your nationality, your age, your qualifications) belongs to you as a matter of principle, not to any company that has collected data about you. eIDAS 2.0 is the EU’s regulatory expression of that principle, implemented at scale.

What Stays in Your IAM and What Moves Upstream

This distinction shapes how you should think about your product stack after integration. Your IAM system does not disappear after eIDAS 2.0 integration. The functions it handles (session management, role assignment, permission control, access tokens, audit logging) are not touched by the wallet. What changes is the upstream step: how you first establish who someone is before your IAM system takes over.

Today, that establishment step typically looks like this: form submission → email confirmation → document upload → video KYC call → manual review. Your platform gathers identity evidence and assembles a record.

After eIDAS 2.0 integration, that step looks like: Presentation Request sent → user approves in wallet → verified attributes received → signature validated. Your platform creates a user record containing the government-verified claims.

Your IAM system then picks up from exactly where it always has, managing what that verified user can do within your product.

The correct framing for an engineering team is not that eIDAS 2.0 replaces the own IAM, but that eIDAS 2.0 changes how the company establishes identity before the own IAM system runs, and it changes the quality of the identity that feeds into it.

One important technical detail worth understanding here: the EUDI Wallet presents per-relying-party pseudonyms. This means it generates a unique identifier for each service a user interacts with, rather than exposing a global user ID that could be used to track that person across services. Your platform receives an identifier that is stable across sessions for your service but is not linkable to identifiers the same user has at other platforms. This has implications for your account-linking logic, which needs to be designed before the integration begins.

Now, Let’s Focus on Your Onboarding Flow

The ownership shift affects two points in your user journey most directly.

• New user onboarding: Today, a new user arrives with nothing your system recognizes. They fill in their details, confirm their email, upload a document if you need KYC verification, and wait for review. Each step is a source of friction, abandonment, and potential error. The identity evidence is self-reported, which means it is only as reliable as the document the user uploaded and the reviewer who assessed it.

  With the wallet, a new user arrives with a government-issued credential already on their device. Your onboarding sends a Presentation Request specifying exactly which attributes you need - name, date of birth, address, or simply an age attestation if that is all your service requires. The user approves the share in their wallet. You receive cryptographically signed, government-verified attributes in seconds. There are no uploads, no manual review, no waiting period. The identity evidence is not self-reported, but government-certified.

• Periodic re-verification: Platforms with KYC obligations need to refresh identity information periodically, triggered by risk events, regulatory review cycles, or the expiry of a previous check. Today, this typically means asking users to re-submit documents or repeat a verification process they found tedious the first time.

  With wallet credentials, you request a fresh attribute presentation. The user’s wallet provides a current, re-signed credential from the issuing authority. The refresh happens without asking the user to start from scratch. This is better UX and more reliable evidence - the credential was re-signed by the government, not re-submitted by the user from a document they may have photographed months ago.

The Data Liability Difference

One of the most significant implications of the ownership shift receives less attention than it deserves: what happens to your data liability when you stop collecting and storing identity data.

When your platform owns the user identity, you store it. Names, addresses, dates of birth, document scans, biometric samples from video KYC - all of this sits in your database. That data can be breached. It attracts regulatory scrutiny. It creates GDPR obligations to protect, process lawfully, and respond to subject access requests. So, it is still a target.

When your platform receives verified claims from a wallet, your storage obligation changes structurally. You store the output of verification (a set of attributes relevant to your service), and not the full identity payload. Because selective disclosure is built into the SD-JWT VC credential format, you receive only what you asked for and what the user approved. If you need to confirm someone is over 18, you receive a boolean confirmation. You never receive or store their date of birth.

The attack surface shrinks and the GDPR scope narrows. The risk of a breach exposing user identity at scale reduces because you are not holding that identity at scale.

This matters beyond compliance: Engineering teams spend considerable resources protecting sensitive identity data. They build encryption layers, access controls, audit trails, and breach response plans for data they hold because they collected it at onboarding. But now, data you never held cannot be stolen from you.

What Changes for KYC-Obliged Platforms

For platforms with Anti-Money Laundering (AML) obligations (financial services, crypto exchanges, insurance, legal services) the ownership shift has direct compliance implications.

Person Identification Data issued through the EUDI Wallet carries Level of Assurance High, the highest assurance category under eIDAS 2.0 and equivalent to in-person government ID verification. For the identity verification component of most KYC programmes, LoA High satisfies the regulatory standard.

From July 2027, the Anti-Money Laundering Regulation (AMLR) explicitly recognises eIDAS-compliant identity methods for KYC purposes. From December 2027, platforms in regulated sectors must accept the EUDI Wallet when a customer offers it.

The shift in ownership is directly relevant to your AML programme design. You are not acquiring and storing identity documents. You are verifying a credential presented by the user and retaining a cryptographic record of the verification event. The evidence trail is different from what your compliance team may currently produce. Review with your compliance officer whether your programme documentation needs to be updated to reflect this, and whether your audit logging of verification events satisfies your regulatory record-keeping obligations.

What You Can Verify that You Couldn’t Before

The wallet ecosystem is not limited to personal identification data. As implementations mature, additional credential types will be issued by authorised bodies across EU member states: professional qualifications, educational degrees, health attestations, driving licences, and sector-specific certifications.

For product teams, this has a longer-term implication that goes beyond the immediate compliance deadline. The ownership shift means that your platform can offer services that depend on verified attributes you previously could not reliably collect at all.

A platform offering regulated financial advice could verify professional credentials in seconds at onboarding, rather than relying on self-reported qualifications. A healthcare platform could verify a patient’s EU health insurance status without asking them to upload a card. An employment platform could verify educational credentials without contacting universities.

Each of these depends on the same structural shift: the user holds verified credentials issued by authorised bodies, and your platform receives specific claims from those credentials when the user chooses to share them.

What To Do Next

If your team has been filing eIDAS 2.0 under IAM, the first step is to re-frame the conversation. This is not an upgrade to your authentication infrastructure. It is a change in the foundational ownership model for identity in EU digital services.

The practical consequence is a set of design decisions your product team needs to make now: which flows currently use identity collection and will need to change, what attributes you actually need per flow rather than per onboarding, how verified wallet credentials feed into your existing user records and access control model, and what your compliance documentation looks like when the verification event is a wallet presentation rather than a document upload.

These are product decisions more than engineering decisions. The architecture follows from getting the model right.

If your team would benefit from thinking this through with someone who has already built in this space, we are happy to help - without a brief and without a sales process. It starts with a conversation. Get in touch with Sourcelab today.