TRUSTTECH / BLOG

What documents can you store in the EUDI Wallet?

Smartphone on white desk surrounded by physical identity documents including passport, driver's license, health insurance card, and diploma in flat lay arrangement.

The EUDI Wallet can store a wide range of digital documents, from government-issued identity credentials to sector-specific documents like diplomas, driving licences, prescriptions, and travel documents. The exact set of supported documents is defined by eIDAS 2.0, which amends Regulation (EU) 910/2014, and by the technical standards elaborated in the Architecture and Reference Framework (ARF) and the legally binding implementing acts. This article walks through the most important questions organisations have about EUDI Wallet documents and what they need to do to get ready.

Which documents are officially supported in the EUDI Wallet?

The EUDI Wallet officially supports a broad range of digital documents, grouped into identity credentials and sector-specific attestations. At its core, every wallet will contain a Person Identification Data (PID) credential, which is the digital equivalent of a national identity document. Beyond that, the wallet is designed to hold many types of verified digital documents that citizens and organisations use in daily life.

The large-scale pilot programmes that tested the wallet across Europe identified key use cases illustrating the range of supported documents:

  • National digital identity (PID)
  • Mobile driving licence
  • Educational credentials such as diplomas and certificates
  • Travel documents including passport data
  • European Health Insurance Card (EHIC)
  • Social security documents and benefit access
  • SIM card registration proof
  • Organisational identity credentials (proof of representing a business)
  • Payment authorisation credentials
  • Medical prescriptions
  • Documents for accessing government services

This list is not exhaustive. The wallet is built as an open ecosystem, meaning new document types can be added as standards mature and as public and private sector organisations become accredited issuers.

What is the difference between a PID, QEAA, PuB-EAA, and non-qualified EAA?

In the EUDI Wallet framework, attestations are classified into distinct categories based on their level of trust and who issues them. A PID (Person Identification Data) is the foundational identity credential issued by a government authority, confirming who you are. A QEAA (Qualified Electronic Attestation of Attributes) is a high-assurance attestation issued by a Qualified Trust Service Provider (QTSP) supervised under eIDAS 2.0. A PuB-EAA (Public Body Electronic Attestation of Attributes) is issued by or on behalf of a public body and sits in its own category, distinct from non-qualified EAAs. A non-qualified EAA (Electronic Attestation of Attributes) is a broader category covering digitally verifiable attestations issued by a recognised party, without the strict qualified or public-body status of the categories above.

Think of it as a trust hierarchy. The PID sits at the top because it is issued by a government authority and forms the anchor of your digital identity. QEAAs carry a high level of legal and technical assurance and are issued by QTSPs that are supervised under eIDAS 2.0. PuB-EAAs are issued by or under the responsibility of a public body. Non-qualified EAAs are more flexible and can be issued by a wider range of organisations, but they carry less regulatory weight.

For organisations deciding which type of attestation to issue or accept, this distinction matters significantly. A bank conducting customer due diligence may require a PID or QEAA, while an online platform verifying a professional certification might accept a non-qualified EAA. Understanding these categories helps organisations design their acceptance policies and plan their own attestation issuance strategy.

Can sector-specific documents like diplomas or prescriptions be stored?

Yes, sector-specific documents like diplomas, prescriptions, professional licences, and insurance cards can be stored in the EUDI Wallet as electronic attestations of attributes. Depending on the issuer and the applicable trust framework, these may take the form of QEAAs, PuB-EAAs, or non-qualified EAAs. These attestations are issued by the relevant authority in each sector and then added to the wallet as verifiable credentials that the user can share selectively.

The pilot programmes demonstrated this in practice. In the education sector, the DC4EU pilot tested how universities and awarding bodies could issue digital diplomas and certificates that students carry in their wallet and present to employers or other institutions. In healthcare, the POTENTIAL pilot tested storing prescription data that patients can present at a pharmacy, as well as the European Health Insurance Card for cross-border healthcare access.

For organisations in regulated sectors, this opens up significant opportunities. A healthcare provider can issue prescription attestations directly into a patient’s wallet. A university can issue a verifiable degree certificate. An employer can verify professional qualifications without needing to contact the issuing institution each time, though it is worth noting that the credential remains tamper-evident rather than absolutely immutable. Sector-specific legislation and national registration requirements continue to apply. The wallet framework does not remove those obligations, and the legal effect of a given attestation may still vary depending on the jurisdiction and sector in which it is presented. Recognition of professional qualifications, for example, continues to be governed by Directive 2005/36/EC.

How does an organisation become an issuer of wallet documents?

To become an issuer of EUDI Wallet attestations, an organisation must meet the technical and regulatory requirements defined under eIDAS 2.0 and elaborated in the ARF. It is important to understand the distinction here: the legally binding requirements are set out in the eIDAS 2.0 regulation and its implementing acts, while the ARF provides the technical elaboration of those requirements. The specific compliance obligations depend on the type of attestation being issued. Organisations issuing QEAAs must be recognised as QTSPs and are subject to supervision by national competent authorities. Those issuing non-qualified EAAs need to meet baseline technical standards and be registered in a trust framework that wallet applications can verify. Issuing attestations of attributes is itself a trust service under eIDAS 2.0.

In practical terms, becoming an issuer involves several steps:

  1. Assess the attestation type: Determine whether you are issuing a PID, QEAA, PuB-EAA, or non-qualified EAA, as each has different compliance requirements.
  2. Review the technical standards: Align your systems with the specifications in the ARF, including data formats such as mdoc and SD-JWT VC, cryptographic standards, and interoperability requirements. The ARF provides technical elaboration of the legally binding requirements set out in the implementing acts.
  3. Register with the relevant trust framework: Your organisation and its attestations must be discoverable and verifiable by wallet applications across the EU, through the applicable national trusted lists, which are brought together in the EU List of Trusted Lists (LOTL).
  4. Implement issuance infrastructure: Build or integrate the backend technology needed to issue, sign, and manage attestations in a wallet-compatible format, using OID4VCI for issuance.
  5. Support revocation and re-issuance: Make revocation status available and support re-issuance when a user moves to a new device, since private keys do not leave the secure element and attestations cannot simply be copied across.
  6. Test and validate: Work with the available reference implementations and pilot infrastructure to validate that your attestations work correctly in real wallet environments.

For organisations in financial services or government, the path to becoming an issuer may also involve coordination with national supervisory authorities and national competent authorities or registrars, who play a central role in certifying and overseeing actors within their jurisdiction. The regulatory landscape is still maturing, but the technical groundwork is already in place through the open-source reference implementations provided by the European Commission.

Are EUDI Wallet documents accepted across all EU member states?

The EUDI Wallet framework is designed so that a certified wallet from one Member State can be used with an appropriate relying party in another Member State. This cross-border interoperability is one of the core goals of eIDAS 2.0. Under the regulation, Member States are required to accept wallet attestations that meet the defined technical and assurance standards, regardless of which country issued them.

This is a significant improvement over the original eIDAS framework, which required mutual recognition of notified national eID schemes but left many gaps in practice. The new framework introduces common technical standards, shared trusted lists consolidated in the EU List of Trusted Lists, and a unified architecture that makes cross-border acceptance more reliable and consistent.

That said, it is important to be precise about what cross-border interoperability means in practice. Not every use case will immediately be available in every Member State, and not every attestation automatically carries the same legal consequence in every jurisdiction. Sector-specific legislation continues to apply, and relying party registration under CIR (EU) 2025/848 of 6 May 2025 remains connected to the applicable national registration framework. A German hospital, for example, needs to be technically capable of reading and verifying a Dutch patient’s EHIC attestation from their wallet, and must also meet any applicable national requirements for doing so. The large-scale pilots that ran across participating Member States specifically tested this cross-border functionality to identify and resolve gaps before full rollout.

What should organisations do now to prepare for EUDI Wallet document integration?

Organisations should start preparing now by mapping out which EUDI Wallet attestations are relevant to their sector, assessing their current technical infrastructure, and identifying gaps in their compliance and integration readiness. 24 December 2026 is the legal deadline by which Member States must make wallets available and public bodies must accept notified wallets for online services requiring electronic identification. From 24 December 2027, Article 5f of eIDAS 2.0 applies to relevant regulated private sectors where strong user authentication is legally or contractually required, covering areas such as financial services, healthcare, telecoms, energy, transport, education, social security, drinking water, postal services, digital infrastructure, and digital services. Micro and small enterprises, defined as those with fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros, are exempt. Very Large Online Platforms (VLOPs) fall under a separate provision of Article 5f: the obligation applies where the platform requires user authentication, on the voluntary request of the user and for the minimum necessary data.

These legal deadlines are the latest permissible dates, not predicted launch dates. Practical interoperability and national rollout are likely to develop in phases, which is precisely why organisations should not wait before beginning their preparations.

Concrete steps to take now include:

  • Identify your role: Will you be an attestation issuer, a relying party accepting attestations, or both? Each role has different technical and regulatory requirements.
  • Review the Architecture and Reference Framework: Familiarise your technical teams with the ARF to understand data formats, trust models, and integration requirements. The ARF provides technical elaboration of the legally binding requirements set out in the implementing acts.
  • Understand relying party registration: Under CIR (EU) 2025/848, a relying party must register with the national authority of its Member State of establishment before requesting wallet data. Registration covers the specific attributes and attestations the relying party intends to request, and the wallet checks requests against that registered scope.
  • Audit your identity infrastructure: Assess whether your current onboarding, verification, and authentication systems can connect with wallet-based attestations.
  • Engage with pilot outputs: The large-scale pilot programmes produced detailed findings on real-world wallet usage. These insights are publicly available and highly relevant for planning.
  • Plan for selective disclosure: Design your data requests to ask only for what is strictly necessary, in line with the privacy-by-design principles built into the wallet framework.

Organisations that wait until wallets are fully deployed will find themselves under pressure to adapt quickly. Starting now gives you the time to test, iterate, and build internal knowledge before the regulatory deadlines arrive.

How TrustTech helps with EUDI Wallet document integration

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 preparing to issue or accept EUDI Wallet attestations, the ID Connector handles the technical complexity of wallet integration in practice. Specifically, it covers:

  • Accepting every relevant certified wallet, so a relying party is not locked to a single wallet provider or Member State
  • Verifying issuer signatures against the applicable national trusted lists consolidated in the EU List of Trusted Lists
  • Checking revocation status via issuer-provided status information
  • Validating wallet unit attestations to confirm that the presenting wallet runs on a certified wallet solution
  • Enforcing the registered attribute scope so that only the attributes declared in the relying party’s registration under CIR (EU) 2025/848 are requested
  • Supporting qualified signing via a connected QTSP for use cases in financial services, healthcare, pharma, and government where a qualified electronic signature is required

Whether you are an issuer preparing to put diplomas, prescriptions, or professional credentials into user wallets, or a relying party in financial services, healthcare, or government that needs to accept and verify those attestations, the ID Connector provides the integration layer that connects your systems to the EUDI Wallet ecosystem. Get in touch with TrustTech to discuss your situation and find out how to move forward.