By the end of 2026, every EU member state must offer its citizens a free, government-backed digital identity wallet. That is not a roadmap slide — it is a legal deadline, and the clock that drives it has already been running for over a year and a half. The law behind it is eIDAS 2.0, formally Regulation (EU) 2024/1183: an amendment to the EU’s 2014 electronic identification and trust services regulation (eIDAS). Put plainly, every member state has to put a phone-based identity wallet in its residents’ hands, and businesses in regulated sectors will progressively be required to accept it.
If you run identity, security or compliance in a European enterprise, this is worth fifteen minutes now, because the obligations arrive on a schedule you can plan around — and because a lot of what is being written about the wallet quietly overstates what it will do for you.
The timeline you can plan around
The regulation entered into force on 20 May 2024. The dates that matter to a business are anchored to the implementing acts — the technical rulebooks the European Commission publishes underneath the regulation. The first batch was adopted in late November 2024 and entered into force in December 2024, which started two countdowns:
- 24 months — end of 2026. Every member state must provide at least one EU Digital Identity (EUDI) Wallet to its citizens, residents and businesses, free of charge.
- 36 months — end of 2027. Under Article 5f of the regulation, private relying parties that are required by law or contract to use strong user authentication must accept the wallet when a user asks to use it. The sectors this points to include transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications. Microenterprises and small enterprises are exempt. Very large online platforms (the 45-million-user tier regulated under the Digital Services Act) fall under the same deadline.
How far along is the rollout in practice? An April 2026 status survey found no certified production wallet live in any member state yet: Denmark, Ireland, France and Germany had opened public sandboxes for integration testing, several countries plan to upgrade existing national identity apps, and the rest had nothing public to test against. The deadline is fixed; the readiness is uneven. Both facts should shape your planning.
What it changes for your business
Four things, concretely.
- Customer onboarding gets a new front door. Today, verifying a new customer’s identity online means document photos, video calls or a bank-login detour — per country, per provider. A wallet holds government-verified attributes the user can present in seconds, valid across all member states. For any business doing know-your-customer (KYC) checks, that is a cheaper and faster channel than the ones it replaces — and one that many businesses in the sectors above will have to accept anyway.
- The obligation lands where PSD2 already applies. Banks and payment providers already live under PSD2, the EU payment services directive that mandates strong customer authentication (SCA). The acceptance obligation is written for exactly that population: relying parties already required to authenticate their users strongly. What it does not do is rewrite PSD2. How a payment is approved, and how that approval is tied to the amount and the payee, is governed by the same rules as before.
- Qualified signatures stop being a paid extra. The wallet lets citizens create qualified electronic signatures — the kind legally equivalent to a handwritten one — free of charge for non-professional use. Expect customers, over time, to arrive able to sign contracts at a level of assurance that used to require a paid certificate.
- “Log in with your wallet” becomes an expectation. Once public services and banks accept it, users will ask why your customer portal does not. For medium and large companies in the listed sectors, that question has a legal answer with a 2027 date on it.
What eIDAS 2.0 does not mean
This is the section most vendor material skips, so let us be plain.
- The wallet does not manage your workforce. It is a citizen-facing credential for accessing public services and regulated private services. It says nothing about your employees, their roles, their VPN access, their Windows logins or their admin consoles. Nothing in the regulation replaces your identity and access management (IAM) stack, and your obligations under NIS2 to protect those workforce logins are entirely unchanged.
- It is not single sign-on for employees. An employee proving to the state who they are is a different problem from an employer controlling what an authenticated employee may do. The wallet addresses the first; single sign-on, session policy and privileged access remain yours.
- The dates are deadlines, not delivery dates. The legislative milestones have landed on time so far, but as of spring 2026 no wallet had been certified for production use and national readiness varied widely. Planning for wallet acceptance is prudent; planning your 2026 security posture around the wallet’s arrival is not.
- Notakey is not an EUDI wallet provider. Wallets are issued by member states or by providers they mandate and certify. We do not build one, and this post is not a pitch that we do. We are also not a qualified trust service provider: a Notakey approval is a cryptographic signature bound to a specific request, not a qualified electronic signature. What we build sits next to the wallet, and that is the next section.
Where enterprise authentication fits alongside the wallet
The wallet answers one question extremely well: who is this person? It is an identification and onboarding instrument. The question your systems answer all day is a different one: did this specific person just approve this specific action? A payment release, a VPN session, a server login, a change to a payout account. That is authentication and transaction approval, it happens long after onboarding, and it stays the enterprise’s job — wallet or no wallet.
That operational layer is what Notakey does.
- Every approval is readable and specific. The user’s phone shows exactly what is being approved — which system, which action, which amount — and the approval is a cryptographic signature over that exact request. This is the dynamic-linking model PSD2 SCA is built on, and it is the only thing that defeats push-bombing: a prompt nobody initiated is visibly not theirs.
- The key never leaves the phone. It is generated in the device’s secure hardware, so there is no shared secret to phish, intercept or reset over a help-desk call.
- Every event is evidence. Each login and each signed transaction produces a timestamped, tamper-evident record — the audit trail PSD2, NIS2 and GDPR assessments ask you to produce.
- It runs where your data has to stay. On-premise in your own infrastructure or in the cloud, with users drawn from the Active Directory, LDAP or RADIUS sources you already maintain.
A sensible 2027 architecture, in other words, is not wallet or enterprise authentication. It is wallet at the front door for identification, and strong, auditable transaction approval behind it for everything the customer or employee does afterwards.
How to prepare: a short checklist
- Classify yourself. Are you in one of the Article 5f sectors, above the small-enterprise threshold, and required by law or contract to use strong user authentication? If yes, wallet acceptance is a legal obligation rather than a product decision, and work that starts in 2027 starts late.
- Inventory the flows. List every customer-facing point where you identify a person or demand SCA: onboarding, login, payment approval, contract signing. Each is a candidate for wallet acceptance; each also needs a fallback, since acceptance is at the user’s option.
- Track your member state’s wallet. Deadlines are EU-wide; sandboxes, certification and launch dates are national. If a public sandbox exists in your market, an early integration test is cheap insurance.
- Keep customer identity and workforce access separate. The wallet will change the first and not the second. Budget and staff them as the distinct problems they are.
- Fix today’s authentication gaps today. An SMS code that can be intercepted, or a blank approval prompt a user can be nagged into tapping, does not become acceptable while you wait for wallets. Attackers are not working to the same schedule.
See where your flows stand
The fastest way to understand the approval layer is to use it once: reading and signing a specific transaction from your own phone, the way your customers or administrators would.
Try the live demo to sign one in about two minutes, or request a demo and we will map your customer-facing SCA and internal access flows to a pilot on your own infrastructure.
This article is general information, not legal advice. eIDAS 2.0 obligations depend on your sector, size and national implementation; the implementing acts are still being extended. Confirm the deadlines and duties that apply to your organization with qualified counsel.