Last updated: 6 October 2026
If your firm is in banking, financial services, health, energy, transport or telecoms, you will at some point be obliged to accept the European Digital Identity Wallet. Our advice is to understand the obligation now and to defer the integration. The deadline is real, but the infrastructure you would be integrating with is not finished, and the obligation itself is narrower and stranger than almost every summary of it suggests.
Most coverage of the wallet compresses Article 5f into "regulated sectors must accept the wallet by the end of 2027". Every part of that sentence needs qualifying, and the qualifications are what determine how much work you actually have.
The provision is titled Cross-border reliance on European Digital Identity Wallets. Paragraph 2 is the one that reaches private firms, and it is worth reading closely rather than in summary. It applies to "private relying parties that provide services, with the exception of microenterprises and small enterprises", which "are required by Union or national law to use strong user authentication for online identification or where strong user authentication for online identification is required by contractual obligation".
Four things follow from that wording, and each one narrows the obligation.
Small firms are out. Microenterprises and small enterprises, as defined in Commission Recommendation 2003/361/EC, are expressly excluded. If you are under the small-enterprise threshold, Article 5f(2) does not reach you at all.
The sector list is not the test. The provision names transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications. But it introduces them with the words "including in the areas of", which makes the list illustrative. The actual trigger is whether strong user authentication is required of you by law or by contract. A bank is caught because payment services law requires strong customer authentication, not because the word "banking" appears. Conversely, a firm in a listed sector with no strong-authentication requirement is not automatically caught.
The duty is reactive. Acceptance is owed "only upon the voluntary request of the user". You are not required to offer the wallet, promote it, or make it a primary route. You are required not to refuse it when someone chooses to present one. That is a materially smaller engineering problem than the one most readiness pitches describe.
There is no date in the text. The obligation bites "no later than 36 months from the date of entry into force of the implementing acts referred to in Article 5a(23) and Article 5c(6)". The regulation sets a duration, not a deadline.
Two obligations run from the same starting gun, and understanding that relationship tells you more about your real timeline than any published date.
| Who | What they must do | By when |
|---|---|---|
| Each Member State | Provide at least one European Digital Identity Wallet (Article 5a(1)) | 24 months from entry into force of the implementing acts under Article 5a(23) and 5c(6) |
| Private relying parties in scope | Accept wallets on voluntary user request (Article 5f(2)) | 36 months from entry into force of the same implementing acts |
| Public sector bodies | Accept wallets where they require electronic identification (Article 5f(1)) | No separate period stated |
| Very large online platforms | Accept and facilitate wallet use on voluntary user request (Article 5f(3)) | No separate period stated |
The twelve-month gap between the two durations is deliberate. Member States are meant to have wallets in the field for a year before private firms are obliged to take them. That ordering is the single most useful planning fact in the regulation, because it means your obligation cannot sensibly arrive before there are wallets to accept.
You will have seen December 2026 for Member States and December 2027 for private relying parties. Those are arithmetic, not legislation. They are 24 and 36 months counted forward from when the first implementing acts entered into force, and they are only as firm as that starting point.
This matters for two reasons. The first is that a derived date behaves differently from a statutory one under pressure. The second is that the technical rulebook those implementing acts contain is still being amended. Implementing acts revising specifications published barely a year earlier have continued to land in the Official Journal. An integration begun against the current specification is an integration begun against a document that has been moving.
That is the honest reason to wait, and it is not a comfortable thing for a digital identity company to say. Readiness is supposed to be the pitch. But a relying party that builds now is buying rework, not readiness.
This is the obligation most readiness coverage omits entirely, and it lands on you rather than on the wallet provider. Article 5b is titled European Digital Identity Wallet-Relying Parties, and paragraph 1 is unambiguous: where a relying party intends to rely on wallets, "the relying party shall register in the Member State where it is established".
Registration is meant to be light. The regulation requires the process to be "cost-effective and proportionate-to-risk". But what you have to declare has consequences that outlast the paperwork.
Under Article 5b(2) you provide your Member State of establishment, your name and registration number, contact details, and critically "the intended use of European Digital Identity Wallets, including an indication of the data to be requested by the relying party from users".
Then Article 5b(3) closes the door behind you: "Relying parties shall not request users to provide any data other than that indicated pursuant to paragraph 2, point (c)."
In other words, you declare your data needs in advance and you are bound by that declaration. This is data minimisation enforced at the registration layer rather than left to your privacy notice. The practical implication is that your wallet-facing flows need to be designed before you register, not after, because the registration fixes what you are permitted to ask for. It is another reason that rushing the integration is the expensive order of operations.
Three further obligations in the same article are worth knowing now:
Member States must publish the register online in a form "suitable for automated processing" under Article 5b(5), and you must notify changes without delay under 5b(6). This is a live obligation, not a one-off form.
The gap between the regulation and a working ecosystem is wider than the timeline suggests, and it is worth understanding in detail, because the specifics tell you which parts are likely to slip.
An approved wallet must operate at level of assurance high. That is not a documentation exercise. It requires a robust binding between the user's identity and secure hardware, so that identities cannot be cloned or extracted. In practice it means cryptographic material held in a secure element or equivalent, not in software.
Translating that into shipped product means Common Criteria evaluation at EAL4+ or above, a process normally reserved for smartcards, SIM chips and government identity modules. It runs to one or two years of testing, audit and code review. We operate Common Criteria certified hardware security modules ourselves, and the practical burden is not the initial certification so much as everything after it: patching, maintenance and capacity planning all become slower when every change touches a certified boundary.
The harder constraint is that the secure hardware mostly belongs to someone else. Phones have secure enclaves and secure elements, but third-party applications have historically not been permitted to use them for arbitrary purposes. Apple has begun opening limited third-party access to its Secure Element under conditions. Android offers StrongBox and hardware-backed keystores, but availability varies across devices.
The consequence for the ecosystem is a dependency on two platform owners. Wallet providers need consistent access across hundreds of device models, and the terms of that access are set commercially rather than by the regulation. One alternative in the architecture is a remote signature creation device, where keys sit in a hardware security module operated by a provider. eIDAS 2.0 now recognises this explicitly: Article 3(23a) defines a "remote qualified electronic signature creation device" as one "managed by a qualified trust service provider". That is a meaningful opening, and it is the route that does not depend on a handset manufacturer's goodwill.
A wallet is empty until a Member State issues the holder a Person Identification Data attestation. Obtaining that requires identification at a high standard, and the routes available are set out in Article 24(1a): a notified electronic identification means at assurance level high, an existing qualified certificate, other methods confirmed by a conformity assessment body, or physical presence.
Countries with a mature national eID can issue against route (a) comfortably. Countries without one cannot, and several large Member States are in that position, either because they have no universal scheme or because the scheme they have is not widely used. Those Member States will have to lean on remote identification under route (c) or on physical presence. Until each country has published and certified a working route, wallet availability in that country is a plan rather than a service.
Article 5a(3) requires that the application software components of wallets "shall be open-source licensed". It is often quoted as meaning everything about a wallet is public, which overstates it: the same paragraph allows Member States to withhold the source of specific components other than those installed on user devices, for duly justified reasons. The practical effect is still real. Wallet implementations will converge, and a provider cannot differentiate on the wallet application itself.
Underneath the engineering sits an older problem, and it is the one we would ask about first.
Europe has run this experiment before. A scheme was built to let any citizen log in to another Member State's public services with their national credentials. Eventually it worked, in the narrow sense: a Swede could authenticate to another country's tax authority. Authenticate, but not be recognised, because a Swedish personal identity number and a Lithuanian one are constructed differently and the receiving system had no way to match an authenticated person to a record it already held.
Authentication and matching are different problems. The regulation now contains provisions on unique identification. A provision does not build the matching. Europe still has no common way to recognise that the person presenting a credential from one country is the same person already in your records, and the wallet inherits that on the day it launches.
So when a vendor arrives selling wallet readiness, there is one question worth asking before any other: how does your solution match a foreign wallet user to an existing client record, when Europe has no shared identifier? A clear answer is worth continuing the conversation. An unclear one tells you how ready anyone really is, including the vendor.
One distinction gets lost constantly, and it changes what you need to procure.
Identity and signature are separate things. The wallet is a container, and its job is proving who someone is. A qualified electronic signature is a distinct credential placed into that container, and behind it there is still a qualified trust service provider performing the cryptography and carrying the liability. Under Article 3(12), a qualified electronic signature remains "an advanced electronic signature that is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures". The wallet does not change that definition and does not remove the provider from the chain.
The practical consequence: the wallet becomes a new front door to qualified signing, not a replacement for it. If your firm needs signatures that carry the legal effect of a handwritten signature under Article 25(2), you will still need a qualified provider after the wallet arrives, exactly as you do now. For what that distinction means when buying, see what a qualified electronic signature actually is.
The failure modes here are not fines. The wallet framework is not primarily a penalty regime for relying parties. The costs are commercial, and they are incurred quietly.
Budgeting for an obligation you do not have. A firm that reads the sector list as the test, rather than the strong-authentication requirement, can commission an integration programme it was never obliged to run. The inverse also happens: a firm outside the listed sectors, but bound by a contractual strong-authentication requirement, concludes it is out of scope and is not.
Registering against the wrong data scope. This is the one with a long tail. Because Article 5b(3) binds you to the data you declared, a registration filed early and narrowly constrains what your product can ask for later. Changing it means going back to the register and notifying the Member State. A registration filed carelessly and broadly invites the opposite problem, since you have declared an appetite for data you cannot justify, in a register that Article 5b(5) requires to be public.
Building against a moving specification. The cost here is simply rework, and it is the most common outcome of acting on a derived deadline. Teams that integrated against earlier versions of the technical specifications have already had to revisit that work as implementing acts were amended.
Assuming the wallet replaces your signing arrangement. A firm that treats the wallet as an end-to-end answer discovers at the point of legal effect that it holds an identity credential and not a qualified signature. That discovery usually arrives during a transaction that needed one, which is the expensive moment to make it.
Doing nothing at all. The genuine risk of inaction is not the deadline. It is arriving at the deadline having never established whether Article 5f(2) applies to you, and then having to answer that question under time pressure, at the same moment as the integration work.
The work that pays off in 2026 is almost entirely analysis rather than engineering.
Establish whether Article 5f(2) actually reaches you. Two tests, both answerable from documents you already hold. Are you above the small-enterprise threshold? And is strong user authentication required of you by Union law, national law or contract? If either answer is no, your obligation is different from what the sector-list summaries imply, and you should know that before budgeting for it.
Decide what data you would request, before you register. Article 5b(3) makes that declaration binding. Work out the minimum set your flows genuinely need, and treat that analysis as the prerequisite to registration rather than a form-filling step at the end.
Scope the duty accurately. Acceptance on voluntary user request is a narrower requirement than wallet-based onboarding. Write down which of your flows a user could present a wallet into, and treat that as the scope. It is usually smaller than a readiness pitch assumes.
Ask vendors the matching question. Before any integration spend, put the identifier question above to anyone selling readiness, and keep the answer.
Watch the implementing acts, not the calendar. Your clock runs from their entry into force. That is the date worth tracking, and it is the one that moves.
Defer the integration itself. Specifications that are still being amended are not a stable build target. Spend attention now and money later.
The obligations that will actually land on a regulated firm before the wallet does are the ones already in force. The Anti-Money Laundering Regulation applies from 10 July 2027, and its customer due diligence requirements reach identification directly. For banks specifically, we worked through which processes those deadlines actually change in QES use cases in EU banking.
There is a useful consequence here. An identity process built on a regulated trust service today, rather than on a single national eID, is already doing most of what the wallet era will ask of it: identification at a defined assurance level, a reproducible verification record, and coverage that does not stop at one country's border. That work is not wasted when wallets arrive. It is the thing wallets plug into. What a national eID login proves, and what it does not, is something we took apart in no log, no decision.
ZealiD is a Qualified Trust Service Provider on the EU Trusted List, listed under Sweden and supervised by the Swedish Post and Telecom Authority. We identify people remotely under Article 24(1a)(c), across nationalities rather than within one national scheme, and issue qualified certificates against that identification. If you want to understand what obtaining one involves, see how to get a qualified electronic signature.
Take the next step
Contact ZealiD to implement a plug-and-play digital identity wallet for your organisation.
Stay up to date with news and trends on digital identity and Qualified Electronic Signature
.svg "ZealiD Logo New (1)"){kind=small}
