8. Implementation Workflow for the Wallet

8.1 Plan and Align

Implementation begins with planning. Governments define the policy goals for the wallet, decide which user groups and services will be supported in the first wave, and conduct the legal and regulatory review, including the check of local legislation described earlier. Existing assets such as national identity apps or mobile eID solutions are inventoried, decisions are taken on whether to evolve them into EUDIW‑compliant wallets or to introduce a new application.

At this stage, the national team examines the GovStack Wallet specification, the EUDIW ARF, and this guide together, and records a national wallet profile: which features will be supported, which platforms will be targeted, what local UX and language considerations apply, and where national rules require deviations or stricter behaviour.

As part of this profiling exercise, teams should also define: a supported algorithm suite, minimal and preferred credential formats, target WSCD capabilities per platform and a roadmap for introducing more advanced features (for example, wallet-to-wallet flows) once the core issuance and presentation flows are stabilised.

8.2 Design and Architecture

In the design phase, architects draw a detailed picture of how the wallet will interact with Identity, Consent, and Signature Building Blocks, trust services, and app‑store ecosystems. Data flows are mapped. Decisions are made about which tasks fall on the client, which require backend services (for example, trust‑list processing), and which remain with external systems such as QTSPs. UX design runs in parallel, defining flows for onboarding via notified eID, receiving credentials, presenting them, authorising signatures, and managing transaction history. Security and privacy requirements are integrated from the beginning rather than bolted on later.

This phase should produce: sequence diagrams for each main flow (onboarding, issuance, presentation, QES signing, device loss and recovery); interface specifications for each Building Block (URL paths, request/response schemas, error codes), a high-level deployment diagram (showing trust boundaries, networks, and external dependencies), and an initial threat model that identifies high-risk assets (keys, PID, QEAA, wallet-set certificates) and defines mitigations.

8.3 Build and Configure

Development teams then implement or adapt the wallet client. Integration with WSCDs is implemented and enforced. OpenID4VCI and OpenID4VP profiles are coded according to the ARF, and test harnesses are built to interact with example issuers and relying parties. Selective disclosure mechanisms, such as SD‑JWT or mdoc attribute requests, are wired into the consent screens. In parallel, backend components supporting the wallet—such as trust‑list fetching services, configuration servers, and anonymised telemetry collectors—are built under the constraints described in the security and unobservability sections.

8.4 Test, Certify, and Notify

Testing goes beyond basic functional checks. Protocol conformance is assessed using the official EUDIW test suites. Security testing covers client and backend code, WSCD integration and session management. Usability testing with diverse user groups checks that consent and disclosure screens are comprehensible and that error states are handled gracefully.

EUDI Wallet solutions are submitted to certification under EUCC or national schemes until EUCC is available. Results feed into eIDAS notification packages and inform communication with EU counterparts and other Member States.

8.4.1 Wallet certification

eIDAS 2.0 places a lot of emphasis on the certification of the wallet to ensure equal security for EU users. This section gives an overview of what to expect from the certification process. The detailed rules for this are in Commission Implementing Regulation (EU) 2024/2981, adopted on 28 November 2024, which lays down the rules for certification of EUDI Wallets.

The regulation is very clear that the whole wallet solution is being certified:

• the mobile app,

• the back‑end services for issuance, revocation, key management, notifications, etc.,

• secure hardware components (secure elements, secure enclaves, HSMs, smartcards, etc.) where keys and critical material are stored,

• relevant processes and services: onboarding, support, incident handling, updates, governance.

Wallets are treated as composite systems: you can reuse existing certified components (e.g. secure element with Common Criteria or EUCC certification), but you still need a top‑level “wallet solution” certificate that says the entire assembled system, as used in real life, reaches Level of Assurance High. Assurance level “High” is defined in the eIDAS implementing regulation 2015/1502 and referenced again in 2024/2981. That requirement applies to the overall wallet solution. Whilst some sub‑components may be certified at lower levels if justified, but the system as a whole has to achieve “High”.

In practice, “High” implies things like:

• strong identity proofing and binding between the real person and the digital identity;

• the wallet as an identification means must be tamper‑proof and duplication‑proof, typically via secure hardware;

• keys should be in hardware that meets Common Criteria EAL4+ (or equivalent like EUCC High, or FIPS 140‑2/3 Level ~3) for the secure element.

8.4.2 An approximate wallet certification process

Wallet certification process is a complex task and at the moment there is no national or EUCC scheme to be certified against. At the same time schemes are expected to broadly follow the Common Criteria / EUCC style of evaluation. Steps like this could be expected for the wallet provider to be followed.

1. Defining the wallet solution and scope - which products and services belong to the wallet solution: app(s), backend, secure hardware, onboarding processes, etc. and mapping them to the requirements in 2024/2981 and the Architecture & Reference Framework (ARF).

2. Identifying relevant certifications - reusing existing certifications where possible.

3. Prepare documentation - describing security objectives, threat model, architecture, cryptographic mechanisms, lifecycle, and privacy controls.

4. Certification - selecting the necessary CAB and submitting documents and product for testing.

5. Surveillance, maintenance and recertification as defined by eIDAS.

8.5 Launch and Evolution

Once tests and certifications are satisfactory, the wallet is released through app stores and other distribution channels. Early phases may concentrate on pilot groups or specific services before broader rollout. Metrics and feedback mechanisms are used to refine the application, address issues, and identify missing features.