eIDAS 2.0 & the EUDI Wallet: A Practical Guide for Enterprise IAM (2025–2027)

October 9, 2025 by Trenton Thurber

What eIDAS 2.0 changes, and why the EUDI Wallet matters

From eIDAS to eIDAS 2.0: what’s new in Regulation (EU) 2024/1183

eIDAS 2.0 upgrades Europe’s digital identity framework with a standardized, interoperable wallet that users can carry on their phone to prove identity, present attributes, and sign transactions across the EU. The regulation entered into force on 20 May 2024 and introduces obligations for the public sector and parts of the private sector to accept EUDI Wallet logins upon a user’s request where strong authentication is already required. It also extends trust services (e.g., qualified electronic attestations of attributes) and creates explicit pathways for cross-border wallet acceptance, including by very large online platforms (VLOPs).

Fact to bookmark: Within 36 months of the Wallet implementing acts, regulated private services that already require strong user authentication and VLOPs must accept the EUDI Wallet at the user’s request.

Wallet fundamentals: credentials, attestations, and selective disclosure

The EUDI Wallet is a user-controlled container for verifiable credentials (identity data, licenses, professional qualifications, payment data). It can carry qualified electronic attestations of attributes (QEAA) issued by qualified trust service providers, and it supports selective disclosure, so users can share only what’s needed (e.g., “over 18” without a birthdate). That design aligns with GDPR principles (data minimization, purpose limitation) and reduces risk for relying parties by eliminating document uploads and manual checks.

Interesting: Selective disclosure is explicitly called out as a basic design feature of the Wallet, expect growing support for SD-JWT and ZKP-capable formats in enterprise flows.

Who needs to care: public sector, regulated industries, VLOPs/gatekeepers

Public services must accept the Wallet for online identification. In the private sector, any service (except micro/small enterprises) that already uses strong user authentication, including banking/financial services under PSD2 SCA, telecoms, healthcare, education, energy, transport, and more, will be in scope. VLOPs (per the DSA) must accept Wallet authentication upon users’ voluntary request when they require sign-in.

Takeaway: If your organization already enforces strong customer authentication (SCA) or strong workforce MFA, you’ll likely be a “wallet-relying party” soon.

Key dates, obligations, and scope for enterprises

Timeline: implementing acts and national wallet availability (2024–2026)

Core implementing acts for the Wallet were adopted, with further sets following in 2025. Member States are required to make at least one national Wallet available within 24 months of the implementing acts’ entry into force, targeting late 2026..

Planner’s note: Treat 2025–2026 as your integration & pilot window (with early citizen/business wallets rolling out), so you’re not compressing IAM changes into 2027.

Mandatory acceptance scenarios in 2027 and beyond

The acceptance clock runs 36 months from the entry into force of the relevant implementing acts. That puts mandatory acceptance for in-scope private services and VLOPs into late 2027, depending on the specific acts referenced. Align this with your compliance calendar and procurement cycles.

Anchor date: For many enterprises, a December 2027 target is a prudent planning assumption while tracking any additional implementing acts that refine scope and timing.

Defining a “wallet-relying party” in your architecture

In EUDI terms, a relying party is any organization that requests and verifies Wallet-presented credentials to deliver a service (public or private). In practice, this maps to your customer portals, workforce SSO, and high-risk transaction flows that already demand strong auth.

Design tip: Treat Wallet acceptance as a new front-door alongside your IdP, not a separate island, so you can route users via OIDC/SAML while honoring consent and data minimization.

Security alignment, phishing resistance and NIST AAL mapping

Mapping workforce and customer journeys to AAL2/AAL3

To operationalize eIDAS with Zero Trust, classify journeys using NIST SP 800-63. AAL2 requires phishing-resistant options and multi-factor proof; AAL3 demands a non-exportable, hardware-backed key and verifier-impersonation (phishing) resistance. Use AAL3 for privileged admin tasks and high-risk approvals, and AAL2 for most customer sign-ins and low-risk workforce sessions.

Reality check: When Wallet assurance or presented attributes elevate risk, apply step-up to AAL3 for the final authorization.

When AAL3 is warranted (privileged actions, high-risk flows)

Use AAL3 when authorizing production changes, data exports, signing/sealing, or finance/HR changes, particularly where a qualified signature or QEAA is involved and the business impact of compromise is high.

Passwordless by design: passkeys, WWPass, and origin binding

For day-to-day sign-in, passkeys (WebAuthn/FIDO2) deliver phishing resistance via origin binding and cryptographic challenges, no shared secrets to phish or replay. Combine device-bound or synced passkeys with Wallet-based attributes to meet AAL targets while keeping UX fast.

Practicality: Keep passwords out of primary flows. Reserve break-glass and recovery channels that aren’t phishable (no SMS/OTP if you can avoid it).

Integrating EUDI Wallets with modern SSO/IdPs

OIDC/SAML patterns for wallet credential presentation

The EUDI Architecture & Reference Framework (ARF) favors OpenID for Verifiable Presentations (OpenID4VP) and compatible issuance protocols. The pattern for enterprises: your RP/IdP requests just-enough attributes from the Wallet, receives a verifiable presentation, and exchanges it for an OIDC/SAML session with appropriate assurance/claims. OpenID4VP spec and EUDI ARF presentation interface.

Engineer’s note: Keep attribute minimization central, map claims to least-privilege roles and persist only what’s necessary for audit.

Bridging wallets and passkeys: cross-device and QR approvals

Many “scan to sign-in” experiences use a QR handshake to bridge desktop and phone. You can pair Wallet presentation with a passkey assertion on the phone, enabling phishing-resistant cross-device login. See WWPass’ guide to QR Code Authentication for implementation patterns (per-session QR, short TTL, replay protection).

Heads-up: Quishing (QR phishing) is rising, always bind QR flows to origin and session, and rotate on view.

Device signals, step-up, and continuous risk checks

Augment Wallet + passkeys with device posture, network risk, and behavioral signals. Use conditional access to step from AAL2→AAL3 when risk spikes or when Wallet claims require stronger binding.

Architecture patterns with WWPass

A practical way to prepare your stack: implement phishing-resistant SSO now and attach Wallet presentation as it rolls out nationally.
, Explore Passwordless SSO for Web & Mobile Apps for rollout guidance.
, Add strong factors with WWPass MFA and manage authenticators with the WWPass Key App.

QR-mediated approvals that resist quishing/replay

WWPass’ QR flows are designed with per-session, per-browser nonces, short TTLs, and origin binding, measures that blunt replay and QR-phishing routes while keeping UX smooth. See QR Code Authentication: How It Works for best practices; pair with Wallet attributes to satisfy regulatory acceptance and PSD2 SCA.

Directed identities and minimizing shared secrets

Combine Wallet directed identifiers (per-RP) with origin-bound passkeys to minimize correlation, prevent credential reuse, and maintain Zero Trust posture. For regulated signing, layer qualified signatures or QEAA where required by sector rules.

Selective disclosure and least-data principles

The EUDI Wallet operationalizes data minimization by letting users present only the attributes required for a transaction (for example, proving “over 18” without revealing a birthdate). In practical enterprise IAM, that means shifting from document uploads and broad profile syncs to verifiable credentials with selective disclosure, reducing stored PII, breach blast radius, and consent fatigue. The eIDAS 2.0 Architecture & Reference Framework (ARF) calls out SD-JWT and mDL (ISO 18013-5) patterns to deliver this at scale, so your login and step-up policies can request “just enough” attributes for each use case (know-your-customer, professional role, or residency). This approach dovetails with GDPR Article 5 and the privacy-by-design goals baked into wallet policy.

Reference points:
Selective disclosure is a wallet must/should in the ARF for PID and (Q)EAA attestations.
Data minimization (“adequate, relevant and limited”) is the explicit GDPR standard your IAM must demonstrate.

From a stack perspective, treat the Wallet like a high-assurance attribute source, not a profile warehouse. Keep your IdP/SSO as the policy brain, but exchange only minimum claims needed per RP/app, and avoid long-lived replication of wallet-derived data.

Under GDPR, valid consent is freely given, specific, informed, and unambiguous, and revocable as easily as it was given. In wallet UX, the prompt must name the relying party, list the requested attributes, and explain the purpose (including retention). Avoid pre-ticked boxes, bundling multiple purposes, or burying “withdraw” controls. Wallets add something powerful here: a user-facing transaction log so people can see who requested what, when, and what was shared, helpful for trust and audit.

Quick wins:
Use plain-language requests (“Share ‘over 18’ to access age-restricted content”).
Make withdraw consent one tap from the confirmation screen and mirror it in your account center.
Surface who/what/when in the user’s wallet history and your RP dashboard.

Accessibility and language support for wallet flows

Wallet acceptance must be accessible by default. Follow WCAG 2.2 (notably 3.3.8 Accessible Authentication) and Europe’s EN 301 549 standard across web and mobile. In practice: no cognitive function tests to log in, visible focus states, clear error help, sufficient touch targets, proper labels, and language localization where you operate. Build voiceover-friendly consent screens and keyboard-navigable QR approvals in desktop flows. The ARF and the Web Accessibility Directive tie these expectations together for public sector, and private enterprises should align to reduce friction and legal risk.

Checklist items:
Accessible authentication: no CAPTCHAs/memory tests to complete sign-in.
EN 301 549 conformance for apps, kiosks, and web, not just sites.

Implementation blueprint (90-day plan)

Readiness assessment: systems, IdP, and RPs in scope

Start by mapping your wallet-relying party surface: customer portals, partner channels, and workforce apps already enforcing strong auth (or PSD2 SCA for payments). Inventory your IdP/SSO capabilities, OIDC/SAML brokering, attribute governance, device posture, and step-up. Confirm support for OpenID for Verifiable Presentations (OID4VP) at the edge (gateway/IdP plugin or verifier service) and identify low-risk flows where wallet acceptance can be trialed. Validate logging paths (SIEM, consent records, transaction IDs) to capture who/what/when/where for audits.

Priorities to baseline:
IdP can request minimal claims and map them to roles; verifier implements OID4VP tests.
Privacy impact assessment updated for verifiable credentials processing.

If you’re modernizing in parallel, it’s efficient to roll in passwordless now so your UX is already phishing-resistant. WWPass provides deploy-ready pieces, Passwordless SSO for Web & Mobile Apps, WWPass Multi-factor Authentication, and the WWPass Key App, that pair well with wallet acceptance architecture.

Pilot wallet acceptance on a low-risk journey

Choose a low-impact, high-volume journey to maximize feedback (e.g., account proofing for discounts or access to non-sensitive records). Present a scan-to-proceed flow: desktop QR to phone wallet → selective disclosure → IdP session with tags noting the assurance (AAL) and wallet provenance. Harden against quishing: per-session QR with short TTL, origin binding, rotation on view, and replay-proof handshakes. WWPass patterns for QR Login illustrate the right controls and are easy to adapt.

Pilot guardrails:
Gate the pilot user cohort (feature flag), measure abandonment, and capture reason codes on decline.
Include multilingual content and assistive-tech testing for consent prompts (WCAG/EN 301 549).

Metrics, audit trails, and rollout governance

Define success criteria early: wallet acceptance rate, selective-disclosure acceptance vs. decline, average attributes shared per transaction, help-desk contacts per 1,000 logins, and time-to-complete vs. legacy MFA. On the governance side, establish a joint product–security–privacy working group to oversee scope creep and change control. For auditability, capture: RP identifier, requested attributes, shared attributes, RP policy version, time/date, device footprint, and assurance labels (AAL2/AAL3). This aligns with GDPR accountability, PSD2 SCA evidence needs, and NIS2 incident review expectations.

Evidence that sticks:
Who/what/when/where records for each wallet transaction; user-visible history in the wallet.
Verifier conformance artifacts (OID4VP test results) pinned to the change ticket.

Compliance mapping & audits

Wallets reduce PII accumulation by enabling least-data assertions, which helps demonstrate GDPR principles. For PSD2 SCA journeys, a wallet-mediated login can combine possession (bound device/wallet) and inherence/knowledge (biometric/PIN), while your IdP enforces dynamic linking and risk controls required by the EBA. Under NIS2, stronger authentication and provable logs improve your risk-management measures and post-incident analysis.

Anchor facts:
PSD2 SCA requires strong auth in online banking and high-risk remote actions (Article 97).
NIS2 emphasizes security measures and reporting, with tighter expectations across sectors.

If you operate payments, map wallet outcomes into your SCA exemptions logic; for critical services, fold wallet acceptance into your NIS2 policy set and DPIA updates.

Logging and evidence: who/what/when/where for regulators

Implement a standard event taxonomy across IdP, verifier, and RPs. For each wallet interaction, log requesting RP, data requested, data actually shared, timestamp, assurance, user consent status, and transaction IDs to enable reconciliation. Publish the relevant details to the user (wallet history) and keep tamper-evident server-side logs for auditors. eIDAS 2.0 discussions and DPA guidance underscore both user-visible traceability and controller-side auditability.

Make it measurable:
Set SLAs for providing event evidence to auditors (hours/days), and rehearse trace-back drills quarterly.

Vendor & RFP checklists for wallet-ready IAM

When procuring, require: OID4VP verifier support (with published conformance results), OpenID/OAuth/SAML brokering, selective-disclosure aware policy mapping, WCAG/EN 301 549 conformance claims, and NIST AAL reporting in tokens. Operational asks: short-TTL QR, origin binding, replay resistance, per-RP directed identifiers, and SIEM-ready logs. Prefer vendors with a 90-day rollout plan and proven passwordless capability so the user experience is consistent across wallet and non-wallet flows.

To accelerate time-to-value, you can leverage WWPass components already built for phishing-resistant flows, WWPass MFA and Passwordless SSO, and layer in wallet verification when your national wallet becomes widely available, with WWPass Key App managing authenticators and QR login best practices guiding the cross-device UX.

FAQs

Do we need to accept EUDI Wallets by 2026 or 2027?

Wallet regulations and implementing acts entered into force after 2024, and Member States must provide at least one wallet within 24 months of the implementing acts. Enterprise acceptance obligations (for services already requiring strong authentication and for VLOPs) kick in within 36 months after the relevant implementing acts take effect, placing most private-sector acceptance in 2027 (exact month depends on the act referenced). Track your national authority’s timeline; plan pilots in 2025–2026 and broad rollout by late 2026/2027.

Key date to plan around: Wallet availability by end-2026, acceptance obligations by 2027 for many in-scope services.

How do wallets differ from passkeys and smart cards?

A wallet stores and presents verifiable credentials (identity and attributes) and can also perform authentication; passkeys (WebAuthn/FIDO2) are phishing-resistant authenticators that prove you control a key bound to an origin (RPID). Smart cards (PIV/CAC) are hardware credentials with certificates for strong auth and signing, often requiring readers or derived credentials on mobile. In enterprise IAM, pair the wallet (to prove who you are/what you’re entitled to) with passkeys (to prove you are present here and now), and use smart cards where regulated signatures or pre-existing PKI are mandated.

Practical mix: Wallet for attributes, passkeys for everyday login, smart cards for qualified signatures/regulated contexts.

What’s the minimum to claim “phishing-resistant” under NIST?

Per NIST SP 800-63B/-63-4, phishing resistance hinges on cryptographic authenticators that prevent verifier impersonation. AAL2 can be achieved with strong MFA (cryptographic) and is the baseline most enterprises should hit; AAL3 requires a hardware-based authenticator with a non-exportable private key and verifier-impersonation resistance (and stricter session/reauthentication timeouts). For high-risk or privileged flows, aim AAL3; for standard workforce and consumer sign-ins, AAL2 + phishing resistance is recommended.

Rule of thumb: Use origin-bound passkeys (and similar passwordless methods) as your default; escalate to hardware-backed AAL3 for admin and high-impact actions.