EUDI Wallet for Businesses: Relying-Party Readiness

A business does not become EUDI-ready by adding a “Verify with EU Wallet” button. It becomes a wallet-relying party: an identified, registered service that requests a declared set of data for a declared purpose and validates the resulting credential presentation.

The software matters, but the hard boundary is operational. Your legal entity, establishment country, use case, requested attributes, domains and technical credentials must line up.

First: determine whether you are a relying party

Under Regulation (EU) 2024/1183, a relying party is a person or organization that relies on electronic identification, an EUDI Wallet or another trust service.

For a typical online flow, you are the relying party if your service asks the user's wallet for PID or an electronic attestation and uses the verified result to provide access or complete an action.

Using an integration provider does not necessarily move that role away from you. Article 5b says intermediaries acting on behalf of relying parties are themselves deemed relying parties and may not store transaction content. The customer entity and the intermediary therefore need a clear responsibility model.

Do all businesses have to accept EUDI Wallets?

No. Article 5f defines particular acceptance obligations rather than a blanket requirement.

The principal groups are:

• public-sector bodies whose online service requires electronic identification and authentication;
• very large online platforms that require user authentication; and
• certain private relying parties, excluding micro and small enterprises, where law or contract requires strong user authentication for online identification.

The last group includes named sectors such as banking, financial services, health, transport, energy, education, social security, digital infrastructure and telecommunications. Applicability depends on the service, legal trigger, entity size and national rules.

A business can also choose to support the wallet voluntarily. In either case, the user chooses whether to use it.

The relying-party registration packet

Article 5b requires registration in the Member State where the relying party is established. At minimum, registration covers:

• the Member State of establishment;
• the relying party's official name and registration information where applicable;
• contact details;
• the intended wallet use; and
• the data that will be requested from users.

The relying party must report changes without delay and cannot request data beyond the registered scope.

The Commission's current service-provider guide says further national registration detail is still becoming available. Plan for country-specific onboarding even where the presentation protocol is common.

Define the minimum verified fact

Start with the business outcome, not a copy of a familiar form.

Bad requirement:

Collect every field from an identity document.

Better requirement:

Establish that this user is over 18 for this transaction.

Or:

Match this verified legal name and date of birth to an existing regulated account.

The second formulation produces a defensible attribute request and makes it easier to decide whether PID, a derived attribute, a pseudonym or another attestation is appropriate.

For each requested item, record:

1. the purpose;
2. the legal or contractual need;
3. the accepted credential types;
4. whether the raw value must reach your system;
5. retention and access rules; and
6. the fallback when it is unavailable.

Separate identity, authentication and authorization

These terms overlap in product copy but not in system design.

• Identity presentation provides verified attributes.
• Authentication establishes control of a wallet or binds a user to a session.
• Authorization is your application's decision to allow an action.

The wallet and verifier can tell you that a trusted issuer attested a claim and that the holder presented it for a fresh request. Your application still decides whether that result permits account access, onboarding or another regulated action.

Keep that policy outside the wallet adapter. Otherwise every country or credential addition risks changing business logic.

Build the trust path, not only the happy path

A production verifier should reject:

• an unknown or unauthorized issuer;
• a credential outside its permitted profile;
• an expired, revoked or suspended credential;
• a response to the wrong nonce or transaction;
• a presentation bound to another relying party;
• an unsupported or malformed selective disclosure;
• a wallet or reader certificate outside the trusted ecosystem; and
• data that exceeds or fails to satisfy the request.

The current EUDI Launchpad test programme tests both successful exchanges and failures such as untrusted reader or issuer certificates. Your acceptance tests should do the same.

Plan a voluntary user journey

Wallet use must remain voluntary. A good journey therefore includes:

• a clear explanation of why wallet data is requested;
• the exact data or result required;
• same-device and cross-device handoff where applicable;
• a safe decline path;
• a fallback for users without a supported wallet or credential;
• recovery from cancellation, expiry and interrupted handoff; and
• no false suggestion that a sandbox result is a real identity.

Fallback is part of the security model. If the alternative quietly accepts weaker evidence without telling downstream policy, the strong wallet route does not protect the overall journey.

Treat coverage as routes, not countries

“Germany supported” or “EUDI enabled” is not enough to operate a real service.

A useful coverage record includes:

Dimension	Question
Jurisdiction	Which national trust and registration system applies?
Wallet	Which certified provider presents the credential?
Credential	PID, mDL, QEAA, public-body attestation or another EAA?
Format	mdoc, SD-JWT VC or another permitted profile?
Delivery	Remote, cross-device or proximity?
Issuer trust	Are the issuer and status sources available in production?
RP state	Is this relying party approved for this purpose and attribute set?
Runtime state	Has the exact route passed a real acceptance test?

This matrix prevents a pilot in one country from being misreported as EU-wide production support.

Decide what evidence to retain

A wallet presentation can produce several kinds of record: the relying party's request, user consent context, verified claims, issuer proof, status result, timestamps and application decision.

Retention should follow the actual purpose and legal obligations. Keeping everything “just in case” undermines data minimisation; deleting evidence needed to support a regulated decision creates a different risk.

Document:

• which data is returned to the business;
• which evidence a processor retains;
• who can decrypt or disclose it;
• the retention period and legal-hold rules;
• what an end user can access; and
• what remains immutable after a completed transaction.

Do not describe a derived age result as zero-PII unless every component truly avoids processing identifying data. Business-redacted output and service-side processing are different claims.

Prepare without pretending production is live

Useful pre-production work includes:

1. Map use cases to the minimum attributes.
2. Inventory relying-party legal entities and establishment countries.
3. Follow each national registration authority and required technical credential.
4. Implement nonce, state, origin and session binding.
5. Validate both mdoc and SD-JWT VC only where needed.
6. Build issuer, wallet, status and trust-list update processes.
7. Test denial and untrusted-certificate cases.
8. Design voluntary fallback and accessibility paths.
9. Reconcile asynchronous events and duplicate delivery.
10. Label synthetic and pilot credentials unmistakably.

The Commission's Relying Party Engagement Programme is aimed at organizations doing this preparation during 2026.

Where Alentra fits

Alentra is designed to let an application compose verified identity actions without embedding country, wallet and credential logic into the business workflow.

The customer selects the routes and facts it intends to support. Alentra's coverage model keeps provider, jurisdiction, credential, registration and runtime readiness separate, then exposes only effective routes. The application receives normalized primitive results and keeps the authorization decision.

That is the intended production model. Current public production routes remain marked coming soon until provider access, national relying-party registration, trusted issuers and real acceptance tests are complete. A synthetic EUDI reference route exists in the sandbox for testing identity and age flows; it is not production proof.

For context, read the complete EUDI Wallet guide and the technical guide to how EUDI Wallet architecture works.

This checklist is technical and operational guidance, not a determination that Article 5f applies to a particular organization.