Becoming a EUDI Wallet relying party is the part of eIDAS 2.0 that lands on engineering teams, and it is the part that has had the least attention. By 24 December 2026, every member state must make a compliant European Digital Identity Wallet available to its citizens and residents. That deadline is binding under Regulation (EU) 2024/1183, the implementing acts are published, and cross-border interoperability testing between member states has already taken place.
Most coverage has focused on the wallet itself: what it stores, how citizens use it, how the privacy architecture holds up. The complementary problem gets far less attention, although it is where the engineering work actually sits. A wallet is only useful if organisations can accept it.
Accepting it means integration work, registration with a national authority and, in many cases, redesigning identity flows that were never built for an attribute-based model. This article follows our eIDAS 2.0 implementation guide, which covered the regulatory framework and the organisational obligations. Here we stay on the technical question.
What a EUDI Wallet relying party is and why it matters
Three kinds of actor make the ecosystem work, and the distinction matters because the obligations differ sharply between them.
Anyone running identity verification in a regulated sector will end up in the third category. That is the position this article is written from.
The technical standards a EUDI Wallet relying party must support
Accepting wallet credentials means implementing a specific stack. It overlaps with existing OAuth and OpenID Connect work, but it is not a superset of it.
Remote and proximity are two different builds
Teams often scope one project and discover two. An online onboarding flow and a branch counter check share the credential formats and the trust infrastructure, yet almost nothing of the transport layer or the user experience. If both channels are in scope, they need separate estimates, separate test plans and separate fallback behaviour. The ARF and the implementing act on protocols and interfaces both treat them as distinct, so a plan that treats proximity as a later phase is easier to defend than one that assumes it comes for free.
What selective disclosure changes for a EUDI Wallet relying party
Selective disclosure lets a holder prove one attribute without handing over the rest of the credential. The mechanism deserves precision, because it is often described loosely. SD-JWT and mdoc both allow individual data elements to be disclosed while the others stay hidden and the issuer signature stays valid. Proving that someone is over 18 without revealing a date of birth works because the credential itself carries discrete elements such as age_over_18, issued by the authority. The wallet discloses that element and withholds the date.
Where the change lands in your systems
Data model. Records built around document type, document number and a scan need to accommodate attribute-based evidence instead. The verification record becomes a set of proven claims with an issuer and a timestamp.
KYC and AML. Wallet credentials carry legal validity under eIDAS 2.0, although compliance teams still have to satisfy themselves that attribute attestations meet their own customer due diligence procedures. That review takes longer than the engineering work in most banks, so it should start in parallel rather than after.
User journey. A presentation is not an upload. The holder opens a wallet, picks a credential, reviews the requested attributes and approves. The screens either side of that moment need redesigning, and the copy needs to explain why fewer fields are being requested than before.
Failure paths. Partial presentations, refused consent, expired credentials and unavailable wallets all need defined behaviour. During the transition this matters more than the happy path, because the happy path is the rarer case.
EUDI Wallet relying party registration with the national authority
Registration is the step teams forget when they scope the work. Before it can request presentations, a relying party has to register with its national supervisory authority, identifying itself as a legal entity, declaring which attributes it will request and stating the purposes. There is a dedicated implementing act covering relying party registration, so the process is defined at EU level even where national implementation still lags.
Two consequences follow. First, this is a prerequisite rather than a formality, because the trust infrastructure checks the registration during the presentation flow. Second, full end-to-end testing cannot happen until registration exists, which puts it on the critical path rather than in the paperwork column. Organisations operating in several member states may need to register in each of them, and the national processes are not uniformly specified yet.
An honest assessment of member state readiness
An independent assessment published in April 2026 reviewed progress towards the December 2026 availability deadline. Three member states looked almost certain to arrive with full functionality, five very likely, eight likely with caveats, and eleven faced varying degrees of risk.
So a plan that assumes 27 fully featured wallets on day one will not survive contact with reality. Some wallets will be complete, others will ship with reduced functionality, and a few will be late. For a relying party this is an argument for building the fallback path first and treating wallet acceptance as an additional channel rather than a replacement.
Portugal sits among the better-prepared states, partly because the existing infrastructure is mature. The Portuguese Citizen Card middleware, which we built, is in use across the entire population, and that continuity makes the national timeline more predictable than most. Our notes from LisbonID 2026 cover where the European conversation stood earlier this year, and our work on digital identity in Cabo Verde shows the same architecture applied outside the EU.
A EUDI Wallet relying party integration checklist
Five questions, in the order worth answering.
What eID Box does in this context
eID Box is our digital identity middleware. It integrates smart card authentication into enterprise applications and has been deployed in the Portuguese national identity card system, used across the whole population. The eIDAS 2.0 transition is the next chapter of the same work rather than a departure from it.
For organisations working through the integration, we assess current identity verification flows and identify what has to change, build or integrate the components needed to verify wallet presentations, support the registration process with the relevant national authority, and design the fallback paths for users whose member state wallet is not ready. Twenty years of building this kind of infrastructure for Portuguese public sector and enterprise clients is what we bring to it.
Frequently asked questions
EUDI Wallet relying party basics
What is a relying party in the EUDI Wallet ecosystem?
When must organisations accept the EUDI Wallet?
Standards and selective disclosure
What technical standards does a relying party need to implement?
What is selective disclosure in the EUDI Wallet?
Timelines and fallbacks
Does the EUDI Wallet replace existing identity verification methods?
Will the EUDI Wallet be available in all 27 member states from December 2026?
