Why a European framework is needed
A digital identification method that works in one EU country is not automatically usable with every service provider in another. Information about education or professional qualifications is also supplied and checked in different ways. People may therefore have to gather the same information again, while organisations must establish its origin and whether they can trust it.
Using digital identity and confirmed information across borders requires systems and organisations to work together. Common arrangements for recognition, security and acceptance make this possible. European rules already exist; eIDAS 2.0 builds on them.
What eIDAS 2.0 adds
The original eIDAS Regulation already provided, under certain conditions, for the recognition of national electronic identification methods when accessing online public services in other EU countries. It also established rules for trust services such as electronic signatures, seals and time stamps.
Existing European foundation
Electronic identification and trust services
Extensions for wallets and credentials
EUDI wallets
A common framework for wallets in which you can receive, store and share identity data and digital credentials. Each Member State must provide at least one EUDI wallet.
Attestations of attributes
Issuing attestations about information such as qualifications or authority gains a specific place among trust services, with legal requirements and effects.
Wallet acceptance
Acceptance obligations are introduced for public services and certain private services. The obligation depends on the service and the applicable conditions.
Legislation and technical implementation
eIDAS 2.0 is the usual name for the extension of the eIDAS Regulation. The Regulation and applicable implementing rules determine the legal requirements. The Architecture and Reference Framework (ARF) describes the architecture and technical cooperation. It supports implementation and does not replace the law. This explanation uses ARF 3.0.
What you can do with an EUDI wallet
Identify yourself to a service
When you submit an application or log in to a portal, an organisation may need to know who you are. You can share identity data using an EUDI wallet. The organisation checks that data and uses it within its application or login process.
Demonstrate a fact about yourself
Sometimes a specific fact is needed, such as a qualification or whether you meet an age threshold. For an age check, confirmation that you are over 18 may be sufficient. With a suitable credential, the organisation would not also need to receive your full date of birth.
Sign a document
An EUDI wallet must also enable signing with qualified electronic signatures. A wallet can therefore play a part in an agreement or application. The receiving organisation checks the signature and processes the document within its own workflow.
These are possible applications. What you can actually use depends on available credentials, the wallet and the receiving organisation’s integration and acceptance.
How issuing, sharing and checking work
Identity data used to demonstrate who you are is called person identification data, or PID, within the European framework. Other digital credentials cover matters such as qualifications or authority. They can come from different issuers; not every exchange requires full identification.
Consider someone demonstrating their completed education to an employer. Each participant has a distinct task in that exchange.
The issuer confirms the information
An educational institution records who has completed a course of study. In its role, it can issue a digital credential confirming this. The digital signature makes the origin and changes to the signed content verifiable. Here, the institution is both the source authority and the issuer; these can also be separate organisations.
The user chooses to share
The user receives the credential in a wallet. When an employer requests education details, the user reviews the request and decides whether to share them. The employer also receives the information needed to check the credential. The wallet provider supplies the wallet; the issuer remains responsible for the credential.
The recipient checks and decides
The employer checks, among other things, the origin, signature, validity and the binding to the user required for this application. The employer then assesses whether the issuer and information are suitable for determining if the applicant meets the education requirement. A successful technical check does not replace that assessment.
- Programme
- Computer science
- Level
- Bachelor’s degree
- Programme
- Computer science
- Level
- Bachelor’s degree
- Programme
- Computer science
- Level
- Bachelor’s degree
Issue
The institution confirms the qualification from its records and issues a signed credential.
Source authority and issuer
Educational institution
- Programme
- Computer science
- Level
- Bachelor’s degree
- Programme
- Computer science
- Level
- Bachelor’s degree
User with wallet · NL Wallet
The complete exchange
The institution issues, the user chooses to share, and the employer checks and assesses. Start the animation or choose a moment.
What trust rests on
Trust requires clarity about who confirmed the information, on what basis and what you can use it for. Origin, legal meaning and user protection each play a part.
Assessing the issuer and source
For education details, an employer needs to know which institution and records underpin the credential. A correct signature does not make incorrect source data accurate or authorise the signatory to confirm every claim.
Understanding the legal meaning
Not every digital credential automatically falls under eIDAS. For credentials issued as electronic attestations of attributes (EAAs) within this framework, we distinguish three categories.
| Category | Who issues it? | Safeguards and legal meaning |
|---|---|---|
| Non-qualified EAA | A provider that does not deliver this issuance service as a qualified service. | Legal requirements still apply. Its electronic or non-qualified form alone is not a reason to deny it legal effect or admissibility as evidence in legal proceedings. |
| Qualified EAA (QEAA) | A trust service provider qualified for this specific issuance service (QTSP). | Additional requirements, conformity assessment and supervision. The same legal effect as a lawfully issued paper attestation. |
| PuB-EAA | A public sector body responsible for an authentic source, or a public sector body designated by the Member State to act on its behalf. | Specific legal requirements, conformity assessment and notification. The same legal effect as a lawfully issued paper attestation. Not every government credential is automatically a PuB-EAA. |
These categories are not file formats or trust frameworks. Whether a credential is suitable for a decision also depends on its content and the applicable acceptance rules.
Checking the status of participants
The qualified status of a specific issuance service is recorded in national Trusted Lists. The European List of Trusted Lists, or LOTL, points to those national lists. PID and PuB-EAA have their own recognition and listing mechanisms. An organisation’s listing as a qualified provider alone is therefore insufficient.
Protecting the user
Wallet use remains voluntary. Users must be able to see who requests information and decide whether to share it. The recipient also needs a valid GDPR legal basis and may only process personal data necessary for its purpose. Approval in the wallet does not replace those obligations.
Which responsibilities and obligations apply
The requirements for your organisation depend on its role. One organisation can fulfil several roles: a municipality may issue credentials and receive wallet data for another service.
| Role | Responsibility |
|---|---|
| Member State | Ensures that at least one EUDI wallet is provided and organises the required recognition, registration and supervisory structures. A wallet may be provided by the state, under its mandate or with its recognition. |
| Wallet provider | Ensures the wallet meets applicable requirements, is certified and continues to operate securely. Protects personal data and provides support when problems arise. |
| Issuer | Substantiates the information it confirms, performs required checks and ensures secure issuance and applicable status management. The precise requirements follow from the credential, its legal category and the relevant arrangements. |
| Receiving organisation | Registers as a relying party, identifies itself and stays within its registered data request. Is responsible for checking received data, lawful processing and the decision it uses the data for. Registration does not itself authorise requesting all registered data. |
When must an organisation accept a wallet?
- Online public services
- Where a Member State requires electronic identification and authentication to access an online public service, a compliant EUDI wallet must also be accepted.
- Certain private services
- Where strong user authentication for online identification is required by law or contract, an acceptance obligation applies upon the user’s voluntary request. Microenterprises and small enterprises under the European definition are exempt from this specific obligation.
- Very large online platforms
- Platforms designated as such under the Digital Services Act have a separate acceptance obligation when they require user authentication. Wallet use is also at the user’s voluntary request, with the minimum necessary data.
Sector membership alone does not determine the acceptance obligation. The service, authentication requirements and exceptions matter. Wallet acceptance does not create a general obligation to issue credentials yourself.
How implementation progresses
Implementation takes place in stages. Wallet provision, registration of receiving organisations and wallet acceptance have different deadlines. The main dates are set out below with their audiences and conditions.
By
At least one EUDI Wallet per Member State
Each Member State must provide at least one EUDI Wallet. The deadline follows from 24 months after the relevant implementing acts entered into force.
Member States. This is not a general duty for every organisation to provide a wallet or issue credentials.
Applies from
Registration implementing rules
Rules for registering wallet-relying parties apply, including the 2026 amendments.
Registrars and organisations relying on EUDI Wallets for their services.
By
Electronic checks against authentic sources
Member States must enable QEAA providers, at the user’s request, to verify Annex VI attributes electronically where they rely on public-sector authentic sources.
Member States, relevant source holders and qualified attestation providers. This does not open all registers to general access.
By
Wallet acceptance for certain private services
Accept a compliant EUDI Wallet on voluntary request where strong user authentication for online identification is required by law or contract. The period is 36 months.
Private parties within Article 5f(2), excluding micro and small enterprises. The sector name alone does not determine the obligation.
The 24- and 36-month periods for wallet provision and private acceptance run from 24 December 2024, when the relevant wallet rules entered into force. The registration rules state their application date directly.
Online public services and designated very large online platforms have separate acceptance provisions. The deadline for private services is not a general deadline for all organisations.
Technical application dates and legal basis
- Entry into force
Expansion of eIDAS
The European framework expands to include EUDI Wallets and new trust services.
Participants in the European ecosystem.
- Entry into force
First wallet implementing rules
Starting point for the relevant 24- and 36-month periods.
Member States and wallet ecosystem participants.
- Entry into force
Technical rules updated
Amendments covering wallets, registration and attestations, with later application dates for specific provisions.
Wallet providers, registrars and attestation providers.
- Applies from
Lists, catalogues and source verification
Provisions on the PuB-EAA provider list, attribute and attestation scheme catalogues, and verification against authentic sources apply.
European Commission and Member States, affecting scheme owners and providers.
- Applies from
Additional source verification requirements
Specifications for the verification mechanism and signing or sealing verification results apply.
Authentic source holders or designated intermediaries performing these checks.
- Applies from
Reference standards for identity checks
The designated identity and attribute verification standards for qualified certificates and QEAA apply. The underlying verification duty already exists.
Qualified providers of these services.
- Applies from
Validating registration certificates
The specific duty for wallets to authenticate and validate relying-party registration certificates applies. This does not postpone the registration duty itself.
Wallet providers, under amended Articles 3(4) and 8 of 2024/2982.
What is actually available
A legal deadline does not establish which credentials and integrations are already available. For an application to work, the user needs access to a suitable wallet, an issuer must be able to provide the credential, and the recipient must be able to process and accept it.
Distinguish announced capabilities, trials and available services. Even when the technology is available, participants need to know what the information means and under which conditions they can use it.
From the European framework to trust frameworks
Organisations exchanging credentials need a shared understanding of the information. They also need clarity about which issuers they accept, which checks are required and how to handle changes or incorrect data.
A trust framework describes arrangements for participation, responsibilities and trust. These help organisations determine which credentials to use for an application, within applicable legal requirements.
A rulebook describes the meaning, data and arrangements for a specific kind of digital credential, including relevant rules for issuance, use and management. Organisations can adopt existing trust frameworks and rulebooks.
Read how trust frameworks work