Architecture GuideEU

EU eIDAS EUDI Wallet Architecture

Turn the ARF and wallet implementing regulations into implementable components, flows, boundaries, keys, logs, and testable controls.

Designed for relying parties, wallet providers, and teams building verifiers and attribute pipelines.

Back to main artifactReview sources
Author
Sorena AI
Published
Feb 21, 2026
Updated
Feb 21, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published Feb 21, 2026
Updated Feb 21, 2026
Overview

The EUDI Wallet is an ecosystem: wallet software on user devices, issuance of person-identification data and attributes, verification by relying parties, and shared trust infrastructure. A working architecture must be secure, privacy-preserving, interoperable, and operationally supportable. Use this page as a technical blueprint that maps the amended eIDAS text, the ARF, and the five wallet implementing regulations into components, data flows, trust anchors, and prove-it-works controls.

Section 1

Ecosystem actors (architectural boundaries you must model)

Start by identifying actors and responsibilities. Most architecture failures come from fuzzy ownership across product, identity, and compliance teams.

eIDAS defines roles including relying parties and providers of European Digital Identity Wallets, and introduces wallet-specific obligations and capabilities.

  • Wallet provider: delivers and operates the wallet solution and its security lifecycle, including updates, revocation or suspension, and incident handling.
  • Issuers: issue person-identification data and electronic attestations of attributes, whether qualified or non-qualified.
  • Relying parties or verifiers: request and verify wallet-based claims and enforce data minimization, logging, and user transparency.
  • Conformity assessment and supervision: certification, notification, and oversight expectations influence your evidence model and release process.
Section 2

Core functional flows (the minimum set you should implement)

Architect the wallet capability around a small set of canonical flows, then enforce consistency and testability across products and channels.

The implementing regulations adopted in late 2024 define the common technical floor for core functionalities, interfaces, PID and attributes, certification, and ecosystem notifications.

  • Authentication flow: wallet-based authentication to relying parties with strong integrity and replay protections.
  • Attribute presentation flow: user shares electronic attestations of attributes with explicit disclosure and only the data necessary for the transaction.
  • Wallet-to-wallet or delegated verification patterns: only where the use case requires it and where trust boundaries are explicit.
  • User transparency flow: user accesses a log of wallet transactions or disclosures through a common dashboard for accountability and dispute handling.
Section 3

Trust model: keys, trust anchors, and verification pipeline

Interoperability is a trust problem. Define how relying parties validate authenticity, integrity, and validity of wallets and presented claims.

Implement verification as a deterministic pipeline with explicit decisions and logs (pass/fail/retry, reason codes).

  • Trust anchors: define authoritative sources for issuer keys, wallet authenticity, and certification status.
  • Signature verification: validate signatures on presented attestations and wallet assertions and handle algorithm agility and versioning.
  • Revocation and status: implement status checks and safe failure modes when status information is unavailable.
  • Decision logging: store verification outcomes, versions, and trust decisions without retaining unnecessary attribute values.
Section 4

Privacy-by-design architecture (what to enforce at system boundaries)

Wallet ecosystems can accidentally create "surveillance by design" if you collect and link wallet usage data across services.

Build privacy controls into your data plane: schemas, retention rules, and logging policies are architecture decisions.

  • Data minimization: enforce minimal-attribute requests and block expansions without explicit justification.
  • Separation of concerns: keep wallet usage telemetry logically separate from other business analytics unless the user explicitly consents and it's necessary.
  • Selective disclosure patterns: design APIs to request only what is necessary and to avoid "full credential disclosure" defaults.
  • Deletion and retention: implement deletion workflows and prove they work with tests and periodic audits.
Section 5

Security controls (make them testable)

A wallet verifier is a high-value target. Implement hard controls and prove them with tests and monitoring.

Your goal is not just security posture - it's demonstrable, repeatable resilience.

  • Threat model focus: phishing, credential replay, issuer compromise, verifier endpoint abuse, and downgrade attacks.
  • Secure update process: handle issuer key rotations and spec changes without breaking verification determinism.
  • Strong audit logging: tamper resistance, clear retention rules, and access controls aligned to least privilege.
  • Operational monitoring: error budgets for verification failures, revocation check outages, and unusual claim patterns.
Section 6

Interoperability and conformance strategy (how to avoid "demo-only" integrations)

Wallet ecosystems only work when implementations interoperate across Member States and vendors. Treat interoperability as a continuous program with contract tests and conformance gates.

Use the ARF, the Commission implementing regulations, and your supported issuer or wallet matrix as the backbone for shared assumptions.

  • Canonical test suite: cover multi-issuer scenarios, multiple wallets, revoked or expired credentials, and partial disclosure edge cases.
  • Spec version management: version your verifier logic and record which ARF or implementing-regulation assumptions each verification used.
  • Release gating: ship verifier changes only when interoperability tests pass across the supported set.
  • Evidence: keep conformance and interoperability test logs as audit-ready artifacts.
Recommended next step

Keep EU eIDAS EUDI Wallet Architecture in one governed evidence system

SSOT can take EU eIDAS EUDI Wallet Architecture from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Evidence system
Open SSOT for EU eIDAS EUDI Wallet Architecture

Start from EU eIDAS EUDI Wallet Architecture and keep documents, evidence, and control records in one governed system.

Explore next step
Talk to Sorena
Talk through EU eIDAS

Review your current process, evidence gaps, and next steps for EU eIDAS EUDI Wallet Architecture.

Explore next step
Primary sources

References and citations

Related guides

Explore more topics

eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan
An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment.
eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties
A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes.
eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?
A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer).
eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation
A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates.
eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs
A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index.
eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence
An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels.
eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence
A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls.
eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines
High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain.
eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction
A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services.
eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping
An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties.
eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)
A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect.
Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation
A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing.
EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack
A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows.
Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence
A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter.
What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties
A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes.