The deadline for relying parties: what changes and what remains open
Regulation (EU) 2024/1183, better known as eIDAS 2.0, entered into force in May 2024. It obliges Member States to provide citizens with an EU Digital Identity Wallet (EUDI wallet) that lets them identify themselves, prove attributes and sign qualified. Wallets are to be available in Member States by the end of 2026, depending on the adoption of implementing acts that set technical details. For SaaS providers the deadline matters for another reason: in the regulation's language they are relying parties, services that accept wallet credentials and base decisions on them.
What exactly awaits relying parties depends on the sector. The regulation provides that certain private services that must require strong user authentication, for example in banking and finance, transport, energy, health and telecoms, must accept the wallet when users wish to use it. Very large online platforms are included as well. Many B2B SaaS providers face no direct acceptance duty, but their customers in regulated industries pass the expectation on. Anyone selling into these markets will be asked about wallet capability in tenders long before an obligation applies.
We value a sober assessment, because many claims circulate on this topic. First, deadlines and details depend on implementing acts and national transposition. Second, the maturity of wallets is not uniform today. Third, the picture keeps changing. Check the current status regularly, for example via the EUDI wallet Architecture and Reference Framework, and do not rely on vendors presenting wallet readiness as complete. We say it plainly: Sign2x prepares, but is not “EUDI-ready”. Anyone claiming that without a productive wallet ecosystem promises something nobody can deliver.
For SaaS teams this means the deadline is less a date for flipping a switch than a period in which expectations form. Customers will ask whether your product can process wallet credentials, whether you accept attributes such as age or professional qualification, and whether you support a wallet-based signature. The honest answer today for most vendors is: “we are preparing the architecture.” That beats a promise, but only credible if you can explain concretely what preparation means.
The wallet's role in signing adds to this. The regulation provides that the wallet enables creating qualified electronic signatures, free of charge for non-professional use. For providers of signing flows this is an opportunity and an uncertainty: users might in future sign qualified with their wallet without a separate identification flow. How this fits your processes depends on which wallets are available in your markets and how qualified trust service providers connect them. Background on the levels is in SES, AES and QES in SaaS.
Why you should not build the wallet integration yourself
Many development teams' first reflex is: “It is a protocol, we will build it.” With the EUDI wallet that is a risky decision. The specification moves, the requirements for relying parties include registration, certificates, data minimisation and protocols for presenting and verifying credentials, and Member State implementations differ in detail. Anyone building their own integration today builds on a foundation that may still shift in the coming months.
Then there is responsibility. As a relying party you carry duties when accepting credentials: you may request only the data you need for the purpose, must register and authenticate towards the wallet. Errors in verifying a credential are not cosmetic flaws but security gaps. Maintaining this logic belongs with teams that run it as a core task, not in a side strand of your product team.
From a cost view, too, little speaks for building it yourself. Wallet integration is no differentiator for your product. No customer buys your software because you implemented the presentation protocol elegantly. They buy it because it solves a domain problem, and the wallet is a channel through which users will bring identity and attributes. Treat it like payment processing: you can build it yourself, but most should not.
Another point is operational load. Certificates expire, trust lists change, specifications are updated. Anyone running their own integration takes on a continuing maintenance duty that is hard to plan. That applies especially to ISVs with many tenants, where every change acts several times. Effort scales with the number of customers, not with their benefit.
A pragmatic stance therefore reads: watch the development, understand the terms, classify your use cases, but do not build the protocol yourself. Which use cases are realistic depends on your business. Typical candidates are age proofs, identification at account opening, professional qualifications in HR settings and signatures with high evidentiary weight. For each, record which data you really need, because data minimisation is a core principle of the wallet logic.
API abstraction: the wallet as one identity channel among several
The robust path is an abstraction. Your product does not talk to the wallet but to a layer bundling various identification and signing channels behind a stable interface. Which channels stand behind it, video identification, eID, bank identification, wallet or something yet to emerge, stays exchangeable without your product code changing. It is the old principle of loose coupling applied to identity.
What does that look like in practice? Your product creates a signing transaction and states which requirements apply: signature level, required attributes, where relevant identification level. The layer below selects or enables the suitable channel and reports the result back by event. Your system learns only: transaction identified, signature given, result with reference. The channel details, whether a user identified via wallet or another route, are secondary for your domain logic and recorded in the event data for evidence.
This approach has three advantages. First, it protects your investment: when specifications change, the layer adapts, not your product. Second, it allows gradual rollout: you can enable wallet-based paths for selected tenants or processes once they are available and legally clarified. Third, it keeps the evidence format consistent: your event data looks the same regardless of the channel through which a user was identified, and your reports need no per-channel adjustment.
It matters that the abstraction does not blur legal differences. An AES and a QES signature carry different evidentiary weight, and a wallet credential does not automatically replace every other check. Your interface and contracts must therefore keep making clear which level applies and what follows from it. The legal basis of the levels is in the eIDAS Regulation in its original version, as amended by Regulation 2024/1183.
For ISVs working with white-label, a tenant aspect is added. Not every customer will want the same wallet strategy. A healthcare tenant has different needs from a property manager. A multi-tenant abstraction lets you configure channels per tenant rather than forcing a global decision. How events flow cleanly into your system is explained in webhook state management.
Partner QTSP: who carries the qualification
The qualified electronic signature requires a qualified trust service provider (QTSP) that is approved by supervision and meets the eIDAS requirements. That holds in the wallet world too: the wallet can provide identity and signature initiation, while the qualified signature itself arises at a provider with the corresponding status. For SaaS providers that means choosing the QTSP partner remains a strategic decision.
Sign2x is not a QTSP. We are the API layer bringing the signature levels SES, AES and QES into your product. For QES we work with partner QTSPs such as Sign8. This division of roles is not only a legal necessity but an advantage for you: qualification stays where it is regulated and audited, and your integration stays at the API level you can shape. How to handle partners is deepened in QTSP partners for ISVs.
For the wallet future this yields a sober expectation. Whether and when QTSPs connect wallet-based signatures productively is up to the providers and supervision. We make no advance promises. What we can do is shape the API so that new channels can be added without breaking your product once they are productive and legally sound. That is preparation, not a product promise.
In choosing a QTSP partner, ask a few questions. Which signature levels and identification routes are productive today? What is the roadmap for wallet connections, and how binding is it? Where is data processed and which law applies? What do exit and data export look like? And how are liability and support shared in a disruption? These questions apply regardless of the wallet, but become more urgent with it because the number of channels grows.
What Sign2x prepares and what it does not
For transparency: Sign2x runs on the Open Sovereign Cloud (OSC) from T-Systems, and the platform is designed as an API layer for SES, AES and QES. From this architecture wallet scenarios can be prepared without our advertising them as a productive feature today. Concretely, preparation for us means: stable, channel-independent event models, tenant-capable configuration, clean separation between API layer and qualification at the partner QTSP, and hosting under European law.
What we do not claim: we do not claim the EUDI wallet is productively usable in Sign2x today. We do not claim we hold a certification for wallet relying parties. And we claim no timelines we do not control. Anyone needing a wallet integration productively today should clarify that openly with us and the partner QTSPs so nobody plans on a false assumption. Our stance on sovereignty is in Cloud Act vs data sovereignty.
What you can prepare yourself is considerable. First, inventory where identity or attributes play a role in your product. Second, check which data you really need and drop what is collected out of habit. Third, separate identity checks from domain logic in your code so a new channel touches no domain logic. Fourth, keep a clean event model that records the channel as an attribute. Fifth, watch the implementing acts and Member State publications, especially in your target markets.
For regulated customers the audit view adds to this. If you later accept wallet credentials, you must be able to show which checks took place. An event log recording channel, time and result is the basis. How this works in the context of supply chain duties is in DORA Article 30 and the API audit trail. We stress here too: this is evidence, not certification.
To start we recommend a short workshop with product, legal and engineering: which use cases could benefit from a wallet? Which customers already ask? What would be the minimum scope sensible in twelve months? The answers form a roadmap fitting your markets rather than general expectations. Materials are in the developer hub, terms in the help centre, examples under use cases, and the Sign2x quiz offers a self-assessment. More articles are in the Sign2x blog.
Discuss your EUDI preparation with us
Related articles: AML-ready signature API: identity provider, QTSP partner, Sign2x layer and eIDAS signatures in the sovereign cloud. Information on security is available from the BSI.
Frequently asked questions
By when must Member States provide the EUDI wallet?
Regulation (EU) 2024/1183 provides for availability by the end of 2026, depending on the adoption of implementing acts. Check the current status in your target markets.
Must my SaaS product accept the wallet?
That depends on the sector. Certain regulated services and very large platforms must accept the wallet. Many B2B providers face no direct duty, but their regulated customers pass expectations on.
Is Sign2x EUDI-ready?
No. Sign2x prepares the architecture, for example with channel-independent event models and tenant-capable configuration. We do not claim a productive wallet integration.
Does the wallet replace the QTSP?
No. The wallet can provide identity and signature initiation. The qualified signature itself arises at a QTSP. Sign2x is not a QTSP, QES runs through a partner such as Sign8.
Should I build the wallet integration myself?
Generally no. Specifications and implementing acts are moving, and relying party duties are security-critical. An abstraction layer protects your investment.
