EU Digital Identity Wallet (eIDAS 2.0): A Relying-Party Implementation Guide Before the 2026 Deadline

Two dates matter, and they obligate two different parties. Member states must have a certified wallet available, with a national relying-party register operational, by 24 December 2026 under Commission Implementing Regulation (EU) 2025/848. That register has to be reachable through both a public website and a machine-readable API, so a relying party's registration status becomes a checkable, auditable fact rather than a private arrangement with a regulator. The obligation that actually falls on private-sector engineering teams follows one year later: by late 2027, banking, healthcare, telecom, energy, transport, and education providers, plus very large online platforms, must accept the EUDI Wallet as an authentication method.

Missing that second deadline is not a soft compliance gap. An obligated relying party that has not registered, has not implemented a working presentation flow, and cannot verify a wallet-issued credential is out of compliance with a binding EU regulation the moment the obligation applies to its sector, with the same enforcement posture as any other eIDAS obligation, national supervisory authorities empowered to investigate and sanction. Even for organizations outside the explicitly regulated sectors, waiting until the deadline is close is a mistake: national registration has lead time, conformance testing against a sandbox environment takes real engineering effort, and attribute-mapping work against an existing identity system is exactly the kind of integration that always takes longer than the first estimate.

Before scoping the integration, get three pieces of context straight, because they shape every implementation decision that follows.

Identify the national body responsible for the relying-party register in the member state where your organization is legally established, this is a designated national authority under the Implementing Regulation, not a pan-EU portal. Before submitting anything, inventory every use case where your product will request wallet credentials (account opening, age verification, professional-qualification checks, login) and, for each one, write down the exact attribute set needed, nothing broader. That attribute list is what you declare at registration, and because the register is required to be both human-readable and machine-readable via API, expect other relying parties, wallet providers, and auditors to be able to check what you declared against what your integration actually requests in production. A mismatch between the two is the kind of finding a supervisory authority does not need a user complaint to catch.

Once registered, the integration work is an OpenID4VP relying-party implementation. At a high level: your service constructs a presentation request naming the specific credential type and attribute set you are authorized to request (matching your registration declaration), the wallet user is directed to their wallet app to review and approve the request, and the wallet returns a signed verifiable presentation. This is architecturally similar to an OAuth authorization request in that a user reviews a scoped request and grants or denies it, but the artifact returned is a cryptographically signed credential rather than a bearer token, and there is no authorization server in the middle brokering trust; verification is the relying party's own responsibility, which is the next step and the one most teams underestimate.

Receiving a signed presentation is not the same as trusting it. A relying-party implementation has to independently verify, for every credential presented: that the digital signature is cryptographically valid over the exact payload received, that the issuing authority's certificate chains up to an entry on the applicable EU or national trusted list rather than an arbitrary self-issued certificate, that the credential has not been revoked, and that the wallet instance itself carries a valid attestation proving it is a certified wallet rather than a spoofed client replaying captured data. Skipping any one of these checks, accepting a valid signature without checking issuer trust, for example, defeats the entire point of the system: a technically well-formed but untrusted credential should be rejected exactly as if the signature itself had failed.

A verified presentation returns a structured attribute set, Person Identification Data such as name, date of birth, and a unique identifier, plus whatever additional attestations the use case required. That data has to be mapped into whatever identity or KYC system already drives your onboarding flow today, and this is where integration effort tends to balloon. Attribute names, formats, and even the underlying schema differ between the mdoc and W3C Verifiable Credential encodings, and a relying party that only tested against one wallet provider's implementation during development can discover format mismatches only once a second provider's wallet shows up in production traffic. Build the mapping layer to validate and normalize on ingestion rather than assuming every wallet implementation serializes identically, and treat a failed or ambiguous mapping as a rejection to review, not a best-effort field-by-field guess pushed into your user record.

Selective disclosure lets a wallet return only the specific attributes or derived claims a relying party actually needs, an age-over-18 boolean instead of a full date of birth, for example, rather than the complete credential. Two things follow from that. First, your presentation request should ask for the minimum viable claim for the use case, not the full PID record by default, both because your registration declaration is supposed to reflect that minimalism and because over-requesting creates a data-handling liability you do not need. Second, your verification logic has to handle selectively-disclosed presentations as a first-class case, not an edge case: a credential missing fields you did not request is correct behavior, not an incomplete or malformed presentation, and code that expects every possible attribute to be present will misclassify legitimate minimal disclosures as verification failures.

Do not point a production integration at a live national wallet as your first test. Member states and the European Commission have stood up conformance testing tooling and sandbox environments alongside the large-scale pilot programs that preceded the 2026 rollout, and wallet providers building to the ARF generally expose test instances against the same OpenID4VP endpoints your production integration will use. Run your presentation-request flow, signature verification, issuer-chain validation, and attribute-mapping logic against that sandbox with test credentials covering the full range of outcomes you need to handle correctly: a valid credential, an expired one, a revoked one, a credential from an issuer not on the trusted list, and a selectively-disclosed presentation missing fields you did not request. Treat each of those as a required test case before go-live, not an optional stretch goal, because production is the wrong place to discover that your issuer-chain check silently passes on an untrusted certificate.

Three failure modes will show up in production regardless of how carefully you build the happy path.

Accepting a wallet credential shifts real liability onto the relying party. If your verification logic accepts a credential from an untrusted issuer, misses a revocation, or mismaps an attribute into the wrong onboarding field, the consequences, a fraudulent account opening, an incorrect eligibility decision, land on your organization's verification process, not on the wallet or the issuer. That is a strong argument for building verification as a dedicated, carefully tested component rather than a bolt-on to an existing auth flow, and for keeping a clear audit trail of what was verified, when, and against which issuer and trusted-list state.

The privacy side of the same coin is over-requesting. Because your national registration declares the exact attributes you are authorized to request per use case, asking a wallet for more than a given interaction actually needs is both a registration violation and a needless data-handling liability under general EU data-protection law; see our GDPR technical controls guide for the broader obligations that apply once government-issued identity attributes land in your systems. The discipline required here, scope every request to the minimum claim needed, and treat scope creep in what you ask for as a design defect, is the same discipline covered from the delegated-authorization angle in our OAuth consent grant audit guide. Minimal disclosure is not just the safer default; for regulated eIDAS 2.0 relying parties, it is the compliant one.