How can enterprises scale EUDI Wallet acceptance across multiple business units?

Scaling EUDI Wallet acceptance across multiple business units means connecting each unit’s customer-facing processes to a single, compliant integration that accepts every certified European wallet, handles trust management, and reuses verified identity data across interactions. The key challenge is not the technology itself but the coordination: governance, registration scope, and process alignment across teams that often work independently. This article walks through the practical questions enterprises face when rolling out EUDI Wallet acceptance at scale.

What does scaling EUDI Wallet acceptance actually involve for large organizations?

Scaling EUDI Wallet acceptance means making every customer-facing process in your organization capable of accepting a certified EUDI Wallet as a valid identity instrument, for identification, login, and qualified signing, regardless of which EU Member State issued the wallet. For large organizations, this involves more than a single technical integration: it requires aligning multiple business units, registering the correct attribute scope per intended use, and building a governance model that keeps all units within their registered boundaries.

Under eIDAS 2.0, regulated private organizations in sectors such as financial services, healthcare, telecom, and energy must accept EUDI Wallets by 24 December 2027, wherever strong user authentication is legally or contractually required. Public bodies face an earlier deadline of 24 December 2026. For enterprises operating across multiple sectors or service lines, the practical work starts well before those dates.

Three things define what scaling actually involves in practice:

• Registration per intended use: Under CIR (EU) 2025/848 of 6 May 2025, relying parties must register with a national authority before requesting wallet data. Each registration specifies exactly which attributes and attestations may be requested for a given use case. The wallet checks every request against that registered scope and stops the presentation if the request exceeds it.
• A shared integration layer: Rather than each business unit building its own wallet connection, a shared interface reduces duplication and keeps trust management consistent across the organization.
• Cross-unit data reuse: Verified identity data, once established in one interaction, can be reused across subsequent interactions, reducing friction for returning users without re-requesting the same attributes.

Which business units are most likely to benefit from EUDI Wallet integration first?

Business units that already rely on strong user authentication or formal identity verification are the most immediate candidates for EUDI Wallet integration. These are the units where the legal obligation under article 5f of eIDAS 2.0 applies first, and where the operational benefit of wallet-based identification is clearest.

In financial services, onboarding and KYC processes are the natural starting point. Identity attributes arrive cryptographically signed by the issuing party, so the data is tamper-evident when it reaches your business process. This does not replace your AML obligations: whether your organization may rely on an identity check performed elsewhere is governed by the AMLR and sector-specific rules, not by eIDAS itself.

In healthcare and pharmaceuticals, patient identification and prescription workflows benefit from wallet-based login at the highest assurance level. The wallet is issued at assurance level high, which most existing verification methods do not reach by default.

In government-facing services, units that interact with public registries or issue official documents are likely to face the 24 December 2026 public-sector deadline if they operate as public bodies, or the 24 December 2027 private deadline if they serve regulated sectors.

Units that handle qualified signing, such as contract management or document exchange, also benefit early. When a user’s identity is already established through wallet-based identification, a qualified signature can be completed in the same session without a separate identity check.

What are the main technical challenges when deploying across multiple business units?

The main technical challenges when deploying EUDI Wallet acceptance across multiple business units are managing wallet verification correctly, keeping each unit within its registered attribute scope, and integrating wallet-based flows into existing authentication and onboarding systems without rebuilding them from scratch.

Wallet verification is not a single check. Every presentation requires three separate controls:

1. Signature verification: The issuer’s signature is checked against the national trusted list of the relevant Member State, compiled in the EU List of Trusted Lists (LOTL).
2. Revocation status: The issuer publishes separate status information. Skipping this check means your process may accept revoked attestations.
3. Wallet unit attestation: This confirms that the presenting wallet runs on a certified wallet solution. Without this check, you cannot confirm the wallet itself is compliant.

Only the first check works fully offline. The second and third require active lookups. Organizations that build their own verification logic often underestimate this and implement only the signature check.

A second challenge is scope management. Each business unit may have different intended uses and therefore different registered attribute sets. A unit requesting more attributes than it registered for faces revocation of its registration. Keeping each unit’s requests within its declared scope requires clear internal controls and, ideally, a shared integration layer that enforces scope boundaries automatically.

A third challenge is system integration. Wallet-based login must fit inside the login flow the unit already runs. Similarly, identification data must flow into existing CRM, onboarding, or case management systems. The credential formats used in the EUDI Wallet ecosystem, mdoc (ISO/IEC 18013-5 for proximity, ISO/IEC TS 18013-7 for online) and SD-JWT VC, need to be handled correctly at the point of integration.

How should enterprises structure governance for multi-unit EUDI Wallet rollouts?

Enterprises should structure governance for multi-unit EUDI Wallet rollouts around a central registration and scope management function, with clear ownership at the business unit level for each intended use. The registration obligation under CIR (EU) 2025/848 sits with the organization that delivers the service to the user, not with any vendor or processor acting on its behalf.

A practical governance structure covers four areas:

• Central registration oversight: One team coordinates registration with the national authority and maintains the register of which unit has declared which attribute scope for which intended use. This team also monitors scope compliance and handles updates when a unit’s use case changes.
• Business unit ownership: Each unit owns its intended use declaration and is accountable for staying within its registered scope. Requesting attributes beyond what is registered is an explicit ground for revocation.
• Privacy and logging controls: Relying parties should log that they stayed within their registered attribute scope, not the full set of presented attributes. Logging the complete attribute set undoes selective disclosure at the front end in your own records.
• Vendor and processor boundaries: A supplier that processes wallet data on behalf of your organization is a processor under article 28 GDPR, not a relying party. The registration obligation and the access certificates remain with your organization.

Governance also needs to account for wallet unit identifiers. Because a user who switches devices will return with a different wallet unit and freshly issued attestations, customer records must never be tied to a wallet unit identifier. Link records to stable identity attributes or pseudonyms instead.

What role does the trust framework play in cross-unit wallet acceptance?

The trust framework is what makes cross-unit wallet acceptance reliable. It defines which wallets are certified, which issuers are trusted, and which relying parties are registered, so that every unit in your organization can verify a wallet presentation against the same authoritative sources without building its own trust infrastructure.

The framework rests on two types of lists. National trusted lists (ETSI TS 119 612) record qualified trust service providers per Member State and are aggregated in the EU List of Trusted Lists (LOTL). ARF version 3.0.0 adds Lists of Trusted Entities (LoTE, ETSI TS 119 602) alongside the trusted lists, covering additional trust anchors such as wallet providers and PID issuers. When a business unit verifies a wallet presentation, it checks the issuer’s signature against these lists.

For cross-unit deployments, the trust framework means that a wallet issued in Denmark, Austria, or the Netherlands is verifiable by any business unit using the same verification logic, because all certified wallets point back to the same trusted lists. Your organization does not need to maintain separate trust configurations per country or per unit.

One important boundary: the national registers of wallet relying parties under CIR (EU) 2025/848 are separate from the trusted lists. The relying party register records which organizations may request wallet data and what scope they declared. The trusted lists record which providers and issuers are qualified. Mixing up these two registries leads to incorrect compliance assumptions.

How can enterprises measure the success of EUDI Wallet adoption across units?

Enterprises can measure the success of EUDI Wallet adoption across business units by tracking wallet-based verification completion rates, scope compliance, and the reuse of verified identity data across interactions. These metrics reflect both technical performance and operational alignment with the registration requirements.

Useful indicators at the unit level include:

• Verification completion rate: The share of wallet-initiated identity requests that complete all three verification checks successfully, covering the issuer signature, revocation status, and wallet unit attestation.
• Scope compliance rate: Whether each unit’s attribute requests stay within its registered scope. Any request that the wallet rejects due to scope overage is a compliance signal that needs investigation.
• Identity data reuse: How often verified identity data established in one interaction is reused in a subsequent one, reducing the need to re-request the same attributes from the user.
• Time to complete identity-dependent workflows: For processes such as onboarding, contract signing, or account opening, wallet-based identification at assurance level high should reduce manual steps and back-and-forth.

At the organizational level, track how many business units have completed registration under CIR (EU) 2025/848 and how many intended uses are live versus planned. This gives a clear picture of rollout progress relative to the 24 December 2027 deadline for regulated private relying parties.

Avoid using wallet transaction logs as a monitoring tool for individual user behavior. The transaction overview in the wallet dashboard exists for the user, who can see which party received which data and submit a deletion request to that relying party. Your internal logging should confirm scope compliance, not replicate the attribute data that selective disclosure was designed to minimize.

How the ID Connector supports enterprise-wide EUDI Wallet acceptance

The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login, and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs, and identity documents, inside and outside the EU.

For enterprises scaling across multiple business units, the ID Connector handles the technical requirements that are hardest to manage consistently at scale:

• All three verification checks, including issuer signature against the trusted lists, revocation status, and wallet unit attestation, are handled per presentation.
• Verified identity data is reusable across interactions, so returning users do not need to re-present the same attributes in every session.
• Wallet-based login runs inside the authentication flow you already operate, at assurance level high.
• Qualified signing is available in the same session once identity is established, via a connected qualified trust service provider.

The ID Connector is used by organizations in financial services, healthcare, government, and pharmaceuticals. To see how it connects to your existing systems and supports your registration obligations, get in touch with TrustTech.