EUDI Wallet business models in 2026: is the elephant still in the room?

More than a year has passed since we published "The elephant in the European Digital Identity Wallet room : how can service providers get paid?" The article became the starting point for a heated debate on how commercial actors, notably (qualified) trust service providers, can get paid for providing their services to the EUDI Wallet ecosystem. Has anything changed by mid-2026, with Member States struggling to get their EUDI Wallet offerings in place before the end of the year?

The answer is both yes and no. The elephant is still in the room in the sense that the base problem is still there: the EUDI Wallet architecture and protocols still don’t cater for commercial actors to get paid. But with real Wallet launch approaching, actors are trying to circumvent the elephant to find other business models that might work, at least in the medium term. 

The EUDI Wallet ecosystem has evolved during the last year. Business models do not attach to technology but to roles, obligations, risk, control points, contractual relationships, and operational cost. The Architecture and Reference Framework (ARF) for the EUDI Wallet now gives us a much clearer view of those roles. What it still does not give us is a single pan-European payment rail that determines who is able to pay whom, when, and for what. 

The hard problem remains: how do we compensate the actors who create trust without undermining the privacy architecture that makes the EUDI Wallet trustworthy in the first place?

Recap of the problem

Several roles in the EUDI Wallet ecosystem are designed to be taken by (qualified) trust service providers (QTSP/TSP). The eIDAS regulation defines (Q)TSPs as commercial service providers in the EU internal market. Someone must pay them. Take Signicat as an example. We intend to become a qualified issuer of electronic attestations of attributes (QEAA), but we can’t provide that service unless we get paid. Commercial EUDI Wallet providers and providers of signing services for EUDI Wallets have the same challenge.

There are essentially two business models: either the government provides funding or actors in the ecosystem pay for services. An “indirect” alternative may be that actors lose money on their role in the EUDI Wallet ecosystem, but by providing it they gain income by other means. An example can be an EUDI Wallet provider that doesn’t earn money from providing the EUDI Wallet but from adjacent services outside of the EUDI Wallet ecosystem.

There are three roles in the Wallet ecosystem that can pay (outside of government funding): the user, the Relying Party (RP), and the (authentic) source that has information it wants to publish to EUDI Wallets in the form of attribute attestations.

A Relying Party (RP) is usually a service provider and may be the actor that gains most from EUDI Wallet usage and hence in many cases should be the actor that pays. But according to the eIDAS regulation, neither an EUDI Wallet provider nor a QEAA provider can know where the EUDI Wallet and attestations are used, and payment would reveal the usage. 

A user can pay to get attestations into their EUDI Wallet, and the source of attributes may be willing to pay someone to issue them to EUDI Wallets. Take the example of a university diploma. The user can be interested in paying to get that in their EUDI Wallet, and the university may desire to pay someone to issue diplomas in the form of EAAs. But will this generate sufficient income for a QEAA provider?

An architecture where a core actor can’t pay for services is a problem. The original “elephant paper” sketched some approaches to allow the RP to pay. The specification of a protocol that can mediate payment metadata and create billable events at least for QEAA providers is ongoing in ETSI, but such a protocol is unlikely to be deployed anytime soon. When an intermediary is used to provide EUDI Wallet functionality to an RP, the intermediary can mediate payment; we’ll get back to this one. The two other alternatives, establishment of a clearinghouse and use of smart contracts, aren’t going to materialise.

The elephant is still there with actors sneaking around it

The elephant in the room is still there in the sense that payment for trust services is not addressed by the Architecture and Reference Framework for the EUDI Wallet nor by other EUDI Wallet specifications. When actors are now getting ready for the “real stuff” of deployed national EUDI Wallets and the entire infrastructure with real, commercial services, actors are getting creative about finding ways to get paid. Below, we describe the business models we see emerging to deal with the elephant in the room.

The PubEAA role as a threat and an opportunity

A PubEAA provider is the government issuing EAAs themselves instead of relying on commercial QEAA providers to do the job. On one hand, this is understandable, as reliance on QEAA providers can be risky. If no QEAA provider takes on the job of mediating information from a Member State's authentic sources, that Member State's information won’t be published. On the other hand, if PubEAA providers issue attestations for free, a commercial QEAA provider will have an even harder time getting return on investment.

In the short to medium term, however, there is a business opportunity for QEAA providers. The requirements for a PubEAA provider are on par with those for a QEAA provider, and none or few governments have agencies that can fulfil these requirements today. What governments might do, at least as a temporary solution, is to hire and pay a QEAA provider to do the job of issuing EAAs signed with the government’s certificate. That is, the QEAA provider offers a white-labelled service on behalf of the government.

Attribute sources can pay

Member States are expected to make attributes from their authentic sources available to Wallets. An alternative to establishing a PubEAA role is to pay at least one QEAA provider to publish them. Other QEAA providers will also have access but the selected one(s) will get compensated for providing a guarantee that the information is available to EUDI Wallets.

The same model applies to other attribute sources that want their information to be available as EAAs. They need to pay an EAA provider (qualified or in this case even non-qualified) to issue the attestations, and they may even need to pay (commercial) EUDI Wallet providers to accept these attestations into their Wallets. The white-label model, where the EAA provider signs attestations using the source’s certificate, is relevant here as well, but then the source must independently register as an EAA or QEAA provider.

Users won’t pay

The legal requirements from eIDAS are that users shall not pay for obtaining or using an EUDI Wallet, nor for signing “for non-professional purposes”. There’s nothing prohibiting requesting payment for attestations, though. But Member States will struggle to reach mass deployment of EUDI Wallets. If users are asked to pay, e.g. to get a driving license issued to their EUDI Wallet, that will hamper uptake. It’s unlikely that any EUDI Wallet provider or QEAA provider will charge users from the start.

Relying Parties may pay registration fees

RPs, usually service providers required to accept EUDI Wallets or wanting access to EUDI Wallets for their service provisioning, must apply to a registrar in the country where they are registered. Following approval, they will get an access certificate. At the discretion of the Member State, RPs may need to pay, which could be a one-time fee or another model, like an annual fee.

Note that issuing of the access certificates should be another QTSP role in the ecosystem, but this role should have a guaranteed payment either from RP fees or from the government paying them to issue the access certificates. We write “should be” because some Member States may establish the certificate issuing themselves, which strictly speaking would break the eIDAS rule that certificate issuing is a commercial trust service in the internal market. The RP fee could be distributed to actors in the ecosystem but maybe it’s more likely that the government keeps the money to cover their own cost, after the access certificate fee is paid. Any payment to EUDI Wallet providers and (Q)TSPs would happen according to national rules and will differ between Member States.

In addition to the access certificate, RPs need registration certificates to state which attributes they need and are allowed to ask for. These certificates are issued as attribute attestations. That should be by a QEAA provider paid through the registrar. Some Member States may decide to establish the registration certificate issuing themselves, like a PubEAA provider. This is still a business opportunity for QEAA providers if  governments buy the service white labelled.

A disadvantage of national payment schemes is that RPs that have a choice, like multinational companies, may seek to register in the Member State that charges least.

Intermediaries are getting increasingly important

All the above are payment options for issuing. Payment for the use of EUDI Wallets, for Person Identification Data (PID) authentication, for presentation and validation of QEAAs, or for signing, is not handled by these models. As mentioned before, the eIDAS regulation states that the user shall not pay for use. Payment for use means models such as transaction-based or user-based (number of unique users) payment and implies creation of a “billable event” that can trigger charging from an identified payer in the ecosystem to an identified receiver.

As stated, the current EUDI Wallet protocols not only don’t cover payment for use, they actively prohibit the RP from paying due to the unlinkability property for presentation of PID and QEAAs. EUDI Wallets will from the start differ in functionality. Not all of them will support all attestations or even issuing into the EUDI Wallet by commercial QEAA providers. The content of the PID won’t be uniform across EUDI Wallets despite the effort to define a minimum PID attribute set. These aspects and more imply that different EUDI Wallets must be treated differently. And there’s going to be at least 30 EUDI Wallets with a legal obligation for many RPs to accept them all. This is a complexity that many RPs would like to outsource, especially since investments in EUDI Wallet acceptance won’t pay off for the RP until EUDI Wallets are widely deployed and used.

An intermediary is a service provider that integrates EUDI Wallet functionality on behalf of RPs, or as the ARF phrases it “an RP acting on behalf of other RPs”. An example is an actor offering one API that an RP can use to do PID authentication and QEAA validation from any EUDI Wallet. The API may support other eIDs, too, like Signicat’s “eID and Wallet Hub”.

The intermediary’s business model is sound as it will be paid by the RP, typically through a subscription fee and per-transaction pricing of EUDI Wallet transactions. Per-user pricing may be difficult since an intermediary isn’t allowed to store data about the context of a transaction. The intermediary role is accepted for the EUDI Wallet ecosystem although it isn’t shown explicitly in the wallet ecosystem.

An intermediary may be able to pay EUDI Wallet providers and QEAA providers without revealing who the real RP is. The EUDI Wallet or QEAA provider will only know that it’s one of the RPs using this specific intermediary. There is, however, a need for payment information that determines how much the intermediary shall pay, either through payment metadata in attestations, published information, or by contract between the intermediary and other EUDI Wallet actors.

Signing by government funding or Relying Party payment

The signing service role described in the EUDI Wallet architecture is a basic one that can apply a signature from the EUDI Wallet user to one or more documents. There’s not a single, mandatory way to sign using EUDI Wallets but there are two basic ways to integrate with a signing service: either it’s called from the EUDI Wallet, or it’s called from the RP side using the EUDI Wallet as an activation mechanism.

For a QTSP providing a signing service, these alternatives are very different. When the service is called from the EUDI Wallet and signing requests pass through the EUDI Wallet, the RP has no connection to the signing service and there’s no payment model available for the RP. Remember that the user shall not pay for signing, except possibly for “professional use” but determining what’s personal and what’s professional is a challenge.

It’s expected that some Member States may attach a signing service to their EUDI Wallets this way; that users at onboarding get both the EUDI Wallet and the ability to sign calling the signing service from the EUDI Wallet. In this case, the Member State must pay for the signing service. 

When the signing service is integrated at the RP side, this is completely different. The RP selects its signing service provider(s) and knows which service is used. There’s nothing preventing the RP from paying.

Signing through intermediaries

A signing service as described above can only support basic signing scenarios like one signer signing one or a set of document(s). Signing may be a much more complex process needing orchestration between multiple signers and packaging to long-term formats that include (qualified) timestamps and more. There is a need for trustworthy display of the document towards the signer and for trustworthy capture and recording of the signer’s consent to sign. While some signers may use their EUDI Wallets, other signers in the same process may use other means to sign.

As for EUDI Wallet integration in general, these are complexities that many RPs want to outsource to a “signature creation service provider” like Signicat Sign. This can conceptually be seen as another kind of intermediary in that the RP calls it for all signing, and the integration to the EUDI Wallet signing service(s) is handled by the signature creation service provider. The RPs pay the intermediary (the signature creation service provider), who in turn pays the EUDI Wallet signing service providers.

Identity proofing and PID issuing can create business

Member States, and commercial EUDI Wallet providers, must onboard users to EUDI Wallets through the use of an existing eID at assurance level ‘high’ or through an existing eID at assurance level ‘substantial’ augmented by a process using an identity document and “selfie-video”. Some Member States may accept the document + selfie-video process alone, without any eID. Processes are regulated through an eIDAS implementing act referring to the standard ETSI TS 119 461 as a basis.

There’s a business opportunity for identity proofing service providers to do this job contracted to governments following a tendering process. 

Conclusion

The elephant is still in the room as the core payment challenges of the EUDI Wallet ecosystem aren’t solved and have not really been addressed. The basic EUDI Wallet architecture still doesn’t allow RPs to pay for their use of the EUDI Wallet. But actors are finding ways to get paid by other business models, circumventing the elephant.

Some of these business models will remain, while the long-term viability of others may be uncertain. E.g., the intermediary role may be seen as a necessary evil to get the ecosystem going but not as a role that should be accepted when (or if) the EUDI Wallet integration to RPs is sufficiently easy for RPs to manage by themselves.

About the author

Jon Ølnes is a leading expert in digital identity, with over 25 years of experience in eIDs, electronic signatures, and trust services. He plays a key role in shaping European policies and standards on digital identity. He recently led the revision of ETSI’s identity proofing standard, a core technical standard that underpins the amended eIDAS regulation and the EU Digital Identity Wallets. At Signicat, Jon has spent the past eight years driving product development for the European market.