Your Login Screen Has a Legal Deadline: What the EU Digital Identity Wallet Actually Makes You Build

The Deadline That Does Not Care About Your Roadmap

Most regulatory deadlines arrive as a compliance memo and leave as a checklist item. This one arrives as a login screen, which is why it is worth paying attention to earlier than the date suggests.

Regulation (EU) 2024/1183, the amendment that turned eIDAS into what everyone now calls eIDAS 2, entered into force on 20 May 2024 and set a clock that has been running quietly ever since. The headline obligation is on member states rather than on you: each of the 27 must make at least one certified European Digital Identity Wallet available to its citizens and residents by the end of 2026. A pilot rollout with front-runner member states has been under way through this year, ahead of general availability.

The obligation that lands on private companies comes next, and it is the one that belongs in a 2027 roadmap being drafted now. Private parties that are required by law to use strong user authentication for online identification, or for whom strong authentication is a contractual obligation imposed by someone else, must accept the wallet 36 months after the technical implementing acts were adopted. Legal analyses of the timeline put that at 6 December 2027. Sixteen months from now, at the time of writing, and the integration is not the hard part.

The reason to start early is not the size of the build. It is that the wallet changes what your system is allowed to know about a user, and systems that were designed around knowing everything take longer to unpick than an OAuth client takes to configure. This has the same shape as the other European engineering deadlines of the past two years, the Cyber Resilience Act reporting obligations and the sovereignty rules: a modest amount of new code sitting on top of an uncomfortable amount of old assumptions.

Who Actually Has to Accept a Wallet

The scope question gets answered badly in most summaries, usually as some variation of banks and government. The actual population is wider and includes a lot of companies that do not think of themselves as identity-regulated.

The obligation attaches to services where strong user authentication is already legally or contractually required, which sweeps in financial services and payments, transport, energy and utilities, telecoms including SIM registration, healthcare and prescription systems, public and social security services, and the very large online platforms designated under the Digital Services Act, meaning marketplaces, app stores, search engines and social networks. Practitioner guides on acceptance scope also flag the categories that get missed in first-pass assessments: education platforms, professional services with licence verification, transport subscriptions, postal services and right-to-work checks in employment tooling.

There is a second-order effect that matters more than the direct scope for a lot of B2B software vendors. If your customer is a regulated acceptance point, their obligation propagates into your product roadmap regardless of whether the regulation names you. The bank does not build its own onboarding flow; it buys one. The telco does not write its own SIM registration front end. Every vendor sitting inside a regulated customer's identity path inherits a 2027 requirement through a contract rather than through a statute, and typically finds out about it during a procurement cycle rather than a legal review.

Worth stating plainly: acceptance means accepting the wallet as one valid method, not replacing what you have. Nobody is required to switch off passwords, passkeys or existing eID schemes. The requirement is additive, which is good news for the build and bad news for the test matrix.

The Protocol Stack You Will Be Building Against

This is where the identity provider mental model stops being useful. There is no redirect to a hosted login page that hands you back a profile. The wallet is on the user's device, it holds attestations issued by other parties, and it presents a cryptographically verifiable subset of them to you.

The binding technical specification is the Architecture and Reference Framework, maintained by the Commission's expert group and versioned aggressively, currently in the 2.x line after moving through several releases in the past year alone. Remote presentation runs on OpenID for Verifiable Presentations, issuance runs on OpenID4VCI, and credentials arrive in one of two formats that you do not get to choose between: SD-JWT VC, and ISO/IEC 18013-5 mdoc, the same format underlying mobile driving licences. The High Assurance Interoperability Profile constrains which optional features of OpenID4VP you are actually allowed to rely on, and conformance to it is mandatory rather than advisory.

The browser layer is where an otherwise clean design has already fragmented, and this is the single most useful thing to know before scoping the work. Chrome 141 and Safari 26 both shipped stable support for the W3C Digital Credentials API in September 2025, which is genuinely good news, and then diverged on what they carry. Comparisons of current browser support record that Safari 26 supports only org-iso-mdoc, while Chrome 141 supports OpenID4VP alongside ISO 18013-7 Annex C. A relying party that wants to work on both therefore needs dual-protocol verification on the backend, not a single request path with a feature flag. Firefox landed baseline code in 149 with the interface work still ongoing, and Chrome 143 opened an origin trial extending the API from presentation into issuance via navigator.credentials.create().

Add the cryptography and the shape of the work becomes clear. You are verifying issuer signatures against national trust lists, checking device binding, evaluating revocation status, and handling selective disclosure where the holder proves an attribute without revealing the underlying value. That is a verification service, and it needs the same operational seriousness as any other component that can lock out every customer in a country when a trust anchor rotates.

Registration Is an Engineering Dependency, Not a Legal Formality

Here is the requirement that reorders sprint plans, and it is buried in an implementing act that most engineering teams have never opened.

Commission Implementing Regulation (EU) 2025/848 lays down the rules for registering wallet-relying parties. Any organisation intending to rely on a wallet must register in the member state where it is established, supplying its official name, a user-friendly name shown to users at the moment of consent, and identifiers such as an EORI number, national business registration number or legal entity identifier. Registration yields the access certificates your service uses to authenticate itself to the wallet, which is a meaningful inversion of the usual arrangement: the wallet checks you before you check the user.

The consequence that catches teams out is the attribute declaration. You register the categories of data you intend to request, and the wallet is designed to enforce that boundary. In a conventional identity integration, widening a scope is a config change shipped on a Tuesday. Here, requesting an attribute you never registered is not a bug that returns an error you can patch around, it is a request the ecosystem is built to refuse, and correcting it runs through a registrar rather than a pipeline.

Design for that up front. It means product decisions about what personal data a flow needs have to be made before the integration is built rather than discovered during it, and it means the classic pattern of collecting a broad profile at signup because someone downstream might want it is not merely bad practice under the GDPR, it is now structurally unavailable. Teams used to data minimisation as a policy they document are about to meet it as a protocol that enforces itself.

There is also a jurisdictional wrinkle worth flagging early for anyone with a distributed engineering organisation. Registration happens in the member state of establishment, and the trust framework is national, so a service operating across the EU is dealing with 27 registries, 27 wallet implementations and 27 sets of national quirks layered on a common specification.

What Breaks Is Your Data Model, Not Your Auth Code

The integration effort for a competent team is measured in weeks. The changes it forces on surrounding systems are measured in quarters, and they are the reason this belongs on a roadmap now rather than in mid-2027.

Account linking is the first thing to go. A wallet presentation does not hand you a stable subject identifier the way an OIDC provider does, because a stable identifier across every service you visit is precisely the surveillance property the design exists to prevent. Pseudonymous and per-relying-party identifiers are the intended pattern, which means the assumption that a returning user can be matched by whatever the identity provider sent last time no longer holds. Systems that key a user record on an external subject claim need a migration, not a flag.

Verified attributes then collide with your existing KYC storage. If a wallet proves that a user is over 18, or resident in a given country, or holds a professional qualification, you have a cryptographic assertion valid at a point in time, not a document you filed. Do you store the proof, the derived boolean, or nothing at all? Each answer has a different retention obligation and a different audit story, and the honest answer is usually the derived boolean plus the presentation metadata, which is exactly the shape most compliance schemas were not built for.

Then there is the consent surface. Selective disclosure means the user approves a specific attribute request in the wallet interface, with your registered user-friendly name attached to it. That is a user experience you do not control, sitting in the middle of a conversion funnel you are measured on, and it is unforgiving of over-broad requests. Asking for six attributes where two would do produces a visible, itemised prompt that users decline. Data minimisation stops being an abstract principle and starts being a conversion metric.

Finally, revocation and status checking have to run on a schedule rather than at login. Attestations expire, get revoked and get reissued. A verification that was valid in March tells you nothing in September, and any workflow that treats onboarding as a one-time gate needs a re-verification story before it needs a wallet integration.

Age Verification: The Deadline Inside the Deadline

For consumer platforms, the wallet timeline is not the binding constraint. Age assurance is, and it is arriving roughly eighteen months earlier.

The Commission built a reference age verification solution, effectively a mini-wallet, precisely because the full EUDI Wallet was not going to be ready in time for Digital Services Act enforcement on minor protection. The Commission's age verification blueprint is designed to be privacy-preserving and data-minimising, initially proving only the 18-plus threshold: it confirms that a user is an adult without disclosing identity or precise date of birth, sends no data to the proof provider at the moment of use, and includes anti-tracking mechanisms so that separate presentations cannot be correlated. Ursula von der Leyen announced in Brussels on 15 April 2026 that the app was technically ready, with deployment to European phones over the summer.

Enforcement is not waiting for voluntary adoption. The Commission has opened proceedings against major adult content platforms over age verification, and the DSA minor-protection guidelines apply to a much wider set of services than most product teams assume, including any platform where adult content, gambling, alcohol or age-restricted goods are accessible.

The engineering implication is the useful part. The mini-wallet uses the same architecture, the same presentation protocols and the same relying-party registration model as the full wallet. A team that builds age assurance properly in 2026 has already built most of the verification service it needs in 2027, provided it builds a general credential verification layer rather than an age-specific endpoint. A team that ships a bespoke age check will build the same thing twice. That distinction is worth about a quarter of engineering time and it is decided in an afternoon of architecture discussion.

What the Pilots Actually Proved, and What They Did Not

There is more evidence available here than for most pre-deadline regulations, because the Commission funded four large-scale pilots starting in May 2023 and two more from the beginning of 2025, and the results are public.

The largest pilot ran with over 140 public and private partners across 19 member states plus Ukraine, testing six use cases in national and cross-border settings: eGovernment access, bank account opening, SIM registration, mobile driving licence, qualified electronic signature and ePrescription. Across the programme, more than eleven everyday use cases were exercised. Analysis of the payments findings reported that wallet-based payments could already be executed in production environments and that identity-linked payments showed strong potential for fraud reduction, which is the first genuinely commercial argument in the whole file rather than a compliance one.

The onboarding result is the one to take to a budget conversation. Customer due diligence built on verified identity data drawn from a wallet removes manual document upload, manual review and the drop-off that comes with both. If you have ever measured completion on a KYC funnel that asks a customer to photograph a passport at 11pm, you already know what removing that step is worth, and it is more than the cost of the integration.

What the pilots did not prove is uniform readiness, and this is where planning should be conservative. Member state progress varies widely, wallet implementations differ beneath a common specification, and cross-border attribute schemas remain the least settled part of the ecosystem. Build for one wallet and you will discover the others by outage. The honest planning assumption is that 2027 begins with partial, uneven coverage that improves through the year, which argues for an abstraction layer and a per-country rollout rather than a single launch date.

How to Sequence the Work

A sequence that survives contact with a real product organisation looks roughly like this, and it deliberately starts before anyone writes a verifier.

Establish scope honestly first. Determine whether you are a direct acceptance point, a vendor to one, or neither, and get that in writing rather than in an assumption. Then inventory every flow where identity or an attribute is currently proven, including the ones hidden inside support tooling and manual review queues. Most organisations find between two and five times more identity touchpoints than the initial list, and the ones nobody remembers are usually the ones with the worst data hygiene.

Build a credential verification service, not an integration. One internal boundary that accepts a presentation request, handles OpenID4VP and ISO mdoc, evaluates trust lists and revocation, and returns a verified attribute set to the rest of your estate. Everything above it, whether that is age assurance in 2026, onboarding in 2027 or professional qualification checks later, becomes a caller rather than a rebuild. Use the Commission's open-source reference implementations for issuer and verifier as a starting point rather than writing the protocol layer yourself; the specification moves too fast for a bespoke implementation to stay current cheaply.

Fix the data model in parallel and treat it as the long pole, because it is. Decide what a user identity record keys on when there is no stable external subject. Decide what a verified attribute looks like in storage, with its expiry and its provenance. Decide the re-verification cadence. This work has no dependency on any wallet existing, it can start today, and it is the part that will not compress if you leave it until 2027.

Then pilot against exactly one front-runner member state's wallet, end to end, in a non-critical flow, and instrument it properly. The purpose is not coverage, it is discovering the twenty small things a specification does not tell you.

This is the kind of work that suits a dedicated team and defeats a fixed-scope project, for a reason that has nothing to do with sales positioning: the specification is still moving. The ARF has cycled through multiple versions in a year, browser support diverged mid-flight, and national implementations will keep arriving through 2027. A team that is engaged for a three-month integration delivers against a snapshot and hands you a maintenance problem. Stepto typically staffs this as a standing dedicated engineering team that owns the verification service continuously, tracks the ARF and implementing acts as they publish, and absorbs the per-country rollout as wallets appear, which is also why being inside the European timezone and legal perimeter matters more here than on an average build. The same argument applies as with DORA third-party risk: when the regulation constrains where your data and your suppliers sit, the location of the team stops being a cost line and becomes part of the compliance answer.