Most companies hear “EUDI Wallet” and file it under government projects, something for ministries and citizens to worry about. That is only half true.
By 24 December 2026, every Member State must make at least one EUDI Wallet available to its citizens and residents, and that is a public sector milestone. In Romania, the RO Wallet is scheduled for public launch on 14 January 2027, shortly after the EU-level deadline. The part that reaches private companies comes a year later, and it arrives faster than most roadmaps assume.
On 24 December 2027, private organizations required by law or by contract to use strong user authentication must accept the wallet whenever a user chooses to present it. If your company falls into that group, or sells to companies that do, the question is not whether the wallet will touch your systems but how prepared you are when it does.
Here are five questions that show where you actually stand.
01
Do you know whether you are a “relying party” with an acceptance obligation?
In EUDI terms, a relying party is any organization that asks users to prove who they are or to share verified attributes. That covers onboarding, login, KYC checks, age verification and contract signing. The acceptance obligation is triggered by the authentication requirement, not by the sector you operate in, and it can come from a contract with a business partner as well as from the law. Micro and small enterprises are excluded, but if you are larger, or you serve clients who impose strong authentication on their suppliers, you are likely in scope. Start by listing every place in your product and operations where you verify identity today. Many teams discover that the list is longer than expected and spread across several systems.
02
Do you know which user data you actually need?
The wallet is built around selective disclosure. A user can prove they are over 18 without handing over a birth date, or confirm a degree without sharing a full record. Relying parties must not request more data than the specific service needs, and the rules for registering relying parties apply from 24 December 2026, which means declaring the purpose and the data you request. That makes data minimization a design requirement rather than a legal footnote. If your current onboarding form collects everything “just in case,” this is the moment to map each attribute to a real purpose and legal basis.
03
Can your architecture handle a new identity channel?
This is where readiness is usually won or lost. Accepting the wallet means integrating with a new trust framework: verifying credentials, checking their validity, handling different assurance levels and exchanging data over standard protocols. In a modern architecture this sits behind a clean identity service. In a legacy one, authentication logic is often scattered across monoliths, custom login flows and third-party plugins, and adding a new channel means touching all of them. A quick test is to ask how long it would take your team to add one more authentication method. If the honest answer is “months,” the wallet will expose that problem sooner or later.
04
Are your compliance, security and engineering teams working together?
EUDI readiness is not a purely technical project, and it is not purely legal either. Someone has to interpret the regulation, someone has to design the integration, and someone has to own the data protection impact. When these groups work in sequence instead of together, projects stall at handoffs. The companies moving fastest tend to have a single owner for digital identity who can translate between legal requirements and engineering tasks. If nobody in your organization holds that role yet, naming one is a cheap first step with a large payoff.
05
Have you tested anything yet?
Reading about the wallet and running it are very different experiences. Large-scale pilots across Europe have already produced reference implementations and open specifications, and organizations that took part in those pilots have a significant head start. You do not need a production rollout to begin. A small proof of concept that accepts a wallet credential for one real use case, such as customer onboarding or age verification, will teach you more about your gaps than another round of planning documents. It also gives you a realistic estimate of effort, which is what leadership needs for budgeting.
How to read your answers
If you could answer most of these confidently, you are ahead of the majority of the market and can focus on refining and piloting. If you hesitated on several, that is normal, and it is also useful. Each hesitation points to a concrete piece of work, whether that is an identity inventory, a data-minimization review, an architecture refactor or a first pilot. The acceptance deadline of 24 December 2027 is more than a year away, but integration work rarely takes less than that once it meets procurement, security review and release cycles.
Talk to Convex before the deadline talks to you
If these five questions raised more questions than answers, that is a good moment to talk. Most companies we speak with are in the same place: they know the wallet is coming, but they are not yet sure which of their systems it affects, what the law requires from them, or where to begin. Convex builds and integrates identity solutions for enterprise systems, from distributed backends to Kubernetes-based platforms, and we are happy to look at your situation with you. In one conversation we can help you see which obligations apply, where the wallet would fit into your architecture, and what a realistic first pilot could look like.
Book a call with Convex, and let's turn the checklist into a plan.
