The question is no longer whether the EU Digital Identity Wallet ships. It is whether your organization can accept one when a user presents it, and whether you are legally obliged to.
eIDAS 2.0, formally Regulation (EU) 2024/1183 amending Regulation (EU) 910/2014, moves the burden. For a decade the original eIDAS put obligations mainly on Member States and trust service providers. The amendment adds a new party to the picture: you, the organization that receives an identity presentation and decides to trust it. The legal term for that role is old, but the exposure attached to it is new.
If you run onboarding, age checks, account recovery, or any flow that asks a user to prove who they are, this is a scoping question you should already be answering.
What is the EU Digital Identity Wallet and what does eIDAS 2.0 (Regulation (EU) 2024/1183) actually mandate?
Start with the base regulation, because eIDAS 2.0 does not replace it. It amends it.
The original eIDAS (Regulation (EU) 910/2014) established two things: mutual recognition of notified electronic identification means across Member States, and a legal framework for trust services such as electronic signatures, seals, time stamps, and certificates. Article 2(1) sets the perimeter: it applies to electronic identification schemes notified by a Member State and to trust service providers established in the Union.
What Article 910/2014 did not do was put a single, portable identity instrument in every citizen's hand. That is the gap Regulation (EU) 2024/1183 closes.
eIDAS 2.0 introduces the European Digital Identity Wallet, commonly called the EUDI Wallet. It is a user-controlled instrument, provided under a notified scheme, that lets a person store and selectively present identity data and electronic attestations of attributes. The regulation entered into force on 20 May 2024, and it obliges every Member State to make at least one wallet available to its citizens and residents.
The wallet does two jobs at once. It carries person identification data, the concept defined in Article 3(3) of the base regulation as the set of data establishing a person's identity. And it carries attestations of attributes, which are verifiable claims about a person that go beyond bare identity: a professional qualification, an age band, a company role, a diploma.
For an organization on the receiving end, the wallet is not a login button. It is a verified data channel that arrives with legal weight and a registration regime attached.
Who counts as a relying party, and are you obligated to accept the wallet?
Here the base text is precise, and it is worth quoting because your obligations flow from it.
Article 3(6) of Regulation (EU) 910/2014 defines a relying party as "a natural or legal person that relies upon an electronic identification or a trust service." That definition is deliberately broad. It is not limited to banks or public bodies. If your service consumes an identity assertion or a trust service output and acts on it, you are a relying party.
Under the original regulation, being a relying party was mostly passive. Article 7(f) required notifying Member States to make cross-border authentication available so that "any relying party established in the territory of another Member State" could confirm the person identification data it received, and it barred Member States from imposing disproportionate technical requirements that would impede interoperability. The relying party was a beneficiary, not a regulated actor.
eIDAS 2.0 changes the posture. It converts many relying parties from passive consumers into registered, obligated participants. Two shifts matter most.
First, acceptance becomes mandatory in defined contexts. Where a relying party is required by Union or national law to use strong user authentication for online identification, or where it operates in sectors the regulation targets, it must accept the wallet as a valid means of identification. Very large online platforms fall squarely inside this expectation. The wallet becomes a right the user can exercise against you, not a channel you may opt into.
Second, acceptance is conditioned on registration. You do not simply switch the wallet on. You declare yourself, and you declare what you intend to ask for. More on that below.
The practical filter is simple. If any regulated flow in your estate depends on knowing who the user is with high assurance, assume you are in scope and work backwards from there. Mapping that exposure against your actual regulatory intelligence profile is faster than guessing.
What is the 2026 availability timeline every Member State must hit?
Be careful with dates here, because precision matters and vagueness invites false comfort.
The anchor date is fixed: eIDAS 2.0 entered into force on 20 May 2024. From there, the obligations phase in against the adoption of implementing acts that define the wallet's technical and trust-framework specifications. Member States must provide at least one EUDI Wallet within 24 months of the relevant implementing acts entering into force. That 24-month clock is what produces the 2026 availability window that compliance teams keep circling.
What that means in operational terms is a staggered but converging rollout. Through 2026, national wallets move from pilot to general availability, and the acceptance obligations on relying parties become live rather than theoretical.
The original regulation offers a useful analogue for how these recognition clocks behave. Article 6(1) of Regulation (EU) 910/2014 required a Member State to recognise another State's notified electronic identification means "no later than 12 months after the Commission publishes the list" of notified schemes. eIDAS recognition has always run on published-list-plus-fixed-window logic. eIDAS 2.0 keeps that pattern and applies it to the wallet.
The reading for a relying party is this. You do not get to wait until every Member State's wallet is live. You need to be ready before the availability run-up closes in your operating jurisdictions, because the day a wallet is generally available is the day a user can present it and expect you to accept it.
How does a relying party register and get authorised to request wallet attestations?
This is the mechanism that catches most organizations off guard, because nothing in the 2014 regulation prepared them for it.
Under eIDAS 2.0, a relying party that intends to rely on EUDI Wallets must register with the competent authority in the Member State where it is established. Registration is not a formality you complete once and forget. It is a declaration of intent that binds what you are then permitted to ask for.
At registration, a relying party is generally required to identify itself, state the purpose for which it will use the wallet, and declare which data or attributes it intends to request. That declaration is the leash. The wallet, and the user, can check what you asked to be authorised for against what you actually request at the point of interaction. Ask for more than you registered for, and the request is illegitimate on its face.
This inverts the traditional data-collection default. In most identity flows today, the service decides at runtime what to demand and the user either complies or leaves. Under the wallet model, your permitted request surface is fixed in advance, published through the registration regime, and enforced by the wallet itself.
Two consequences follow for governance. Your registration record becomes a compliance artifact you must keep aligned with your live data practices. And any change to what a flow collects is potentially a change to what you must be registered to request. That is an access governance problem as much as a legal one, because it ties a legal permission to a technical request pattern that engineering controls.
Which technical and trust-framework controls must you build to accept and verify a wallet presentation?
Accepting a wallet presentation is a verification pipeline, not a checkbox. Several controls trace directly to concepts the base regulation already defines.
Assurance level. Article 8 of Regulation (EU) 910/2014 defines three assurance levels: low, substantial, and high. The wallet is designed to operate at high assurance, the level Article 8 characterises as providing a higher degree of confidence in the claimed identity, with technical controls whose purpose is to prevent misuse or alteration of identity. Your acceptance logic has to understand assurance level and gate sensitive actions accordingly, rather than treating every presentation as equal.
Attestation verification. Beyond bare identity, the wallet presents qualified electronic attestations of attributes. A qualified electronic attestation of attributes is a new species of qualified trust service under eIDAS 2.0, issued by a qualified trust service provider, carrying the same legal-effect and presumption logic the base regulation reserves for qualified services. Your systems must validate the attestation cryptographically, confirm it was issued by a provider on the relevant trusted list, and check it has not been revoked. Article 3(41) already defines validation as "the process of verifying and confirming" that a signature or seal is valid; you are extending that discipline to attribute attestations.
Interoperability without over-engineering. Article 7(f) of the base regulation prohibits imposing disproportionate technical requirements on relying parties that impede interoperability of notified schemes. The design principle cuts both ways. Build to the common wallet interface and the published technical specifications, not to a bespoke integration that fragments as national wallets diverge.
Trusted-list consumption. Verification depends on knowing which issuers and providers are trusted. That means consuming and refreshing trusted lists as a live dependency, not a static config file. When a provider's status changes, your acceptance decisions should change with it. Mapping each of these obligations to a concrete control you can evidence is exactly the kind of control mapping work that separates audit-ready from audit-hopeful.
How do data-minimisation and over-asking limits change what attributes you may request?
This is the part that changes product design, not just security architecture.
The base regulation already embedded restraint. Article 12(3) of Regulation (EU) 910/2014 required the interoperability framework to "facilitate the implementation of the principle of privacy by design" and to ensure personal data is processed in accordance with the applicable data protection law. Article 5(1) tied all processing to that data protection regime, and Article 5(2) established that the use of pseudonyms in electronic transactions "shall not be prohibited." Minimisation and pseudonymity were principles from the start.
eIDAS 2.0 operationalises those principles at the transaction level through selective disclosure and the registration leash. The wallet is built so a user can release only the specific attributes a service needs, rather than a full identity dossier. Ask for proof that a user is over 18, and the wallet can present an age attestation without disclosing date of birth, name, or address.
For relying parties, this reframes the design question. The default is no longer "collect the identity record and derive what we need." It is "identify the minimal attribute that satisfies the decision, and request only that." Requesting attributes you did not register for, or that exceed the purpose you declared, is not a grey area under the wallet model. It is an over-asking violation the system is designed to surface.
The governance implication is concrete. Every attribute request in every flow needs a documented necessity justification tied to a purpose, and that justification has to match your registration declaration. This is where identity engineering and privacy compliance stop being separate conversations.
What should a relying-party readiness roadmap look like before the availability run-up closes?
Treat this as a scoping and control-mapping exercise first, and an integration project second.
Confirm your relying-party status. Apply the Article 3(6) test to every flow that consumes an identity or trust-service output. Where a flow is legally required to use strong user authentication, flag it as likely subject to mandatory wallet acceptance.
Inventory your attribute demands. List every identity attribute each flow requests today and attach a purpose to each one. This inventory becomes the basis of your registration declaration and your minimisation defence.
Prepare to register. Identify the competent authority in each Member State where you are established, and prepare the declaration of intended use and requested attributes. Keep it aligned with the inventory above, because divergence between what you registered and what you request is where enforcement lives.
Build the verification pipeline. Assurance-level gating per Article 8, qualified attestation validation, trusted-list consumption with revocation checking, and selective-disclosure request patterns. Design to the published wallet interface, not a one-off integration.
Wire minimisation into product. Convert full-identity requests into minimal-attribute requests, honouring the privacy-by-design principle Article 12(3) already required and the pseudonym allowance in Article 5(2).
Keep the map current. Wallet specifications arrive through implementing acts, and national rollouts land on different dates through the 2026 window. Your obligation map has to update as those instruments publish, not a quarter later.
That last point is the recurring failure mode. Organizations map eIDAS 2.0 once, then let the map rot while the implementing acts and national timelines keep moving. A relying-party posture is only defensible if it is current on the day a user presents a wallet.
Map your eIDAS 2.0 relying-party obligations against your organizational profile at agrc.ai, and see which acceptance, registration, and minimisation duties actually apply to your flows, source-grounded to the regulation text.
FAQ: eIDAS 2.0 relying-party questions answered
Is my organization legally required to accept the EU Digital Identity Wallet? If Union or national law requires you to use strong user authentication for online identification, or you operate as a targeted platform such as a very large online platform, eIDAS 2.0 obliges you to accept the wallet. Start from the Article 3(6) relying-party definition and check whether any in-scope flow triggers the acceptance obligation.
What is a qualified electronic attestation of attributes? It is a verifiable claim about a person, such as an age band, professional qualification, or company role, issued as a qualified trust service under eIDAS 2.0 by a qualified trust service provider. It carries the legal weight the base regulation reserves for qualified services, and relying parties must validate it against the relevant trusted list.
Do I have to register before I can request wallet data? Yes. A relying party intending to rely on EUDI Wallets registers with the competent authority in its Member State and declares the attributes it intends to request. That declaration bounds what you may ask for at the point of interaction.
When does this actually take effect? eIDAS 2.0 (Regulation (EU) 2024/1183) entered into force on 20 May 2024. Member States must make at least one wallet available within 24 months of the relevant implementing acts entering into force, producing a 2026 availability window. Acceptance obligations become live as national wallets reach general availability.
How is this different from the original eIDAS? Regulation (EU) 910/2014 focused on Member State schemes and trust service providers, with relying parties as passive beneficiaries under Article 7(f). eIDAS 2.0 adds the wallet, makes acceptance mandatory in defined contexts, and turns relying parties into registered, obligated participants subject to over-asking limits.
