EUDI Wallet holder binding: what a presentation really proves
The possession problem explained from primary text: what a wallet presentation proves, what ARF v3.0.0 says on User binding and the portrait, a threat table, and a risk-based step-up design for regulated teams.
In short
EUDI Wallet holder binding is the link between the person presenting a wallet and the person the identity data was issued to. The Architecture and Reference Framework (ARF) calls it User binding, and for most presentations the relying party trusts it rather than checks it.[2]
- A verified, device-bound presentation proves the data is genuine and unchanged and that the wallet holds the bound key.[2]
- It does not prove who holds the phone at your next login, payout or password reset.
- Level high is a real assurance. Keep the wallet as the default and add face checks only where the risk justifies them.
This is the possession problem. A wallet signature shows that a key was used. It takes a chain of trust to get from that key to a human being, and the last link sits on a phone you do not control.
None of that makes the wallet weak. It is issued under a scheme with assurance level high, and a team that treats it as suspect wastes it. This guide covers what it answers, what it leaves open and how to close the gap.
For registration and certificates, read our relying party guide. For the choice of integration route, read how to choose an EUDI Wallet integration platform.
What a wallet presentation actually proves
A remote presentation runs several checks in sequence. Some are yours and some happen inside the wallet where you cannot see them.
You never see step 3
Check signature and status
Check device binding
Simplified remote presentation, drawn from ARF v3.0.0 section 6.6.3. Steps 1, 2 and 4 are visible to you or to the person. Step 3 is not.[2]
| Layer | What it establishes | Who checks | Status for you | Limit |
|---|---|---|---|---|
| Issuer signature | The data comes from a genuine provider and was not changed[2] | You | Article 5b(9) puts it on relying parties, for PID and attestations[1] | Says nothing about who is presenting |
| Revocation status | The data was not revoked by its provider[2] | You | Recommended, not mandatory[3] | Only as fresh as the status source |
| Device binding | The data sits in the wallet unit it was issued to, not a copy[2] | You | Recommended, but required if you rely on the wallet's own authentication[2] | Proves a key, not a person |
| Wallet integrity | The wallet unit and its secure hardware were valid at issuance[2] | The provider of the data, during issuance[2] | You trust this indirectly[2] | You have no direct way to verify it[2] |
| User authentication | The wallet authenticated its user before releasing data[2][6] | The wallet | You trust this indirectly[2] | No result reaches you |
ARF v3.0.0 splits the regulation's wallet unit attestation into a Wallet Instance Attestation, on the app's integrity and revocation status, and a Key Attestation, on the secure storage that holds the keys.[2] On your position: "The Relying Party Instance does not have a way to directly verify the authenticity of the Wallet Unit and the Wallet Provider."[2]
Figure 12 of the ARF: the user reaches the wallet unit through an authentication link the relying party never sees. Source: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0. Not adapted.
Cover the gap the wallet leaves open
Run liveness and face match on the actions that carry real risk, in the workflow you use for verification today. Start free or talk to us.
Device binding, holder binding and the gap after them
Three different links get merged under "holder binding". The first two are ARF concepts. The third is our own label.
Key to wallet
Device binding
- Data is tied to a key in secure hardware[2]
- Also called proof of possession[2]
- Stops copying and replay[2]
Checked by you
Wallet to person
User binding
- Presenter is the person issued the data[2]
- Depends on device binding[2]
- Usually trusted, not verified[2]
Performed by the wallet
Person to action
Action binding
- This person did this later action
- Sits outside the presentation
- Lives in your session and controls
Yours alone (our term)
Device binding and User binding are ARF terms. Action binding is a Didit label, not a term from any standard.
The ARF discussion paper on device-bound attestations states the distinction in one line: "An attestation may be bound to a device but not to a User."[11] The definition that matters is this one.
Section 6.6.3.9ARF v3.0.0
"User binding (sometimes also called 'holder binding') is the property that the person that presents the PID or attestation to the Relying Party is in fact the User to whom the PID or the attestation was issued."
Source: ARF v3.0.0, chapter 6[2]
On the wire, the property you control is require_cryptographic_holder_binding in OpenID4VP. It defaults to true, and setting it to false tells the wallet you accept a credential without that proof.[12] The protocol says holder binding where the ARF says device binding.[12][2] Leave it on. Our OpenID4VP verifier guide covers the checks.
What the law and the ARF say, in their own words
These provisions govern wallet issuance and presentation, not later actions on your account.
| Rule | Text | What it means for you |
|---|---|---|
| Art. 5a(4)(a), Regulation 910/2014 | Wallets must enable users to present data "under the sole control of the user"[1] | Our reading: a requirement on how wallets are built, not a finding about any session |
| Art. 5a(5)(d) and 5a(11) | Wallets meet level high requirements and are provided under a level high scheme[1] | Strong baseline, no extra proof needed for that claim |
| Art. 5b(9) | Relying parties are responsible for "authenticating and validating" the data[1] | Signature and validity checks are yours |
| Art. 3(5), Regulation 2024/2977 | PID providers "shall ensure" that the PID they issue "is cryptographically bound to the wallet unit to which it is issued"[4] | PID providers must bind the PID to the wallet unit; you verify the result |
| Art. 3(1), Regulation 2024/2979 | No core functionality "until the wallet unit has successfully authenticated the wallet user"[6] | The wallet authenticates before acting |
| Annex, point 2.2.1, Implementing Regulation 2015/1502 | For level high, "The electronic identification means is designed so that it can be reliably protected by the person to whom it belongs against use by others."[7] | Protection against others, available to the owner |
| WIAM_14, ARF Annex 2 | Secure hardware for PID authenticates the user at level high before cryptographic operations on its critical assets[3] | A second authentication layer inside the wallet |
Section 6.5.3.3.1 of the ARF reads: "During Wallet Unit activation, the Wallet Unit ensures that the Users sets up two User authentication mechanisms." One sits at operating system level and one in the secure cryptographic hardware used when a PID is issued, presented or deleted.[2] The user has to pass both to present PID.[2]
Section 6.6.3.9 on trusting that authentication: "This trust is not based on the outcome of any verification by the Relying Party itself", but on "a-priori trust in the certified Wallet Unit and (for PIDs and attestations with a security level High) the certified WSCA/WSCD."[2] (WSCA and WSCD: the wallet's secure cryptographic application and device.) The ARF adds that relying on this method "implies that Relying Parties must verify device binding".[2]
So the ARF sets out three routes to User binding. Trust the wallet's authentication, which always runs. Compare a portrait in the PID with the live face. Or compare PID attributes with an identity document that you can verify really belongs to the person.[2]
Why level high is a real assurance
Level high requires protection "against attackers with high attack potential".[7] Certification tests that resistance.[8] A forged PID, a cloned wallet or a replayed response should fail. Our reading: level high describes the means, and says nothing about a real holder who chooses to lend or sell its use.
The ARF's Topic R working paper of 14 October 2025 records that "as of today the mobile devices have no means or basis to attest to Wallet-Relying Parties that the User authentication has been performed", and that in the opinion of some experts device biometrics "are not fully reliable".[10] It is a discussion record, not a requirement.
- 11 August 2026Portrait confirmation rulesRegulation 2026/1731 in force: warnings and explicit confirmation.
- 24 December 2026Wallets dueComputed: 24 months from the acts.
- 10 July 2027AMLR appliesArticle 22(6) binds obliged entities.
- 24 December 2027AcceptanceComputed: Article 5f(2). Private parties that must use strong user authentication by law or contract, on the user's request; micro and small firms exempt.
- 11 August 2028Portrait in PIDMandatory PID attribute from this date, subject to opt-outs.
The December dates are our computation from Articles 5a(1) and 5f(2), counted from the entry into force of the implementing acts referred to in Articles 5a(23) and 5c(6) (Regulations 2024/2977 to 2024/2982, in force on 24 December 2024).[1][4][5][13] See our EUDI Wallet deadlines guide.
The portrait: useful, optional and tightly regulated
The portrait is the obvious way to check the person. Implementing Regulation (EU) 2026/1731, adopted on 15 July 2026 and published in the Official Journal on 22 July 2026, changed its rules.
- Timing. "the wallet user's portrait may be part of the mandatory person identification data for the natural person only as of 11 August 2028".[5] Under the current PID table, the portrait is included "Except where the user explicitly opts out, where applicable".[5]
- Opt-outs remain. Member States "may provide that the user has the option to decline the insertion of the portrait", and then the value is set empty.[5]
- Wallet warning. The wallet warns that the request involves biometric data, and the user must "explicitly and specifically confirm the presentation of the portrait".[4] ARF RPA_07c adds: "Silence or a pre-ticked box SHALL NOT suffice."[3]
- Not a legal basis. Recital 2 of Regulation 2026/1731 says: "The explicit confirmation of the wallet user should be a technical safeguard and not in itself provide a legal ground for processing."[5] The recital points to Articles 6 and 9 of the GDPR for the legal basis.[5]
- Retention. The portrait "shall not be retained by wallet-relying parties unless its processing is necessary for the purposes of identification and authentication" under data protection law, or Union or national law provides for it.[4][5]
- Registration. Under Article 5b(3) you may not request data beyond what you registered, so the portrait must be in your registered use.[1]
For remote comparison the ARF asks for good lighting, clear instructions and "an approved liveness detection mechanism supporting Presentation Attacks Detection", "as well as mechanisms for injection attack detection, in particular deepfake detection".[2] ENISA details face presentation attacks.[21] ETSI TS 119 461 defines an injection attack as an "attack consisting of injecting content controlled by the attacker into the data capture process".[23]
A face check on a phone: the capture step is the attack surface. Illustration by mikemacmarketing, Wikimedia Commons, CC BY 2.0. Not adapted.
One-to-one verification whose sole purpose is to confirm a claimed identity is excluded from the AI Act's Annex III entry on remote biometric identification.[16] Biometric data used to uniquely identify a person stays special category data under GDPR Article 9, so plan a lawful basis and an impact assessment.[15]
Threat by threat: what the wallet stops and what stays with you
The certification regulation contains a risk register for wallets. Its threat identifiers below are the official ones. The last two columns are our assessment.[8]
| Threat | Register | Wallet effect | What remains | Your control |
|---|---|---|---|---|
| Copied or duplicated wallet data | TR60 | Strong: device binding[2] | Little, if you verify it | Keep the binding proof on |
| Replayed presentation | Type 5.3 | Strong: fresh signature over your data[2] | Little | Unique nonce per request |
| Stolen phone, locked | TR98 | Strong: two authentication layers[2] | Knowledge factor theft (TR35) | Check revocation status |
| Shared household device | TR35, TR98 | Partial | Someone who knows the PIN or code[22] | Step-up on high-risk actions |
| Coerced or manipulated user | TR28, TR99 | Weak: the genuine user approves | Almost all of it | Transaction monitoring, cooling-off, step-up with context |
| Cross-device relay | TR103 | Partial: proximity check[24] | Phishing of the browser session | Same-device where you can, name the action |
| Defeated local authentication | TR113 | Depends on certification[8] | Compromised device risk | Revocation check, device signals |
| Account takeover after onboarding | Outside the wallet | None unless re-presented | Passwords, sessions, recovery flows | Step-up on sensitive changes |
| Mule with a real wallet | Outside the wallet | None: all checks pass | Everything | Behaviour monitoring, network links |
The genuine user who approves
TR99 reads: "An attacker can convince a user to authenticate and approve transactions with an attacker or unauthorised third party."[8] Every factor passes. Strong customer authentication "remains effective against the fraud types it was designed to mitigate", according to the ECB, and total reported fraud across the European Economic Area was €4.2 billion in 2024.[19][20] For credit transfers, payer manipulation fraud grew "from 65% to 74% in value terms and 55% to 71% in volume terms, from 2023 to 2024".[19]
Two people, two devices
TR103: "The user behind the relying party – browser connection can be different from the user behind the relying party – wallet connection."[8] ARF section 4.4.3.2 notes that "Cross-device flows are vulnerable to phishing and relay attacks", and section 4.4.3 makes the proximity check mandatory for them.[24] Your web session still stays separate from the wallet's approval.
Figure 5 of the ARF: in a cross-device flow your service talks to a browser, and the wallet sits on a second device. Source: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0. Not adapted.
The mule with a real wallet
A person who sells access to an account, or who opens one for someone else, passes every wallet check honestly, because that person is the holder. The control is the one the Anti-Money Laundering Regulation (AMLR) already sets: "ongoing monitoring of business relationships".[13] Links between accounts, shared devices and repeated faces are the signals that expose networks.
A step-up design that keeps the wallet as the default
No text we read requires liveness on top of a wallet. AMLR Article 22(6)(b) lists, as one of its options, "the use of electronic identification means which meet the requirements of Regulation (EU) No 910/2014 with regard to the assurance levels 'substantial' or 'high'".[13] The final draft standards from the Anti-Money Laundering Authority (AMLA) say this "includes European Digital Identity Wallets", and those standards are still a draft, not law.[14] See our AMLR guide to wallet acceptance.
Article 20(2) AMLR leaves the extent of measures to "an individual analysis of the risks".[13] In our view, a selfie on every presentation is hard to justify under the GDPR principle of data minimisation.[15] These tiers are our suggestion, not legal categories.
1Classify the event
Onboarding, login, or a specific action, with its risk.
How much harm can a wrong person cause
Wallet alone
Full cryptographic checks. No biometrics.
Add liveness and face match
Against the portrait, or a face you hold lawfully.
Re-verify at the action
Fresh check tied to this action, then review.
2Record the evidence
What ran, the result, the date. Not the portrait by default.
A sample decision flow. Set your own thresholds in your risk assessment.
| Tier | Typical events | Controls | Why |
|---|---|---|---|
| Wallet alone | Age or attribute checks, standard account opening, low-risk sign-in | Signature, device binding, status, nonce | Level high does the work; less data is better |
| Wallet plus face | Higher-risk customer, unusual device or location, first use after a long gap | Above, plus liveness and face match | Answers User binding directly, as the ARF describes[2] |
| Action re-verification | New payee, large payout, changed bank details, recovery, adding a device | Fresh face check or transaction-bound approval, plus review | Binds the person to that action |
| No wallet or no portrait | Customer without a wallet, late country, portrait opted out | Document, chip reading, liveness, face match | Wallet use is voluntary[1] |
The PID cannot approve an action for you: "Wallet Units SHALL NOT use a PID private key to sign transactional data received from a Relying Party in a presentation request."[9] Transaction approval belongs to strong user authentication (SUA) attestations, which carry transactional data and sit under the ARF topic on electronic payments.[3] Payments law works the same way: the code must be "specific to the amount of the payment transaction and the payee".[18] PSD2's "any action through a remote channel which may imply a risk of payment fraud or other abuses" is a useful trigger model.[17]
Option
Wallet again
- Fresh PID presentation
- Confirms the wallet again
- No link to the action
Good for login
Option
Face check
- Liveness and face match
- Checks the person present
- Needs a lawful reference
Good for risky changes
Option
Transaction attestation
- Signs the action data
- Shows the user what is approved
- Depends on issuer support
Good for payments
Watch out
Do not use the PID key as a device identifier. Providers may issue attestations that are presented only once, to "mitigate the risk of Relying Party linkability".[2] Match returning customers on attributes, as our cross-border acceptance guide explains.
Checklist: what to do this month
The internal policy behind these steps is in our EUDI Wallet policies and controls guide, and the route decision is in the integration platform guide.
Compliance and risk
- Write down which of your events rely on the wallet alone.
- Define step-up triggers for payouts, payee changes and recovery.
- Decide your lawful basis for any face comparison.[5][15]
- Update your data protection impact assessment for portrait use.[15]
Engineering
- Keep the holder binding proof required in every request.[12]
- Verify the device binding signature on every response.[2]
- Check revocation status even though it is optional.[3]
- Tie each presentation to one session with a fresh nonce.
- Build the portrait path so that an empty value is handled.[5]
Product and support
- Request the portrait only where your registered purposes include it.[1]
- Keep a document route for people without a wallet.[1]
- Write the wording for each step-up so it names the action.
- Tell customers they can ask the wallet provider to revoke a stolen wallet.[6]
How Didit helps with the possession problem
Didit's documentation lists EUDI Wallet acceptance with the status Coming soon.[28] Our EUDI Wallet page says "There is no EUDI-specific Didit API yet" and "Integrate today, and keep it when the wallet arrives." This section covers what runs today. Biometric Authentication runs liveness and face match step-ups.
- Re-verification. Biometric Authentication verifies returning users with liveness alone, or liveness plus face match against a stored portrait, as a session in a workflow.[25][27]
- Presence. Liveness checks that a real person is in front of the camera, with passive, 3D action or flashing methods.[26]
- Step-up. Didit's Authentication documents a call that applies your step-up rules before a sensitive action and returns whether verification is required. It is new and enabled per application.[31]
- Networks. Face Search finds duplicate accounts, and Networks groups applicants that share device, IP, biometric, document or contact signals.[29][30]
- Monitoring. Transaction Monitoring screens transactions in real time against a configurable rule engine, with case management.[32]
- Fallback. ID Verification and live national eIDs serve customers without a wallet.[28]
Didit provides
- Liveness and face match on demand
- Document and national eID routes
- Duplicate and network signals
- The record of each check
Stays with you
- The risk assessment and step-up policy
- Your lawful basis and impact assessment
- Relying party registration
- Each onboarding and transaction decision
Plans and rates are on our pricing page. Stored data follows the retention you configure, and Didit acts as your processor.[33]
Design your step-up with us
Tell us which actions carry the most risk, and start with liveness and face match in your workflow.
Key takeaways
- Device binding proves a key. User binding links that key to a person, and you usually trust it rather than check it.
- Level high is a strong assurance about the wallet, and it does not cover a willing mule or a manipulated user.
- The portrait joins the mandatory PID data from 11 August 2028, subject to opt-outs, and user confirmation is not a legal basis.
- The PID cannot sign transaction data, so high-risk actions need another approval.
Frequently asked questions
What is holder binding in the EUDI Wallet?
Holder binding is the property that the person presenting the data is the person it was issued to. The ARF calls it User binding and says it is sometimes also called holder binding.[2]
What is the difference between device binding and holder binding?
Device binding ties the data to a key in the wallet's secure hardware, and it stops copying and replay. Holder binding ties the data to a person. The ARF treats device binding as a prerequisite for User binding.[2]
Is device binding mandatory for the PID?
Yes, for providers. Implementing Regulation 2024/2977 requires PID providers to ensure that the PID they issue is cryptographically bound to the wallet unit.[4] Verifying the signature is recommended for relying parties, and it is required if you rely on the wallet's own authentication.[2]
Can I do a face match against the wallet portrait?
Only if the PID has one, you registered that use, the user confirms and you have a lawful basis. The portrait joins the mandatory PID data from 11 August 2028, and Member States may let users opt out.[5]
Can I keep the portrait from a wallet presentation?
Not by default. It may be retained only if processing is necessary for identification and authentication in compliance with Union data protection law, or where Union or national law provides for it.[4][5]
Does the AMLR require liveness on top of the EUDI Wallet?
No text we read requires it. Article 22(6)(b) lists, as one option, electronic identification means that meet the requirements of Regulation 910/2014 at level substantial or high, and the extent of measures follows your individual risk analysis.[13] AMLA's final draft standards say this includes wallets, and they are not law yet.[14]
Can a wallet presentation approve a payment?
Not with the PID. The PID Rulebook forbids using the PID private key to sign transactional data.[9] The ARF expects transaction-specific approval to rely on strong user authentication attestations, which carry the transactional data.[3]
Does level high stop account takeover?
It protects the wallet, not your account. After onboarding, your passwords, sessions and recovery flows sit outside the wallet, unless you ask for a fresh presentation or another check at sensitive moments.
Can a mule pass EUDI Wallet checks?
Yes. A real holder using a real wallet passes every check, because the checks are true. The control is ongoing monitoring under Article 26 AMLR, plus links between accounts.[13]
Does Didit accept the EUDI Wallet?
Didit's documentation lists EUDI Wallet acceptance with the status Coming soon, and the solutions page says there is no EUDI-specific Didit API yet.[28] National eIDs, document verification, liveness and face match run today, and the solutions page describes the plan.
Sources
- Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183, consolidated text of 18 October 2024, EUR-Lex.
- Architecture and Reference Framework v3.0.0, chapter 6, Trust model, European Commission, 23 July 2026.
- Architecture and Reference Framework v3.0.0, Annex 2, High-Level Requirements, European Commission.
- Implementing Regulation (EU) 2024/2977, consolidated text of 11 August 2026, EUR-Lex.
- Implementing Regulation (EU) 2026/1731, EUR-Lex, Official Journal of 22 July 2026.
- Implementing Regulation (EU) 2024/2979, consolidated text of 11 August 2026, EUR-Lex.
- Implementing Regulation (EU) 2015/1502 on assurance levels, EUR-Lex.
- Implementing Regulation (EU) 2024/2981 on wallet certification, Annex I risk register, EUR-Lex.
- PID Rulebook v1.7, European Commission, 17 July 2026.
- Topic R, Authentication of the User to the device, v1.0, ARF discussion paper, 14 October 2025.
- Topic Z, Device-bound Attestations, v1.0, ARF discussion paper, 29 September 2025.
- OpenID for Verifiable Presentations 1.0, OpenID Foundation.
- Regulation (EU) 2024/1624 (AMLR), EUR-Lex, Official Journal of 19 June 2024.
- Final Report, draft RTS under Article 28(1) AMLR, AMLA, 30 September 2026 (final draft, not law).
- Regulation (EU) 2016/679 (GDPR), EUR-Lex.
- Regulation (EU) 2024/1689 (AI Act), EUR-Lex.
- Directive (EU) 2015/2366 (PSD2), EUR-Lex.
- Delegated Regulation (EU) 2018/389, EUR-Lex.
- 2025 report on payment fraud, EBA and ECB, December 2025.
- Joint EBA-ECB report on payment fraud, press release, ECB, 15 December 2025.
- Remote Identity Proofing: Attacks and Countermeasures, ENISA.
- TechDispatch on Digital Identity Wallets, European Data Protection Supervisor, December 2025.
- ETSI TS 119 461 v2.1.1, identity proofing of trust service subjects, ETSI.
- Architecture and Reference Framework v3.0.0, chapter 4, High-level architecture, European Commission.
- Biometric Authentication, Didit documentation.
- Liveness Detection, Didit documentation.
- Face Match 1:1, Didit documentation.
- Digital ID wallets, Didit documentation.
- Face Search, Didit documentation.
- Networks, Didit documentation.
- Create a step-up, Didit documentation.
- Transaction Monitoring, Didit documentation.
- Data retention, Didit documentation.
A wallet answers who a credential belongs to, and your risk work starts from that answer. For the moments that need a person, see Biometric Authentication. For wallet readiness, see our EUDI Wallet page and eID verification.
Check the person, not only the key
Add liveness and face match where your risk assessment says they belong.
Artikel terkait
- Persyaratan KYC FINTRAC untuk MSB kripto dan perusahaan pembayaran (2026)
- Law 25 Quebec dan biometrik: panduan verifikasi identitas (2026)
- EUDI Wallet integration: how to choose your route (2026 guide)
- EUDI Wallet readiness: policies and controls for regulated firms
- EUDI Wallet cross-border acceptance: one integration across the EU
- Verifikasi usia di Kanada: S-209, C-34 dan langkah yang perlu diambil sekarang