“A citizen needs an income statement from the tax office to qualify for social housing. Traditionally, the tax authority won’t give third parties API access to citizen income data, so the citizen requests a paper document, hands it to the housing provider, and the housing provider manually checks, copies and files it. With a digital wallet, the tax office verifies the user’s identity and delivers the income statement directly into their wallet. The housing provider receives it instantly, can verify it is genuine, and the citizen never had to visit an office.”
This example, drawn from a live implementation in Rotterdam, illustrates what eIDAS 2.0 actually changes in practice. The regulation is often discussed in terms of compliance obligations, certification timelines and technical standards. Those things are not the practical implications of eIDAS 2.0 for citizens. For organisations paying attention, eIDAS 2.0 creates a set of concrete business opportunities. This article maps five of the roles emerging in the eIDAS 2.0 ecosystem, the revenue models attached to each, and the deadlines that make timing matter.
These insights are drawn from a recent webinar with Boris Goranov. Register here to access the full recording.
The wallet as shared infrastructure
Before eIDAS 2.0, digital identity was built on one-on-one connections. Every issuer had to establish individual relationships with every relying party, agree on protocols, and manage the legal and commercial terms of each data exchange. As Boris Goranov, CEO of Ubiqu, put it during a recent webinar: “When the amount of connections grows, it grows exponentially and becomes unmanageable.”
The wallet changes that logic. Issuers no longer need to think about which relying parties they give access to. They focus on supporting a wallet. Relying parties focus on reading from a wallet. The user transports their own data between the two, which also resolves a long-standing problem around consent and GDPR: the user fetching their own data from an issuer creates a legal basis for sharing, and the user delivering that data to a relying party constitutes consent. Trust stops being rebuilt from scratch in every transaction and becomes shared infrastructure.
Five roles, five revenue models
Private wallet providers
Banks and telecoms are in a structurally interesting position. When government wallets become available, users will be able to log in to banking apps or authorise transactions using any compliant wallet, not just the bank’s own app. That erodes customer intimacy. The defensive move is to upgrade existing apps to function as certified private wallets, so users add their government-issued credentials there rather than elsewhere.
The offensive move is to recognise that banks and telecoms are themselves authentic sources: a bank knows which accounts a user holds and can issue statements on financial means; a telco knows which mobile number belongs to which customer. Both can monetise that data as verifiable credentials consumed by relying parties in KYC, KYB and onboarding flows. Revenue models here run on per-wallet subscription fees or per-transaction charges. The deadline for mandatory wallet acceptance is 2027.
Credential issuers
Not all credentials need to be delivered into a wallet for free. Organisations that hold valuable, verifiable data such as professional registers, diploma authorities, tax offices or sector-specific databases can become Qualified Electronic Attestation of Attributes (QEAA) providers. A credential issued by a QEAA is legally recognised across all EU member states, which means the addressable market for monetising that data is EU-wide.
Relying parties benefit because verifiable credentials lower their verification costs, which creates a genuine incentive to pay for them. Revenue models include per-credential charges or partnership arrangements with QTSPs. The deadline for authentic sources is the end of 2025, meaning this window is open now.
Signing platforms
Many existing signing platforms operate at the advanced electronic signature level, not the qualified level. eIDAS 2.0 creates both pressure and opportunity to upgrade. The wallet removes the biggest friction point in qualified signing: identity verification. Once a user’s identity is established in their wallet, signing digitally at scale becomes far more practical.
That also creates downstream demand for archiving at scale, which is one of the new trust services introduced under eIDAS 2.0. Revenue models are per-signature or per-seat per month. The regulation is already in force, so the window to position is now.
System integrators
The number of organisations that need to become compliant issuers in the coming years is large, and the timelines are not generous. Custom-built QTSP projects historically take two to three years from start to finish. System integrators and consultancies that can offer reusable, pre-certified components rather than starting from scratch on every engagement will have a structural advantage. Reducing delivery risk matters as much as reducing cost when public sector procurement deadlines are fixed and non-negotiable.
Existing QTSPs
QTSPs that already operate one or more trust services under eIDAS 1.0 are well positioned to expand, but most have built tightly integrated stacks that do not lend themselves easily to adding new qualified services. The opportunity is to add service lines, bundle offerings, and become a QEAA to participate in attribute-based value chains. The constraint is architectural: doing that on a monolithic legacy platform is slow and expensive. Volume-based API pricing becomes viable when the infrastructure can support it.
What all five roles have in common
Across all five roles, three requirements appear consistently.
- Certified key management: wallet providers need cryptographic key storage for wallet backends, and issuers need signing key infrastructure.
- Compliance infrastructure: covering audit logs, registration authority functionality and certificate issuance capability.
- Modular architecture: since eIDAS 2.0 requirements are evolving annually and organisations running multiple service categories need components they can update independently without rebuilding entire systems.
The compliance surface is larger than most organisations anticipate. Demonstrating conformity against ETSI requirements involves approximately 1,500 line items, each of which needs to be implemented, evidenced and shown to be working over time. That is an ongoing operational capability.
Build, buy or partner
Given the complexity and the deadlines, most organisations face a genuine build-or-buy decision. Building in-house means full control and ownership of certification, but projects of this kind run two to three years and carry significant delivery risk. Outsourcing to a managed QTSP is fast and low-investment, but the certification belongs to the vendor and lock-in is high. A third path is to implement pre-certified, modular components that reduce time to market to months rather than years, while preserving control over the stack and keeping lock-in low through interchangeable building blocks.
At Ubiqu, that third path is what we have built. Our remote secure element provides certified cryptographic key management at scale, and our issuer platform packages the organisational, procedural and technical compliance components so that customers focus on governance controls rather than rebuilding infrastructure that already exists. The goal is not to replace the organisations becoming QTSPs. It is to give them the certified layer underneath so they can move at the speed the market requires.
