EUDI Wallet Onboarding

Skip key takeaways

Updated September 4, 2026

• Five fields guaranteed, fourteen optional Table 1 of the Annex to CIR (EU) 2024/2977 fixes family_name, given_name, birth_date, birth_place and nationality as mandatory while Table 2 marks fourteen further fields optional, so a photograph, an address, an email address and a phone number are all data that may never arrive
• Mandatory means present, never means true A Member State that does not know an attribute value substitutes one appropriate to the situation, and the sources read for this article describe no flag that would distinguish the substitute from a real value, so every mandatory field needs a branch that treats a populated value as unverified
• One guaranteed field arrives at two granularities Birth place may be an ISO 3166-1 alpha-2 country code or a municipality name, with a list of administrative units offered in between and no rule saying which an issuer picks, so a parser assuming a city string breaks on the first Member State that issues a code and any cross-level comparison silently fails
• Your maximum request is public, your minimum is yours alone Member States publish the registration information online in a form suitable for automated processing, so the widest attribute set your verifier may legitimately ask for is readable by anyone who looks it up, while narrowing any individual request below that ceiling is a selective-disclosure decision that stays entirely inside your own code
• No acceptance duty reaches a firm by sector Article 5f binds Member States for public services, private relying parties already required by Union or national law or by contractual obligation to use strong user authentication and providers of very large online platforms, and the sector list attached to the second category is introduced by the word including, so it illustrates rather than defines who is caught

Copy takeaways

A wallet-presented identity reaches your onboarding endpoint as a signed, Member-State-issued data set. The temptation is to read that sentence as a solved problem and to scope the remaining work as parsing. What actually arrives is smaller than most product plans assume, and two of its properties will change your data model before they change your UI.

What follows is a walk through person identification data as the implementing regulation defines it: which fields you are guaranteed to receive, what a guaranteed field is actually worth, and which obligations move onto you the moment you decide to consume one.

The acceptance position, stated first

The duty and the mechanism get conflated routinely, so take the duty first. Regulation (EU) 2024/1183 inserts a new Article 5f into the eIDAS framework, and that one article carries the whole acceptance position in three duties. The first binds Member States for their own online services: "Where Member States require electronic identification and authentication to access an online service provided by a public sector body, they shall also accept European Digital Identity Wallets that are provided in accordance with this Regulation." (Regulation (EU) 2024/1183, Article 5f(1))

A second duty reaches private business and is conditional twice over. It opens by carving out the smallest firms: "Where private relying parties that provide services, with the exception of microenterprises and small enterprises as defined in Article 2 of the Annex to Commission Recommendation 2003/361/EC" (Regulation (EU) 2024/1183, Article 5f(2)) It then states the actual trigger, which applies where those parties "are required by Union or national law to use strong user authentication for online identification or where strong user authentication for online identification is required by contractual obligation, including in the areas of transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education or telecommunications" (Regulation (EU) 2024/1183, Article 5f(2))

Sector membership triggers nothing by itself. The word including makes that list illustrative, and the operative condition is a pre-existing strong-authentication requirement, in Union or national law or in contract.

The private-sector duty runs on a period and on a request

Timing arrives as a span measured from an event. The obligation clause reads "those private relying parties shall, no later than 36 months from the date of entry into force of the implementing acts referred to in Article 5a(23) and Article 5c(6) and only upon the voluntary request of the user, also accept European Digital Identity Wallets that are provided in accordance with this Regulation." (Regulation (EU) 2024/1183, Article 5f(2)) That is a period running from an implementing-act event, so there is no calendar date to put on a roadmap. The clause carries its own brake as well, since the duty bites only where a user asks.

The third duty drops the strong-authentication condition but lands on a narrow class, providers of very large online platforms as referred to in the Digital Services Act. Where those platforms "require user authentication for access to online services, they shall also accept and facilitate the use of European Digital Identity Wallets that are provided in accordance with this Regulation for user authentication only upon the voluntary request of the user and in respect of the minimum data necessary for the specific online service for which authentication is requested." (Regulation (EU) 2024/1183, Article 5f(3))

Your own coverage is a separate legal question

Whether your own firm sits inside the second duty turns on a separate legal question, and the provision states it in two limbs. Strong user authentication for online identification may be required of you by Union or national law, or by a contractual obligation you have already signed. Either limb puts you inside the test, so a firm that finds no statute pointing at it has done half the check. This article answers neither half, and no sector is placed in scope by name. The recital behind the provision confirms as much, placing those sectors behind the words "for example in the areas of transport, energy, banking and financial services" (Regulation (EU) 2024/1183, recital 56).

What the framework says about the user sits in a recital rather than in an enacting article, and it is written in the language of a recommendation: "Users should be under no obligation to use a European Digital Identity Wallet to access private services and should not be restricted or hindered in their access to services on the grounds that they do not use a European Digital Identity Wallet." (Regulation (EU) 2024/1183, recital 57) A recital records the reasoning behind the enacting terms. Read it as a strong steer to keep your existing route open alongside a wallet lane, not as a prohibition you could hold someone to.

What person identification data actually contains

Commission Implementing Regulation (EU) 2024/2977 is the instrument that says what person identification data is made of, and its Annex is the payload. It defines the consuming role in wallet terms and covers private services explicitly (CIR (EU) 2024/2977, Article 2, point (11)).

Table 1 of that Annex is headed "Mandatory person identification data for the natural person" (CIR (EU) 2024/2977, Annex, Table 1) and it carries five identifiers: family_name, given_name, birth_date, birth_place and nationality. That is your guaranteed surface.

Everything past those five is a design assumption. Table 2 is headed "Optional person identification data for the natural person" (CIR (EU) 2024/2977, Annex, Table 2) and holds fourteen entries: resident_address, resident_country, resident_state, resident_city, resident_postal_code, resident_street, resident_house_number, personal_administrative_number, portrait, family_name_birth, given_name_birth, sex, email_address and mobile_phone_number. A photograph, a postal address, an email address and a phone number all sit in that second table, which means a flow designed around any of them is designed around data that may never arrive.

A mandatory field promises presence, not meaning

A note under Table 1 changes what the five guaranteed keys are worth: "Where an attribute value is not known for the person or cannot otherwise be issued as part of the person identification dataset, Member States shall use an attribute value appropriate to the situation instead." (CIR (EU) 2024/2977, Annex, note under Table 1)

Read that against a schema. The field is populated because the regulation requires the field, not because the issuing Member State knows the answer. A validator treating a non-empty birth_place as evidence about where someone was born is reading presence as truth. Two engineering consequences follow. Every mandatory field needs a branch for a substituted value, and a substituted value is indistinguishable from a real one at the wire format, because the sources read for this article describe no flag that would mark one.

This bites hardest where mandatory fields feed a match. A deduplication key built from family_name plus birth_date plus birth_place inherits the substitution, so two customers whose Member States substituted the same appropriate value collide on a key you believed was an identity. Score those matches instead of trusting them, and keep a manual path for the collision.

Granularity varies inside the guaranteed set

A field you can rely on receiving still arrives in more than one shape. The Annex defines birth_place as "The country as an alpha-2 country code as specified in ISO 3166-1, or the state, province, district, or local area or the municipality, city, town, or village where the user to whom the person identification data relates was born." (CIR (EU) 2024/2977, Annex, Table 1, birth_place)

One field, two granularities. The definition runs from a country code through a list of administrative units and stops at a village, and it never says which rung an issuer will pick. A column typed as a city name takes a two-character country code from the first Member State that issues one. A geocoder pointed at it returns a country centroid for some users and a municipality or a village for others. Length validation demanding more than two characters rejects a conformant value.

Store it opaque and compare it carefully

Keep birth_place as an opaque string, detect the alpha-2 form as an explicit special case and never derive a comparison that assumes both sides sit at the same administrative level. The same caution applies to any downstream screening list keyed on place of birth, because a country code and a village name will not match each other even when they describe the same person.

The obligations that move onto you

Consuming wallet data puts you in a regulated role before it puts you in an engineering one. Article 5b, inserted into the eIDAS framework by the same amending Regulation, requires a relying party that intends to use wallets to register in its Member State of establishment, and requires that filing to indicate the data it will ask users for. This site covers that track in EUDI Wallet relying party registration. One consequence of it reaches into the matrix below.

The declared list is a ceiling rather than an opening position. "Relying parties shall not request users to provide any data other than that indicated pursuant to paragraph 2, point (c)." (Regulation (EU) 2024/1183, Article 5b(3)) So the request your verifier emits derives from a filing rather than a sprint decision, and that filing is on the record: "Member States shall make the information referred to in paragraph 2 publicly available online in electronically signed or sealed form suitable for automated processing." (Regulation (EU) 2024/1183, Article 5b(5))

Narrowing is the direction that stays open. A wallet is specified to hold and present identity data "while ensuring that selective disclosure of data is possible" (Regulation (EU) 2024/1183, Article 5a(4), point (a)), so a registered set is a maximum and never a minimum, and every individual request is separately bounded by necessity, proportionality and data minimization (Regulation (EU) 2024/1183, recital 56).

Verification is yours, and identification is not always permitted

The wallet authenticates its holder to you, and it checks nothing on your behalf. Article 5b(9) puts two duties into two sentences, both of them quoted in full in the registration article linked above (Regulation (EU) 2024/1183, Article 5b(9)). The first makes the relying party responsible for authenticating and validating the person identification data and the attestations it requested, which is the signature, trust-chain and status work covered here in EUDI Wallet verifier and OpenID4VP implementation.

The second duty is easier to miss. A relying party may not refuse the use of pseudonyms where identification of the user is not required by Union or national law, which turns identification into a permission some other instrument has to grant. The wallet does not grant it, and an onboarding flow that identifies every user by default has assumed a permission nobody checked.

Identification also runs in both directions. "Where relying parties intend to rely upon European Digital Identity Wallets, they shall identify themselves to the user." (Regulation (EU) 2024/1183, Article 5b(8))

What the issuing side already did

The reason a wallet presentation outranks a typed form sits at the issuing end. Wallets are provided under an electronic identification scheme at assurance level high (Regulation (EU) 2024/1183, Article 5a(11)), the top of the three eIDAS levels, and the implementing regulation specifies the enrollment sitting behind it. "Member States shall enroll wallet users in accordance with the requirements relating to enrolment at assurance level high, as set out in Commission Implementing Regulation (EU) 2015/1502" (CIR (EU) 2024/2977, Article 3(7), first sentence)

The proofing happens before anything reaches the wallet: "In the context of the enrolment process, providers of person identification data shall perform identity verification of the wallet user in accordance with the requirements related to identity proofing and verification before issuing the person identification data to the wallet unit of the corresponding wallet user." (CIR (EU) 2024/2977, Article 3(7), second sentence)

That is a real assurance, and it is an assurance about the issuance event. It records that a Member State proofed the person at enrollment. It says nothing about your own obligations, and nothing read for this article speaks to customer due diligence. This site covers that ground separately in MiCA KYC.

Binding and revocation keep the presentation tied to a live fact

The data is bound to the device holding it: "Providers of person identification data shall ensure that person identification data that they issue is cryptographically bound to the wallet unit to which it is issued." (CIR (EU) 2024/2977, Article 3(5)) A copied payload does not present.

Validity is a moving state. "Providers of person identification data issued to a wallet unit shall ensure that revocations cannot be reverted." (CIR (EU) 2024/2977, Article 5(5)) The place to look for it travels inside the payload, because providers must publish status and "they shall make publicly available the validity status of person identification data they issue, in a privacy preserving manner, and indicate the location of that information in the person identification data." (CIR (EU) 2024/2977, Article 5(7))

For an onboarding flow that means a status check at presentation time and a deliberate decision about re-checking afterwards. Discovery is not an integration problem, since the pointer arrives with the data. A revoked record never returns to valid, so a cached positive is safe against reversal but not against a revocation that happened after you cached it. Where you retain person identification data after onboarding, the controller-side questions are covered in EUDI Wallet data deletion requests.

A readiness matrix for the fields

Each fact above lands on a different field, which is what makes them hard to hold at once.

Person identification data readiness matrix. Columns one to three come from Table 1, Table 2 and the substitute-value note in the Annex to CIR (EU) 2024/2977. Column four is this article's own recommendation, not a regulatory requirement. Presence in the issued set is not arrival at your endpoint, which your registered set and selective disclosure bound.

Field	In the issued data set	Value guarantee	What the flow must handle
family_name	Always present	May be a substituted value	Score name matches, never assert them
given_name	Always present	May be a substituted value	Score name matches, never assert them
birth_date	Always present	May be a substituted value	Parseable, but not evidence of a birth date
birth_place	Always present	Alpha-2 country code or a place name at any level, equally substitutable	Opaque storage, explicit alpha-2 branch, no cross-level comparison
nationality	Always present	May be a substituted value	Populated, possibly not describing the person
portrait	Optional	Absent unless issued	No face match on the critical path
resident_address and its six components	Optional	Absent unless issued	Separate address collection, no wallet-derived geography
personal_administrative_number	Optional	Absent unless issued	No national identifier as a primary key
email_address	Optional	Absent unless issued	Separate capture and verification
mobile_phone_number	Optional	Absent unless issued	Separate capture and verification
family_name_birth, given_name_birth, sex	Optional	Absent unless issued	No logic that requires them

What the matrix changes about the flow you build

Read the third column downwards and the shape of a wallet-fed onboarding flow appears. Identity resolution runs on five fields, every one of which may carry a substituted value and one of which may also be a country code. Every contact channel, every address and every image stays a separate collection step outside the wallet. The wallet does not remove your existing collection screens, it replaces the part of them that asks for a name and a birth date.

Cost lands on one side of the line. The amending Regulation settles the wallet itself. "The issuance, use and revocation of the European Digital Identity Wallets shall be free of charge to all natural persons." (Regulation (EU) 2024/1183, Article 5a(13)) That makes the wallet free to the person holding it, and it says nothing about anything else a service may charge for. The planning consequence is narrower than it first looks. No wallet fee exists for you to recover an integration against, so a business case resting on wallet adoption has to find its saving somewhere other than a charge for the wallet.

Strong user authentication counts factors, not identities

One boundary is worth restating because the term invites the wrong inference. Strong user authentication, as the amending Regulation defines it, "means an authentication based on the use of at least two authentication factors from different categories of either knowledge, something only the user knows, possession, something only the user possesses or inherence, something the user is, that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data" (Regulation (EU) 2024/1183, Article 3, point (51)). Satisfying that definition establishes how many independent factors were used, and it establishes nothing about whether a customer has been identified. Payments law runs a separate term, strong customer authentication, on its own rules. EUDI Wallet and strong customer authentication covers that one, including the wallet-presented SCA Attestation and the order a payment service processes it in.

FAQ

Last updated: September 4, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 5

• ★ Featured question. Can we add one more attribute to the request after go-live?

  Copy link Copies a direct link to this answer to your clipboard.

  Not without amending the registration. The data a relying party may request is declared in its registration filing, and the regulation prohibits requesting anything outside that declared list, so a new form field is a change to a register entry before it is a sprint task.

  Asking for fewer attributes than you registered stays available, so register the full set you expect to need and narrow the request per use case in code.

• What happens if a customer declines to use a wallet?

  Copy link Copies a direct link to this answer to your clipboard.

  You keep your existing route open. Recital 57 says users should be under no obligation to use a wallet to access private services and should not be restricted or hindered on the grounds that they do not use one.

  That sits in a recital rather than in an enacting article, so it records the reasoning behind the enacting terms instead of stating a prohibition of its own. It is still the clearest statement of intent the framework offers on the point, and a flow that makes wallet presentation the only way in runs straight against it, so scope the wallet lane as an addition to the form lane you already operate.

• Do we have to re-check validity after onboarding, or is one check enough?

  Copy link Copies a direct link to this answer to your clipboard.

  That is your decision, and the data set makes it a cheap one either way. Providers of person identification data publish validity status in a privacy preserving manner and indicate where that status lives inside the data itself, so you never have to discover an endpoint out of band.

  Revocations cannot be reverted, which means a positive result you cached can only be invalidated by a later revocation and never contradicted by a reversal.

• Does the wallet cost our customers anything?

  Copy link Copies a direct link to this answer to your clipboard.

  Not the wallet itself. Issuance, use and revocation of the wallet are free of charge to all natural persons, which settles the wallet and says nothing about what else a service may charge for.

  For planning, the point is that no wallet fee exists to recover your integration against, while registration, certificate handling, verifier engineering and the status checking above all still have to be paid for.

• Is the person identification data set the same as an electronic attestation of attributes?

  Copy link Copies a direct link to this answer to your clipboard.

  They are different objects and the regulation treats them separately. Person identification data is the Member-State-issued identity set defined in the Annex to the implementing regulation, with its five mandatory and fourteen optional fields.

  An electronic attestation of attributes is a separate credential a wallet may hold alongside it, and the relying-party duty to authenticate and validate what comes back is written to cover both.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.