WalletFit self-serve toolkit
EUDI Wallet Readiness Kit
A practical workbook for European businesses preparing to accept, issue, or operationalize EU Digital Identity Wallet interactions under eIDAS 2.0.
Use this kit in one working session.
The goal is not to answer every legal question. The goal is to identify where your wallet acceptance plan is already credible, where evidence is missing, and which gaps should become board-level, product, legal, security, or vendor actions this month.
How to work through it
- Run the checklist against one concrete customer journey.
- Score the ten readiness dimensions from 1 to 5.
- Turn every score below 3 into a dated action in the template.
- Re-run the scorecard after legal, product, security, and vendor owners respond.
Tip: use your browser’s print dialog and choose “Save as PDF” to create a PDF copy with your notes.
Part 1
eIDAS 2.0 compliance checklist
The checks below are distilled from WalletFit’s ARF component mapping for wallet units, relying parties, PID/EAA/QEAA providers, authentic sources, registrars, pseudonyms, certification, and incident handling.
| Done | Checkpoint | What evidence should exist | Primary mapping |
|---|---|---|---|
| □ | Define your wallet role before building. Are you a relying party, PID provider, EAA/QEAA issuer, wallet provider, public service, private obliged relying party, registrar, authentic source, or intermediary? | One-page role decision memo, affected legal entities, Member States, service journeys, and whether you accept wallet data, issue data, or operate wallet infrastructure. | ARF roles + eIDAS 5a/5b/5f/45b |
| □ | Map each wallet use case to a lawful purpose and minimum data set. Do not request PID or attributes outside the registered or disclosed use. | Journey-by-journey attribute inventory, purpose statement, legal basis, data minimization note, and user-facing explanation. | Relying party — Article 5b |
| □ | Prepare relying-party registration. Wallet-accepting services need registration data and wallet-facing authentication material before production integration. | Registration dossier with legal entity data, intended wallet uses, requested attributes, contact points, lifecycle owner, suspension/cancellation process, and certificate dependency. | CIR 2025/848 |
| □ | Design relying-party authentication to the wallet. The wallet/user must be able to identify who is requesting data and why. | Access certificate plan, registration certificate plan, metadata publication, revocation/renewal process, and validation behavior when certificates are stale or invalid. | CIR 2024/2982 + 2025/848 |
| □ | Validate PID, EAAs, and QEAAs before relying on them. Treat wallet data as high-assurance input only after issuer, status, revocation, and trust-list checks succeed. | Validation sequence diagram, trust stores, issuer eligibility rules, revocation/status checks, cache-expiry policy, audit logs, and fail-closed error handling. | PID/EAA/QEAA + LoTE |
| □ | Screen for Article 5f wallet-acceptance obligations. Some public services and private services with strong-authentication duties may need to accept wallets when users choose them. | Applicability screen covering sector, service type, Member State, user-choice design, identity requirement, fallback route, and legal conclusion. | Article 5f |
| □ | Separate identified, pseudonymous, and anonymous journeys. Do not reject pseudonyms where legal identification is not required. | Decision tree showing when full PID is needed, when a pseudonym is enough, linkability-risk review, and analytics/session handling rules. | 5a(4)(b) + 5b(9) |
| □ | If issuing attributes, classify trust level accurately. Non-qualified EAAs, QEAAs, and public-sector authentic-source EAAs carry different legal effects and evidence duties. | Attribute catalogue, issuer eligibility, source-of-truth, assurance level, disclosure policy, revocation/status model, and wording that avoids implying qualified status unless true. | 45b–45h + Annex V/VII |
| □ | If relying on authentic sources, document the source chain. QEAAs and public-source attestations require reliable verification of regulated attributes. | Authentic-source owner, legal mandate, API or verification flow, data-quality controls, logging, liability boundary, and Member State constraints. | 45e/45f + CIR 2025/1569 |
| □ | Plan cross-border identity matching. Public-sector and regulated journeys need clear matching behavior when PID comes from another Member State. | Matching data model, duplicate-resolution rules, exception handling, manual review policy, customer communications, and metrics for false matches/non-matches. | CIR 2025/846 |
| □ | Build incident and lifecycle controls around wallet dependencies. Suspension, revocation, recovery, and breach reactions must be operational, not just contractual. | Runbook for wallet outage, compromised certificate, issuer status failure, breach notification trigger, customer support scripts, and rollback/fallback pathway. | CIR 2025/847 |
| □ | For wallet providers, treat the wallet as a regulated security product. User sole control, selective disclosure, logs, pseudonyms, QES/QSeal support, accessibility, and certification evidence are core requirements. | Requirements traceability matrix, risk register, certification evidence pack, vulnerability-assessment schedule, open-source disclosure position, and CAB readiness plan. | 5a/5c/5d + CIR 2024/2981 |
Part 2
EUDI wallet acceptance readiness scorecard
Score each dimension from 1 to 5 for one named service journey. Add the scores for a maximum of 50, then use the interpretation guide to decide what happens next.
1Unknown or not started.
2Owner identified, evidence thin.
3Draft evidence exists.
4Reviewed, resourced, testable.
5Production-ready and monitored.
| # | Dimension | Question to answer honestly | Score 1–5 | Evidence / gap |
|---|---|---|---|---|
| 1 | Role clarity | Can we say exactly whether this journey makes us a relying party, issuer, wallet provider, public service, obliged private relying party, intermediary, or authentic-source dependency? | ||
| 2 | Article 5f applicability | Have legal and product owners documented whether wallet acceptance is mandatory, optional, or out of scope for this journey and Member State? | ||
| 3 | Registration readiness | Do we have the data, purposes, attributes, contacts, and lifecycle process needed for relying-party registration? | ||
| 4 | Data minimization | Are requested PID/attributes strictly limited to the service purpose, with pseudonymous or anonymous options where possible? | ||
| 5 | Technical interface plan | Have we mapped wallet protocols, presentation flows, RP authentication, status checks, fallback states, and user experience? | ||
| 6 | Trust validation | Can our system validate issuers, wallets, registration certificates, trust lists, revocation/status data, and cache expiry before relying on wallet data? | ||
| 7 | Attribute strategy | Do we know which attestations we need, who can issue them, whether they are non-qualified EAA/QEAA/public-source EAA, and what legal effect they carry? | ||
| 8 | Cross-border matching | Can we match or reconcile PID from other Member States without brittle assumptions, excessive manual work, or unacceptable false-match risk? | ||
| 9 | Operational resilience | Do support, fraud, security, legal, and engineering teams know what to do if wallet validation fails, a certificate is revoked, or a breach notice arrives? | ||
| 10 | Governance and ownership | Is there an accountable owner, decision cadence, evidence repository, vendor plan, budget, and timeline for EUDI wallet acceptance? |
Interpretation: 10–22 = exposed and exploratory; 23–34 = credible discovery but not implementation-ready; 35–43 = pilot-ready with targeted gaps; 44–50 = strong production candidate if legal sign-off and vendor dependencies are confirmed.
Part 3
Prioritized action list template
Use this section to convert low scores into concrete work. Keep every action small enough for one accountable owner to complete in one to two weeks.
P0 — Stop-the-line gap
Blocks legal sign-off, customer trust, or technical launch. Example: no relying-party registration path or no way to validate issuer status.
P1 — Pilot blocker
Does not block strategy, but prevents a controlled pilot. Example: fallback support flow or cross-border exception handling is missing.
P2 — Maturity improvement
Improves resilience, evidence quality, or operating efficiency. Example: formalizing dashboards, runbooks, or post-launch review cadence.
| # | Priority | Gap / risk | Next action | Owner | Due date | Evidence of done |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | ||||||
| 3 | ||||||
| 4 | ||||||
| 5 | ||||||
| 6 |
Suggested first three actions for most businesses: create a relying-party registration dossier, run an Article 5f applicability screen, and document a validation flow for PID/EAA/QEAA status checks before any UI work starts.
Appendix
Source map
This self-serve kit is derived from WalletFit’s internal docs/walletfit-arf-cross-reference-database-layer-1.md knowledge asset.
Layer 1 mappings used
- Regulation (EU) 2024/1183 and final eIDAS 2.0 article mapping, especially Articles 5a, 5b, 5c, 5d, 5e, 5f, and 45b–45h.
- CIR 2024/2977 for PID and electronic attestations of attributes issued to wallets.
- CIR 2024/2979 for wallet integrity, core functionality, user control, logs, privacy, and security.
- CIR 2024/2981 and CIR 2025/849 for wallet certification and certified-wallet information flows.
- CIR 2024/2982 for wallet protocols and interfaces across issuance and presentation.
- CIR 2025/846 for cross-border identity matching and CIR 2025/848 for wallet-relying-party registration.
- CIR 2025/1566, 2025/1569, 2025/2160, and 2025/2530 for identity/attribute verification, QEAAs, authentic-source attestations, non-qualified trust services, and QTSP requirements.