How should organisations prepare identity and access processes for the eIDAS 2 digital wallet model?

Organisations should treat eIDAS 2 as a shift toward user-directed identity sharing, not just a new login option. That means aligning onboarding, authentication, and consent flows to accept wallet-based identification, validate attributes only when needed, and minimise unnecessary data collection. Teams should also review sector-specific acceptance requirements so public and private services can use the same digital identity consistently.

Why eIDAS 2 Changes Identity and Access Design

eIDAS 2 changes the access model from organisation-issued identity proofing toward wallet-mediated presentation of identity attributes. That matters because onboarding, authentication, consent, and attribute validation no longer sit entirely inside one service boundary. Organisations need to decide what they will accept from a wallet, how much they need to verify, and when to rely on the wallet holder’s consent versus their own policy checks. The legal framework itself is set out in the eIDAS 2.0 — EU Digital Identity Framework.

The practical shift is that access teams must support selective disclosure and attribute-based decisions without forcing unnecessary data collection. If a service only needs age, residency, or professional status, the process should request only that attribute and avoid turning the wallet into a broad identity dump. That reduces friction, but it also increases the need for clear acceptance rules, because different services may trust different wallets, issuers, or assurance levels.

In practice, the hardest failures happen when the organisation keeps its old login assumptions and simply adds a wallet button on top.

How It Works in Practice

Preparing for the wallet model means redesigning the identity journey around three questions: what must be known, what may be presented, and what can be deferred. Organisations should map each service to the minimum identity attributes required, then define which parts of the flow are wallet-driven and which still depend on local account creation, step-up authentication, or internal approval.

A workable implementation usually includes:

Wallet acceptance rules that specify which wallets, issuers, and assurance levels are allowed for each journey.
Attribute-level intake logic, so the service can consume only the claims it needs.
Consent handling that records what the user agreed to share and for what purpose.
Fallback paths for users or sectors that are not yet wallet-ready.
Auditability for identity proofing, attribute retrieval, and downstream account provisioning.

Services also need to distinguish between identification and authorization. A wallet may prove who the user is or provide an attribute, but the application still has to decide what that user can do inside the service. That means existing access models, including RBAC and privileged approval flows, may need to be updated so they can consume externally asserted identity evidence instead of only locally issued accounts.

For public-sector and regulated private-sector services, the main operational task is not just technical integration. It is harmonising policy, consent, and assurance so the same identity can be used consistently across journeys without expanding data collection or weakening control. The OWASP Non-Human Identity Top 10 is useful here as a control-pattern reference when wallet-mediated access also drives machine-side provisioning or delegated workflow access. These controls tend to break down when teams treat wallet acceptance as a front-end feature and leave downstream account lifecycle, revocation, and assurance mapping unresolved.

Common Variations and Edge Cases

Tighter wallet acceptance often increases integration and governance overhead, so organisations have to balance interoperability against control. Some services will be able to rely on a single wallet presentation, while others will need multiple acceptable wallets or additional verification because sector rules or assurance expectations differ.

One common edge case is cross-border or cross-sector use. A wallet may be technically valid but still fail local policy because the service needs a specific attribute source, a specific level of assurance, or a jurisdictional acceptance rule. Another is progressive rollout, where a service accepts wallet-based identity for some journeys but retains legacy login for others. That hybrid model can work, but only if the organisation is explicit about which path is authoritative for account creation, recovery, and revocation.

Best practice is evolving toward minimising repeated data capture and letting the wallet carry only the attributes needed for a given transaction. The design risk is over-trusting the presentation layer and under-designing the lifecycle layer. If issuance, consent, expiry, and revocation are not linked to the service’s own access rules, the organisation may create a cleaner user experience while still carrying fragmented identity governance behind the scenes.

Risk and Threat Considerations

eIDAS 2 introduces exposure around assurance mismatch, consent misuse, and fragmented lifecycle control. The main risk is that organisations accept wallet-presented identity as if it were a complete substitute for internal identity governance, even though the service still needs its own rules for trust, access, retention, and revocation.

Failure mechanism: Weak acceptance logic can allow an attribute to be used outside its intended context, or allow a stale account to remain active after the underlying wallet credential or consent state has changed. If the service does not tie attribute use to purpose and expiry, it can over-collect data, over-trust an assertion, or fail to revoke access when the user’s wallet state changes.

Impact: The result can be unauthorized access, excessive data exposure, inconsistent sector acceptance, and poor auditability of who was trusted for what. In regulated environments, that also creates governance risk because the organisation may be unable to prove that identity, consent, and access decisions were aligned.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the technical controls, while EU AI Act define the regulatory obligations.

Framework	Control / Reference	Relevance
EU AI Act	eIDAS 2.0 Digital Identity Framework	Defines the wallet-based digital identity model and trust requirements
Recommendation — Align onboarding and acceptance rules to wallet-based identity and attribute presentation.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Maps the need to govern wallet-driven authentication and access decisions
Recommendation — Update identity and access processes to validate wallet assertions and enforce least-privilege access.
NIST SP 800-63	SP 800-63-3 — Digital Identity Guidelines	Supports assurance, federation and identity-proofing decisions for wallet trust
Recommendation — Use assurance and proofing guidance to set trust levels for wallet acceptance.
CIS Controls v8	5.1 — Establish and Maintain an Inventory of Accounts	Wallet adoption still requires account lifecycle control and auditability
Recommendation — Maintain an inventory of wallet-linked accounts and revoke stale access promptly.

Practitioner Guidance

What to prioritise: Start with the services that depend on identity proofing, regulated attributes, or cross-sector acceptance. Those are the journeys where wallet support changes the access model most, and where a weak design will cause the most rework later.

Decision rule: If a service only needs a bounded attribute set, design for attribute intake and verification first; if it needs full account continuity, add a local identity and lifecycle layer rather than assuming the wallet alone will cover recovery, revocation, or privileged access decisions.

What to verify: Confirm that consent, attribute scope, assurance level, and revocation handling are all explicit in the process design. If any of those are implicit, the organisation will usually discover the gap only after onboarding begins across multiple channels.

Practitioner takeaway: The safest eIDAS 2 preparation is to treat the wallet as a trust input, not a complete identity system, and to make every downstream access decision explainable, minimal, and reversible.