The EUDI Wallet stores a range of personal data, including identity credentials, official documents, and certified attributes such as diplomas, driving licences, and health cards. The exact data depends on which documents a user chooses to add and what their Member State makes available. The wallet does not automatically share everything it holds: users stay in control of what gets shared, with whom, and when. This article walks through the most common questions organisations and individuals have about EUDI Wallet data storage, privacy, and what this means in practice.
What types of data can be stored in the EUDI Wallet?
The EUDI Wallet can store a wide variety of personal data in the form of digital documents and attestations. This includes government-issued identity data, official documents, and certified attributes from trusted issuers. The wallet is designed to be a single, secure place where users manage multiple aspects of their digital identity.
Based on the use cases tested across the large-scale pilot programmes, the following types of data can be stored in the wallet:
- Identity credentials: Name, date of birth, nationality, and other core identity attributes from national identity documents
- Travel documents: Digital travel credentials derived from passports or identity cards
- Driving licences: A mobile driving licence that can be presented both online and in person
- Health documents: The European Health Insurance Card and prescription data
- Educational credentials: Diplomas, degrees, and other certified qualifications
- Social security information: Access to benefits and relevant entitlements
- Payment credentials: Identity verification data used to authorise payments
- Organisational credentials: Proof that someone is an authorised representative of an organisation
Each of these data types is stored as an attestation from a trusted issuer that can be verified against the relevant national trusted lists, which are brought together in the EU List of Trusted Lists (LOTL). Organisations in sectors such as finance, healthcare, and government are already exploring how to work with these attestation types. For a broader look at how financial services can use digital identity, the implications extend well beyond simple login.
Who controls the personal data stored in the EUDI Wallet?
The user controls all personal data stored in the EUDI Wallet. This is one of the core principles behind the wallet design under eIDAS 2.0, which amends Regulation (EU) 910/2014 through Regulation (EU) 2024/1183. No third party, including the wallet provider, the issuing Member State, or any European institution, can access or share a user’s data without their explicit action. The user decides what to store, what to share, and with whom.
Governance of the EUDI Wallet is a shared responsibility. The European Commission manages the legal framework and adopts implementing acts that set binding requirements. Member States provide or mandate wallet solutions, certify and notify them, and supervise actors within their jurisdiction. Wallet providers, issuers of Person Identification Data and attestations, qualified trust service providers, and relying parties each carry distinct roles and obligations within that framework. No single central European authority operationally manages all EUDI Wallets.
This user-centric model is a significant shift from how identity data has traditionally been managed. In most existing systems, personal data is stored in centralised databases controlled by service providers or governments. With the EUDI Wallet, the data lives with the individual. When a service requests information, the user must actively approve that specific transaction before anything is disclosed.
Users can also keep track of which organisations have requested data and what was shared. This transparency is built into the wallet architecture through a dashboard that gives users a clear picture of their transaction history. It is a model that embeds privacy by design into the core of the system.
How does the EUDI Wallet protect stored personal data?
The EUDI Wallet protects stored personal data through a combination of cryptographic security, certified technical standards, and regulatory requirements under eIDAS 2.0. Attestations stored in the wallet are signed by their issuing authority, making them tamper-evident. The wallet itself must meet high assurance level requirements, ensuring the underlying technology is independently audited and certified by the relevant national competent authorities.
Several layers of protection work together to keep data secure. The wallet operates on the user’s device and does not rely on a central server that could become a single point of failure. Attestations are issued with digital signatures from trusted authorities. Private keys for Person Identification Data and attestations remain within the Wallet Secure Cryptographic Device and never leave it. Any attempt to alter or forge an attestation would be detectable during verification.
Verifying an attestation involves three distinct checks: first, verification of the issuer’s signature against the relevant national trusted list; second, checking the revocation status through the issuer’s status information; and third, validation of the wallet unit attestation to confirm that the presenting wallet runs on a certified wallet solution. Only the first of these checks can be performed fully offline.
The open-source reference implementation developed by the European Commission also allows public scrutiny of the code, which adds an additional layer of accountability. Member States and private wallet providers must build on these verified foundations, ensuring a consistent security baseline across all compliant wallets in Europe. The Architecture and Reference Framework (ARF) provides the technical elaboration of these requirements, while the legally binding obligations are set out in the implementing acts adopted under eIDAS 2.0.
What data does the EUDI Wallet share when used at a service?
When a user presents their EUDI Wallet at a service, only the specific data attributes that the service has requested and the user has approved are shared. Nothing more is disclosed. This selective disclosure mechanism is one of the most important privacy features of the wallet.
For example, if a service only needs to verify that a user is over 18, the wallet can share that single confirmed attribute, such as an “over 18” confirmation, without revealing the user’s full date of birth, name, or any other information. Zero-knowledge proofs are not required for this: selective disclosure of a single attribute is sufficient. If a bank needs to verify identity for account opening, the wallet can present the relevant identity attributes without exposing unrelated attestations such as health documents or educational certificates.
This approach differs from showing a physical identity document, where the recipient inevitably sees all the data printed on it. The EUDI Wallet gives users and organisations a more precise, privacy-respecting way to exchange exactly the information needed for a given interaction. For organisations working in healthcare and other sensitive sectors, this level of granularity matters considerably, particularly given the additional requirements under Article 9(2) of the GDPR for health data.
Cross-border use of the wallet operates within this same framework. A certified wallet from one Member State can be used with an appropriate relying party in another Member State. However, this does not mean that every use case is immediately available in every Member State, that national registration requirements disappear, or that sector-specific legislation ceases to apply. Which elements are interoperable at European level and which remain national or sector-specific will depend on the particular use case and the applicable legal framework in each jurisdiction.
Can organisations access EUDI Wallet data without user consent?
No. Organisations cannot access data stored in the EUDI Wallet without the wallet holder’s explicit approval of each individual request. Every data transaction requires active approval from the user. This is both a design requirement and a legal obligation under eIDAS 2.0 and the broader EU data protection framework, including the GDPR.
It is important to distinguish between two separate things: the user’s approval of a data request within the wallet, and the relying party’s legal basis for processing that data under the GDPR. Approving a request in the wallet is not the same as giving consent as a GDPR legal basis. A relying party needs its own GDPR legal basis for processing the data it receives. For identity verification in a regulated context such as banking, that basis is typically a legal obligation. For health data, an additional ground under Article 9(2) of the GDPR is also required.
Organisations that want to request data from a wallet must be registered as relying parties under CIR (EU) 2025/848, adopted on 6 May 2025. This means registering with the national authority of the Member State where the organisation is established before sending any data requests to wallet holders. As part of registration, a relying party specifies per intended use which attributes and attestations it will request. The wallet checks incoming requests against this registered scope. An unregistered organisation cannot query a wallet and receive a response. Registration requirements remain national in scope even where the underlying technical standards are harmonised at European level.
When a registered organisation sends a request, the user sees exactly what is being asked for and by whom. They can approve, decline, or share only a subset of the requested data. This structure ensures that the wallet cannot be used as a tool for organisations to collect personal data without the individual’s knowledge.
What data should organisations request from the EUDI Wallet?
Organisations should request only the minimum data necessary to fulfil a specific purpose. This is both a privacy best practice and a legal obligation under the GDPR’s data minimisation principle. Requesting more data than needed may also deter users from completing a transaction and raise compliance risks.
When designing a data request, organisations should ask themselves what specific information is genuinely required to deliver the service or meet a regulatory requirement. A good starting framework is:
- Define the purpose clearly: What decision or action does the data need to support? Identity verification, age confirmation, professional qualification, or something else?
- Map the minimum attributes: Which specific data attributes are strictly necessary for that purpose? Avoid requesting full documents when a single attribute will do.
- Check regulatory requirements: In regulated sectors such as banking or healthcare, compliance frameworks may specify which attributes must be verified. Align your request with those requirements, bearing in mind that sector-specific obligations may vary between Member States.
- Test with users: Consider how your data request will appear to a wallet holder. A clear, specific request builds trust. A broad or vague request may cause hesitation.
- Review and update regularly: As services evolve, data requirements may change. Review your request design periodically to ensure it remains proportionate.
Getting this right affects both compliance and user experience. Users are more likely to approve a data request that feels proportionate and clearly explained. Organisations that approach the EUDI Wallet thoughtfully will build more trust with their customers than those that treat it as another data collection opportunity. If you are looking for practical resources on digital identity implementation, there is a growing body of guidance available to help organisations prepare.
How the ID Connector supports organisations working with EUDI Wallet data
The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.
For organisations managing data requests from EUDI Wallets, the ID Connector handles several of the technical and trust-management tasks that sit between a wallet presentation and a verified result. Specifically, it covers:
- Wallet acceptance across Member States: The ID Connector accepts every notified EUDI Wallet, regardless of which Member State issued it or which wallet provider the user has chosen
- Verification against trusted lists: Issuer signatures are checked against the relevant national trusted lists, brought together in the EU List of Trusted Lists, so that only attestations from recognised issuers are accepted
- Revocation checking: The ID Connector checks the revocation status of attestations through the issuer’s status information as part of each verification flow
- Wallet unit attestation validation: Each presentation is checked to confirm that the wallet presenting the data runs on a certified wallet solution
- Registered attribute scope enforcement: Requests are kept within the attribute scope registered by the relying party under CIR (EU) 2025/848, so that only permitted data is requested and processed
- Qualified signing via a connected QTSP: Where a use case requires a qualified electronic signature, the ID Connector connects to a qualified trust service provider to support that flow
The legal deadline for Member States to make notified wallets available and for public-sector bodies to accept them for online services requiring electronic identification is 24 December 2026. From 24 December 2027, the acceptance obligation under Article 5f of eIDAS 2.0 extends to relevant regulated private sectors, including financial services, healthcare, telecoms, energy, transport, education, social security, and others where strong user authentication is legally or contractually required. Very large online platforms are covered by a separate provision of Article 5f, where the obligation applies where the platform requires user authentication, on the user’s voluntary request and for the minimum necessary data. Micro and small enterprises, defined as organisations with fewer than 50 employees and an annual turnover or balance sheet total of no more than ten million euros, are exempt from the private-sector obligation.
Organisations in financial services, healthcare, pharma, and government that want to be ready before those deadlines can connect through the ID Connector without building and maintaining the full verification and trust-management stack themselves. Get in touch with TrustTech to find out how the ID Connector fits your organisation’s digital identity setup.