What Does the EU Digital Identity Wallet Mean for Your Platform

The EU Digital Identity Wallet is a certified application that lets EU citizens authenticate, share verified identity attributes, and sign documents across any service in the EU. Under Regulation (EU) 2024/1183 (eIDAS 2.0), every member state must make a wallet available to citizens by December 2026, and regulated platforms (in financial services, healthcare, telecoms, and others) must accept them by December 2027.

The Sourcelab team already shared insights about the EU Digital Identity Wallet from the user’s perspective: what it is, what it lets citizens do, and why it matters. That’s the right starting point if you are new to the topic.

This article is a product implementation guide for the product manager, the CTO, or the engineering lead who must take action before it is too late to comply with the regulation.

Your Platform As the Relying Party in the EUDI Ecosystem

Before getting into implementation specifics, there is one concept that reframes how you think about everything else.

In the EUDI Wallet ecosystem, every service that verifies identity credentials from a user’s wallet is called a Relying Party (RP). If your platform asks a user to prove who they are, verify their age, confirm their address, open an account, or sign a document, then your platform is a Relying Party.

This is not a marketing label, but a legal designation under eIDAS 2.0, with specific technical and administrative obligations:

• Your platform must register as a Relying Party through your member state’s national RP registry. This is governed by Commission Implementing Regulation (CIR) 2025/848. Registration requires you to declare the exact credentials you intend to request, your data processing purpose, and your privacy policy URI, so the wallet (and ultimately, the user) can see who is asking for their data before they approve anything.
• Your platform must obtain Access Certificates that accompany every credential request you send to a user’s wallet. These certificates prove your platform is a legitimate, registered service and not a phishing attempt.
• Your platform must implement OID4VP (OpenID for Verifiable Presentations) - the protocol through which users present credentials to your platform. This is not an optional integration. It is the technical foundation of wallet-to-platform communication under the Architecture Reference Framework (ARF), now at version 3.0.

RP registration alone typically takes 4-6 weeks, including the legal review of your attribute request scope and the certificate issuance process. It is the first milestone on your integration timeline, and it cannot happen in parallel with building.

What Changes In Your Onboarding Flow

This is where the shift is most immediately visible to product teams.

Today, onboarding a new user typically involves one or more of the following: uploading a scan of a national ID card, completing a video KYC session, entering a code sent to a bank account, or responding to manual review. Each step has a drop-off cost. Manual review introduces delay. And the output (a name, a date of birth, an address) is only as trustworthy as the document your team reviewed.

With the EUDI Wallet, this flow changes structurally.

Instead of asking a user to upload documents, your platform sends a Presentation Request via OID4VP. The request specifies exactly which attributes you need - name, date of birth, country of residence, or whatever your onboarding requires. The user’s wallet displays the request, the user reviews and approves precisely which data to share, and the wallet returns a Verifiable Presentation: a cryptographically signed response containing the approved attributes.

Your platform verifies the signature against the eIDAS Trusted Lists, extracts the attributes, and progresses the onboarding step.

Nothing was uploaded. No manual review was triggered. The attributes your platform received are not self-reported, but are government-issued, cryptographically bound, and auditable. For the user, the process takes seconds.

The Two Interaction Patterns You Need to Support

There are two technical flows your UI needs to handle, and which one fires depends on the user’s device context (not your design preference).

• Same-device flow: the user is on the same phone where their wallet lives. Your web app or native app generates a deep link that opens the wallet directly. The user reviews the request in the wallet, approves it, and returns to your app. No QR code is required.
• Cross-device flow: the user is on a desktop browser. Your platform displays a QR code. The user scans it with their phone’s wallet, approves the request on the phone, and your browser session updates in real time. This is the UX pattern that most closely resembles existing 2FA confirmation flows.

Both flows must be supported. Implement one and you will break onboarding for a large cohort of users on their first attempt.

What Changes for Your KYC and AML Processes

For any platform with Know Your Customer (KYC) or Anti-Money Laundering (AML) obligations (financial services, crypto, insurance, lending, legal services) the EUDI Wallet changes the shape of the compliance conversation in ways that go beyond identity verification speed.

Person Identification Data (PID) issued through the EUDI Wallet carries a Level of Assurance (LoA) of High (the highest category under eIDAS 2.0, equivalent to in-person government ID verification). For the majority of KYC identity verification requirements, LoA High satisfies the regulatory standard without additional document review steps.

From July 2027, the new Anti-Money Laundering Regulation (AMLR) enters into force and explicitly recognises eIDAS-compliant identity methods, including EUDI Wallet credentials, as valid for KYC processes. Five months later, in December 2027, regulated entities including banks, insurers, investment firms, telecoms providers, energy suppliers, and large online platforms must accept the EUDI Wallet as an identity method when a customer presents one.

This Creates Two Distinct Obligations for KYC-Obliged Platforms

• Technical readiness: you must be able to accept a wallet credential presentation as a valid, first-class input to your KYC workflow, not as a fallback or an exception path, but as a core channel your compliance and engineering teams have validated.
• Re-verification workflow changes: instead of requesting fresh document uploads for periodic KYC refresh (triggered by risk events or regulatory review cycles), you can request an updated credential presentation. The credential is re-issued by the original government issuer, not re-uploaded by the user. This is faster for customers and more reliable for compliance teams.

One requirement that is easy to miss: EUDI Wallet credentials are revocable. If a user’s identity document is invalidated after the credential was issued, the wallet issuer updates a status list - a real-time revocation registry. Your verifier must check this status list on every presentation. Accepting a credential without checking status is accepting a potentially invalid identity claim. This is a non-optional integration component we must emphasize on.

The Tech Stack: What You Need to Implement

Here is the complete scope of a Relying Party integration. Each component is required for a conformant implementation.

OID4VP: OpenID for Verifiable Presentations

This is the core presentation protocol. Your platform implements an OID4VP verifier endpoint that sends Presentation Requests and receives Verifiable Presentations. It is required with the HAIP profile (High Assurance Interoperability Profile) and handles same-device and cross-device flows. This is the largest single implementation workload: typically 8-12 weeks for a clean integration with test wallet coverage.

OID4VCI: OpenID for Verifiable Credential Issuance

If your platform also issues credentials to wallets (not just verifies them), you need OID4VCI. For most private-sector Relying Parties, this is optional in the initial integration scope, but is worth understanding for platforms that plan to issue professional credentials, loyalty attributes, or service-specific attestations.

SD-JWT VC: Selective Disclosure JWT for Verifiable Credentials

This is the credential format used for PID and most EUDI Wallet attribute types. SD-JWT allows the wallet to disclose specific fields from a credential without revealing the rest. Your parsing logic needs to handle SD-JWT VC natively. Open-source libraries (sd-jwt-js, openid4vp-rs) now support this, meaning they are mature enough for production use.

ISO/IEC 18013-5 and 18013-7: The .mdoc Format

This is the credential format for document-type credentials - mobile driving licences and national IDs. For remote online verification (which is your scenario), the relevant spec is ISO/IEC 18013-7, the remote verification extension. This is a second credential format alongside SD-JWT VC. Many platforms scope this for a second integration phase. If your onboarding relies on mDL verification, it cannot be deferred.

Wallet Attestation Verification

When a wallet presents credentials, it also sends a wallet attestation - proof that the wallet itself is a certified, conformant EUDI implementation. Your verifier must validate this attestation and handle edge cases: what happens when a wallet’s certification has expired? Or what if the wallet instance has been revoked because the user reported device theft?

Status List Integration

Real-time revocation checking against the issuer’s credential status list. Required on every presentation. This is a two- to four-week integration but must be scoped from the beginning, since it affects your verification latency and error handling logic.

Consent and Audit Logging

Every credential presentation must be logged with: the credential hash, the presentation submission metadata, the relying party’s request, and a snapshot of the Trusted List used for validation at that timestamp. Both GDPR and eIDAS 2.0 require this. Your existing audit log infrastructure will need to be extended.

User Account Linking Logic

When a new user presents a wallet credential during onboarding, you need to resolve three scenarios: is this a new user creating an account? Is this a returning user you already know, re-authenticating? Is this an existing user with a new device and a new wallet instance? These decisions live in your data model, and not in the OID4VP protocol. They need to be designed before the actual integration begins.

Selective Disclosure: The Data Model Implication You Need to Plan For

One of the most consequential product implications of the EUDI Wallet is not immediately obvious from reading the regulation, but selective disclosure changes what you are allowed to ask for.

The SD-JWT VC format, combined with eIDAS 2.0’s data minimisation requirements, means you cannot request “a copy of the user’s ID.” You can request specific, named attributes: family_name, given_name, birth_date, age_over_18, address, nationality. Each attribute you request must be tied to a declared processing purpose.

For product teams, this changes the data model fundamentally. You are no longer receiving documents and extracting data from them downstream. You are receiving specific, verified claims and binding them directly to a user record.

In practice, if your onboarding only requires age verification, you do not need the user’s date of birth. You request age_over_18 - a single boolean claim that confirms the user meets the threshold. The user’s actual DOB never leaves the wallet. Your platform receives the confirmation it needs. Your stored data liability shrinks accordingly.

This is better UX, higher compliance, and smaller data risk. But it requires product teams to explicitly design what they request for each flow, rather than defaulting to a document catch-all and figuring out what to extract later.

Timeline: What to Build and When

Wallets are available to citizens from December 2026. Regulated platforms must accept them by December 2027. A production-ready Relying Party integration typically takes 16-22 weeks. That means the architecture decisions and registration process need to begin now.

Now - Q4 2026: Foundation and Registration

Initiate Relying Party registration with your national competent authority. This involves legal review of your intended attribute request scope and formal registration of your service. Set up a development sandbox connected to one of the existing EUDI pilot wallet implementations (the large-scale pilots under DC4EU, EWC, NOBID, and POTENTIAL all have test wallet access). Map your existing onboarding and KYC flows: identify exactly where a wallet presentation will replace or augment a current step. Make the data model decision on account linking before a line of code is written.

Q1 2027: Core Integration

Implement the OID4VP verifier endpoint with HAIP profile. Integrate SD-JWT VC parsing. Build both same-device and cross-device presentation flows. Build real-time status list checking. Begin internal testing against test wallets with your own engineers as test users.

Q2 2027: Pilot and Attribute Logic

Soft launch with an opt-in cohort or internal users. Build the attribute extraction and downstream account-linking logic. Update consent screens and audit logging. Resolve the edge cases that only appear with real wallet holders: what happens when a user declines to share an attribute you’ve marked as required? What happens when their credential expires mid-session?

Q3 2027: Production Readiness

Full end-to-end testing under realistic load. ISO/IEC 18013-7 integration for mdoc flows if in scope. Formal compliance review. Go-live before the December deadline, with margin for remediation.

December 2027 and Beyond: Mandatory Acceptance Live

Wallet acceptance is live. Monitor ARF updates for new credential types (professional qualifications, educational credentials, health attestations) and expand your attribute scope as they roll out across member states.

A Quick Self-Assessment to Validate Platform Readiness

• Is my platform in a mandatory-acceptance sector (financial services, telecoms, healthcare, energy, or large online platforms)?
• Have I initiated Relying Party registration with my member state?
• Have I assessed which onboarding and authentication flows will need a wallet presentation path?
• Does my platform support both same-device and cross-device OID4VP presentation flows?
• Can my backend parse SD-JWT VC credential payloads?
• Have I integrated real-time credential status list checking?
• Have I designed my attribute request scope per flow rather than defaulting to a full ID request?
• Does my consent and audit logging capture the full presentation audit trail?
• Have I mapped the account-linking logic for new vs. returning users presenting wallet credentials?

What to Do Next

If your platform operates in a regulated sector in the EU, EUDI Wallet integration is a product workstream and definitely not something to delegate until 2027. The mandatory deadline is December 2027. And a full integration takes 16-22 weeks which makes it less than a year to become compliant.

The good news: you don’t need to rebuild your entire identity stack. The most valuable thing you can do right now is make the right product decisions before implementation begins: what attributes you actually need per flow, how wallet credentials map to your existing user records, and what your onboarding UX looks like when a wallet presentation is in the loop.

These are questions Sourcelab has worked through in production. If you want to think them through with a team that is already built in this space, let’s talk.

Contact us today and learn how we can help you build and validate a compliant workflow that owns all the principles of Sourcelab’s Digital Trust philosophy.

---

Frequently asked questions