FAQ about digital wallet

The EUDI Wallet is a government-provided app for digital certificates.
Citizens should be able to securely store, manage and present identity details such as their name or date of birth, as well as electronic certificates such as school reports or driving licences, on their smartphone. It is also designed to enable qualified digital signatures where required by the use case.

The PID is the standardised basic set of personal data for the Wallet.
It comprises the core identity data that Member States can provide for users. The PID serves as the foundation upon which further attestations are built.

EAA are digital, verifiable records of individual characteristics or attributes.
These may include, for example, qualifications, licences, address details or register information, depending on the issuer and the use case. They are stored in the wallet and presented to ‘relying parties’.

A QEAA is a qualified attribute assurance, offering a particularly high level of trust, in accordance with eIDAS 2.0.
‘Qualified’ means: stricter requirements, defined roles and a higher level of liability and trust within the ecosystem. QEAAs are intended for scenarios in which an attribute must be proven to be particularly robust.

QEAA is the qualified variant, with higher requirements and greater evidential value.
Both are digital attribute certificates, but QEAA complies with the eIDAS ‘qualified’ rules and is therefore subject to stricter verification and listing procedures. In practical terms, this means: greater standardisation, greater trust, and more formal requirements.

The issuer issues credentials, the wallet provider operates the wallet, and the relying party verifies them.
Issuers include, for example, public authorities or organisations that issue PIDs, EAA or QEAA. Relying parties are services that accept and verify credentials (e.g. banks, public authorities, platforms).

The ARF describes the common architecture, standards and interfaces of the wallet.
It is intended as an implementation guide and is continuously updated to facilitate interoperability. It does not replace the legally binding regulations and implementing acts, but complements them from a technical perspective.

Yes, the wallet is also designed for qualified signing and sealing.
This is relevant when a transaction requires not only ‘proving identity’ but also ‘legally binding signing’. Technically, the implementation depends on how signature generation and key management are handled in the wallet’s setup.

WSCA is the secure crypto wallet application (software), whilst WSCD is the associated secure device (hardware).
The idea is that cryptographic operations (e.g. key usage) take place in a secure environment. This is a key consideration in wallet certification and security requirements within the architecture.

The Business Wallet is a wallet concept designed for businesses and organisations.
It is intended for digital corporate documentation and interactions with public authorities and other businesses, particularly across borders. Important: it is not simply ‘the citizen wallet for businesses’, but addresses the specific requirements of legal entities.

It combines a corporate identity that can be used across the EU with verified attributes.
These typically include register data, licences, certificates, or information on representation and roles, which must be verified within processes. The aim is less about ‘logging in’ and more about ‘verifiable corporate status within the process’.

Both use similar principles, but are aimed at different target groups and use cases.
The EUDI Wallet focuses on natural persons and their proof of identity and attributes. Business Wallets apply wallet mechanisms to legal entities, so that corporate data can be verified in a standardised manner.

Member States are to make wallets available and roll them out by the end of 2026.
This does not mean that all use cases will be live everywhere straight away, but their availability has been clearly set as the target. Pilot projects and reference implementations are running in parallel and will inform national implementation.

Implementing acts set out specifications for EAA/QEAA, interoperability and revocation.
They specify how certificates are to be issued, verified and revoked, to ensure that this functions consistently across the EU. This applies not only to data formats but also to processes such as revocation mechanisms.

Organisations require verification, trust list checks and appropriate backend protocols.
In practical terms, this means: validating incoming certificates (signatures/binding), verifying issuer trust (e.g. via trust lists) and processing the results in an audit-proof manner. The effort involved depends heavily on whether you simply want to ‘verify’ or also ‘issue’.

A wallet is not a centralised register, but a container for verifiable credentials.
The wallet stores and displays credentials, but the truth comes from the issuer and their audit trails. The notion that ‘wallet = login app’ falls short, as it often involves attributes, roles and signature/seal functions.