The wallet deadline nobody in Britain is planning for

Two deadlines, and almost nobody I speak to in Britain has either of them in a plan.

By the end of 2026, every EU member state must make at least one certified digital identity wallet available to its citizens, residents and businesses. The precise date falls 24 months after the core implementing acts entered into force, which lands in late December, and the European Commission itself simply says by the end of 2026. That is the supply side, and it is a government obligation rather than yours.

One year after that, by the end of 2027, obligated private sector organisations must accept that wallet when they require a customer to identify or authenticate themselves. That one is yours, and it is the date worth putting in a board pack.

The British reflex is to file this under European regulation and move on. That reflex is wrong, and expensively so, because the obligation attaches to the market you serve rather than the country you are incorporated in. If you sell to customers in the EU and you make them prove who they are, you are in scope in those markets regardless of where your office is.

What the obligation actually says

The duty to accept lands on organisations providing services where strong user authentication is legally required, and on very large online platforms. In practice that means banking and financial services, telecoms, healthcare and the platforms most people use daily. Sector by sector the detail varies, and the exemptions are real, so this is a question to put to counsel rather than to a blog post.

What matters strategically is the direction. The regulation takes a capability that has been a competitive differentiator, verified identity attributes on demand, and turns it into public infrastructure that you are required to accept. It commoditises the input.

It is not an SSO integration

This is where most technical plans go wrong. Teams look at wallet acceptance, see an authentication flow, and scope it like adding another login button. It is not that.

Three things make it different in kind.

You have to register. Relying parties are registered with a national authority, declaring which attributes they intend to request and on what legal basis. That is a compliance process with a lead time, not a developer signing up for an API key on a Tuesday afternoon.

You have to speak the standards. Not a proprietary SDK: the mobile credential formats under ISO/IEC 18013-5, W3C Verifiable Credentials, and the profile set out in the EUDI architecture and reference framework. These are genuinely interoperable, which is the point, and they are unlike anything in a typical identity stack today.

You have to ask for less. Selective disclosure is not an optional feature of this design, it is the design. The wallet hands over the specific attribute requested, and your registration constrains what you are permitted to request. Systems built on the assumption that verification yields a full identity record, which is very nearly all of them, will find that assumption failing at the interface.

That last one is the expensive part, and it is not in the identity layer at all. It is in your database, your risk models, your fraud rules, your CRM and every downstream process quietly relying on holding a date of birth. Discovering in 2027 that your onboarding pipeline cannot function without fields you are no longer entitled to collect is a very bad quarter.

A sequence that works

If I were running this, I would spend the next twelve months on four things, in this order.

Inventory the questions, not the data. For every point where you verify a customer, write down the actual question being answered. Are they over eighteen. Do they live in this country. Are they who they claim to be. Are they authorised to act for this company. You will find you are collecting far more than you need to answer them, mostly for historical reasons nobody present can explain.

Find the attribute dependencies. Trace where each collected field is used downstream. This is the piece with the longest tail and the one teams consistently underestimate, because the dependency is usually in a report, a model or an integration rather than in the onboarding code.

Prototype against the reference implementations. Open source wallet and verifier implementations exist and are testable now. The point is not to ship, it is to discover which of your assumptions break, while breaking them is free.

Start the registration conversation. Whichever market matters most to you, find out what registration involves there and how long it takes. Administrative lead time is the thing most likely to make a 2027 date slip, and it is the one part you cannot solve by adding engineers.

The strategic read

Underneath the compliance work there is a shift worth understanding, because it changes where the value sits.

Verified attributes are becoming a commodity. When any customer can produce a government-backed, cryptographically signed statement that they are over eighteen or resident in Spain, the ability to establish that fact stops being an advantage. Everyone will have it, cheaply, as a matter of law.

What does not commoditise is the harder question next to it. A wallet proves that a credential was validly issued and that whoever holds the device can unlock it. It does not prove that the authorised human is the one presenting it at this moment. That gap is where fraud will concentrate, for the straightforward reason that it is where the remaining margin is. Attack the strongest credential system in the world through a stolen unlocked phone and the credential does exactly what it was designed to do.

So the defensible position is not verification. It is confirmation at the moment of the action: proving the live human is present and is the one the credential belongs to, weighing several independent signals so that a single stolen factor is never enough, and doing it at the point where consequence actually lands rather than once at the door.

That is the work I would be investing in over the next two years. The compliance deadline is the forcing function, but the deadline is not the opportunity. The opportunity is that a great many organisations are about to have their identity assumptions rewritten by law, at the same time, and most of them have not started.