The EU Digital Identity Wallet is not a research project. Regulation 2024/1183 (the eIDAS 2.0 revision) obliges every Member State to offer at least one compliant wallet to every citizen and resident by the end of 2026, and the large-scale pilots running throughout 2024-2025 have moved wallets from specification to production. The operational question for regulated entities is no longer whether the wallet will exist, but how their existing identity, KYC, and consent flows need to change to accept wallet-based credentials — and where the line sits between a legitimate business need and the surveillance pattern that eIDAS 2.0 was specifically designed to prevent.
This post covers what eIDAS 2.0 imposes on relying parties, the privacy architecture that constrains how wallet data can be processed, the interaction with GDPR lawful bases, and the concrete integration decisions a regulated entity should be making in 2026.
What the Regulation Actually Obliges
Regulation 2024/1183 amends Regulation 910/2014 (the original eIDAS) and introduces the European Digital Identity Wallet as a new category of electronic identification means. The obligations fall into three groups.
Member State obligations. Each Member State must make a wallet available to all citizens and residents who request one, free of charge, by the deadline set in the implementing acts — in practice, late 2026. The wallet must be interoperable across borders, so a wallet issued by one Member State must be usable to authenticate and share credentials in any other Member State.
Relying party obligations. Relying parties — any public or private entity that accepts wallet-based authentication or attestations — must register their intended use, limit the attributes they request to what is strictly necessary, and respect the user's consent and minimisation preferences. Relying parties are prohibited from requesting attributes beyond those registered, and from combining attributes across transactions in ways that would build an unauthorised profile of the user.
Mandatory acceptance in specific sectors. Article 5f obliges specific sectors — including banking, financial services, healthcare, electronic communications, and a range of public services — to accept the wallet as a means of identification and authentication where they currently accept other strong electronic identification. This is the clause that converts the wallet from an option into a regulatory minimum for large parts of the regulated economy.
The Privacy Architecture
The design of the wallet is built around one principle: the user controls disclosure, and the issuer of a credential does not learn when or to whom the user presents it. This is implemented through three mechanisms that regulated entities need to understand before designing their integration.
Selective disclosure. A wallet-held credential — such as a driver's licence or a professional qualification attestation — can be presented without disclosing every attribute it contains. If the relying party needs proof that the holder is over 18, the wallet can produce a cryptographic proof of the "over 18" predicate without revealing the date of birth. Any relying party design that requests the full credential when only a predicate is needed will fail the necessity test under the regulation and under GDPR Article 5(1)(c).
Unlinkability. The wallet's cryptographic architecture prevents relying parties from colluding to link multiple presentations from the same user. Each presentation uses fresh pseudonymous identifiers where persistent identification is not required. Systems that depend on a stable cross-session user identifier — many fraud detection tools do — need to be redesigned to obtain that identifier from a separate, consented mechanism rather than by attempting to link wallet presentations.
Issuer blinding. The credential issuer — for example, the Member State authority that issued an identity attestation — must not be able to observe when and where the credential is used. This affects the architectural options for credential revocation checking. Simple online revocation lookups reveal usage to the issuer. The regulation and its implementing architecture require privacy-preserving revocation mechanisms such as cryptographic accumulators or status list indexes, which relying parties will need to integrate.
The Interaction With GDPR
eIDAS 2.0 does not replace GDPR — it sits alongside it. A relying party processing wallet-derived personal data is still a controller under GDPR and still needs to satisfy Articles 5, 6, and 13 independently.
The two most common friction points in 2026 integrations:
Lawful basis. The wallet's consent mechanism satisfies the user-facing disclosure step of the transaction, but the relying party must still identify an appropriate GDPR lawful basis for the downstream processing. For most KYC and authentication flows, the lawful basis is legal obligation (Article 6(1)(c)) — an AML directive, a professional licensing regulation, a DORA onboarding requirement. For flows that go beyond legal obligation — for example, onward profiling, cross-product marketing, or analytics — a separate lawful basis and a separate consent are required. The wallet's consent for the immediate transaction does not authorise these downstream uses.
Data minimisation with an audit trail. The entity needs to retain proof of the KYC check for supervisory purposes, but the supervisor's evidence needs differ from the entity's operational needs. The correct pattern in most cases is to retain the cryptographic proof of the attestation (verifiable by the supervisor) rather than the full set of attributes that were presented. This is a substantial change from the traditional KYC pattern of capturing and storing full identity document copies. Entities that do not redesign their evidence retention will accumulate more personal data than GDPR permits and will find themselves exposed on future supervisory reviews.
The Integration Decision: Wallet-Native or Wallet-Wrapped?
Most regulated entities face a build decision in 2026 that will shape their identity architecture for the next decade. There are two dominant patterns.
Wallet-wrapped — the entity keeps its existing identity verification flow (typically a document scan, liveness check, and database cross-reference) and adds the wallet as an additional input channel. The wallet presentation is converted into the entity's existing internal identity object, and the downstream flow is unchanged. This pattern is cheap to build, but it preserves the existing minimisation and retention weaknesses. It also undermines the point of the wallet — the user goes through a wallet flow, but the entity still ends up with more data than was necessary.
Wallet-native — the entity redesigns its verification and KYC flows to take wallet attestations as first-class evidence. The evidence retained is the cryptographic proof, not the underlying attributes. Downstream systems are updated to query the minimal attribute set they actually need, rather than the full customer record they used to receive. This is a larger programme — typically 12-18 months for a tier-1 bank — but it produces an architecture that aligns with the regulation's intent and substantially reduces the entity's GDPR surface.
For most entities, the realistic answer is a staged migration: wallet-wrapped in 2026 to meet the acceptance deadline, with a committed migration to wallet-native architecture by 2028-2029. The risk is that wallet-wrapped becomes permanent, at which point the compliance and liability profile is worse than if the wallet had never been integrated.
The Sectoral Specifics to Watch
Four sector-specific issues will dominate 2026 implementation conversations.
Banking and AML. The 6th AML Directive and the AML Regulation interact with the wallet in non-obvious ways. Wallet attestations can satisfy most of the customer due diligence requirements, but enhanced due diligence for politically exposed persons or high-risk jurisdictions still requires additional sources. Banks need to decide where the wallet satisfies the check entirely and where it is one input among several, and document that decision in their AML policies.
Healthcare. The European Health Data Space Regulation and eIDAS 2.0 interact around patient identification and consent for cross-border health data exchange. The wallet is the anchor identity for EHDS primary and secondary use flows, but the consent mechanisms are distinct and need to be integrated carefully to avoid the user being asked for overlapping consents that create confusion and legal risk.
Financial services under DORA. DORA's ICT third-party provider oversight applies to the providers of wallet-integration technology. Entities relying on a third-party wallet verification service need to include that service in their register of information, their concentration analysis, and their business continuity plans.
Telecoms and electronic communications. Mandatory acceptance extends to telecoms for SIM issuance and account authentication. The privacy implications here are significant — a wallet-based SIM issuance can be designed to disclose far less personal data than the current physical document flow, but only if the operator redesigns the backend rather than forcing the wallet flow into the existing data model.
What to Do in the Next Six Months
A pragmatic six-month programme for a regulated entity that has not yet started wallet integration:
- Identify every current identity verification and authentication flow. Map the attributes collected, the lawful basis, and the retention. This is the baseline for the redesign.
- Register as a relying party in the target Member States where you operate, through the national authority or the Commission's registration service. Registration is a prerequisite for receiving attributes from any wallet.
- Decide the wrapped vs. native strategy per flow. Not every flow needs the same architecture. High-volume, low-risk flows may be wallet-wrapped indefinitely. KYC onboarding for regulated products should be wallet-native.
- Update privacy notices and DPIAs. Any change to the identity verification flow is a material change under GDPR Article 35 and typically triggers a DPIA update.
- Engage the internal fraud and AML teams early. The unlinkability property of the wallet breaks specific fraud detection patterns. The replacement needs to be designed in parallel with the integration, not discovered during user acceptance testing.
- Test against at least two Member State wallets. Interoperability is a regulatory requirement but operational reality across wallet issuers varies. Testing against a single wallet gives a false sense of readiness.
The entities that treat the wallet as a compliance checkbox will meet the acceptance deadline and carry most of their current identity-data liability forward. The entities that treat it as a privacy-architecture upgrade will spend more in 2026 and substantially less for the rest of the decade. The regulation points toward the second path; enforcement in 2027 and beyond will almost certainly follow.