For years, onboarding forms ran on one habit: ask for everything now, in case it's useful later. The EU Digital Identity Wallet is built to end that habit, and in many cases the wallet itself will enforce the rule.
From principle to mechanism
Data minimization has been a GDPR principle for a long time, but it was easy to ignore because nothing stopped you from asking. A field on a form was a business decision, and the only check was an occasional audit.
The EUDI Wallet changes that. A service can't simply request data from a wallet. As a relying party, it must register in advance and state which attributes it needs, and the user sees and confirms the request. The rule moves from a policy document into the protocol.
The Commission has also said that registrars verify what relying parties declare at registration, and can restrict or cancel the registration of a relying party that requests more attributes than it registered. The “just in case” field is no longer a harmless shortcut. It is a compliance risk with a defined consequence.
What you can no longer ask for
The wallet doesn't hand over a full identity card. It is designed around selective disclosure, where the user explicitly chooses which attributes to share. In practice, several common habits become hard to defend.
01
A full date of birth to check age
If you only need to know that a user is an adult, an “age over 18” attribute answers that question without exposing the birthday, and you don’t need to store it.
02
A scan of an ID document when a single attribute would do
Identity card images, home addresses and national ID numbers are difficult to justify if the use case needs only a name or a yes/no answer.
03
Data for hypothetical future use
Because attributes must be declared at registration, “we might need it later” has to become “we need it now, for this specific purpose.” Bundled requests, asking for a large set of attributes in one step because it’s simpler to build, will no longer match what you registered. Each request has to correspond to a real need.
None of this means you can't verify your users. You verify them with less data, and with a stronger guarantee than a photo of a document that anyone could have edited.
What it looks like across sectors
The shift will look different depending on the business. Age-restricted services, such as gaming or alcohol sales, can confirm eligibility without ever learning who the user is. Online retailers can confirm that a name and delivery address belong to a real person without asking for an identity document at checkout. Financial services will still need substantial identity data for KYC, but they will have to justify each attribute, and “everything we collected before” stops being an acceptable answer. Public services can request exactly the attribute a procedure requires, such as residency or a specific qualification, instead of a full profile.
In each case the question changes from “what can we collect?” to “what is the minimum that answers the question we're actually asking?”
Who is affected, and when
Each Member State must provide at least one EUDI Wallet by 24 December 2026. From 24 December 2027, private relying parties subject to the obligation must accept it when the user asks to use it. Micro and small enterprises are excluded. Even outside that scope, an organization that chooses to use the wallet is still bound by the rules on registration, data minimization and the use of attributes.
The practical lesson is to start early. Registration requires you to declare the attributes you intend to request, which means you first need to know what you actually need. That is a product decision, not just a legal one, and it takes longer than most teams expect because the answers sit across product, legal, compliance and engineering.
Common objections
“We need the data for analytics and marketing.”
That is a different purpose from verification. If you want that data, you need a separate legal basis and a separate, honest request. You can’t carry it in on the back of an identity check.
“Our fraud team wants as much data as possible.”
Fraud prevention is a legitimate purpose, but it has to be specific. A vague wish for more signals doesn’t justify a broad attribute request, and a well-defined risk check usually needs fewer attributes than people assume.
“Our legacy systems expect the full record.”
This is the most honest objection, and the one with the real cost. It is an architecture problem, which brings us to the engineering side.
What to do now
Start with an audit of your data fields. For each field in your onboarding, KYC and checkout flows, write down the purpose and the legal basis. If you can't, it's a candidate for removal. Then look for places where you store a value only to check a condition, such as a birth date kept to confirm eligibility, and ask whether a simple yes/no claim would do. Rethink retention too: if you only need proof that a check happened, you may not need to keep the data it was based on.
Treat the registration step as a design constraint. Your declared attribute list is a public commitment, so build your integration to request that list and nothing more. And involve engineering early, because the cheapest time to change a data model is before the registration is filed.
The engineering side
Minimization can't be bolted on at the form level. It has to run through the whole system: APIs that accept claims instead of full records, services that don't pass identity data downstream by default, and integrations that check a credential and discard what they don't need. For teams running distributed systems or older platforms, that usually means revisiting data models and service boundaries, not just the front end.
At Convex, we see EUDI readiness as an architecture and integration challenge as much as a regulatory one. Organizations that build minimization into their systems now will have an easier time with the wallet than those that treat it as a form-design fix in late 2027.
Ready to ask less and verify more?
The EUDI Wallet deadlines are closer than they look, and the work of deciding which attributes you really need, and reshaping your systems around them, takes time. If you're preparing for relying party registration, or you simply want to know where your current onboarding and KYC flows would struggle, we'd be glad to look at it with you.
Book a call with Convex and let's talk through your data flows, your integration points and a realistic path to wallet readiness. The sooner you start, the more room you have to build trust into your product instead of retrofitting it under deadline pressure. You don't need to have every answer before we speak. Even a single question, like which fields you could stop collecting tomorrow, is a good place to start.
