eIDAS 2 for Postal & Delivery Services

eIDAS 2 requires postal and delivery operators to accept the EUDI Wallet for online identification. Next to that, the wallet will offer benefits for identity checks at the door, at the counter, and at the parcel locker. This guide gives an overview of all of the various use cases.

What changes for postal and delivery operators

1. Wallet acceptance becomes mandatory online. Where an operator is legally or contractually required to use strong user authentication for online identification, it must accept the EUDI Wallet as one of the options.
2. Handover gets an improved identity check. Instead of a courier judging whether an ID card looks right, the recipient can be verified cryptographically in seconds.
3. Age-restricted deliveries. A recipient proves they are above the threshold without handing over a document or revealing a birthdate.

Micro and small enterprises are exempt from the acceptance obligation.

What the obligation actually covers

It covers online identification. The requirement applies to digital channels, the customer account, the app and the web portal.

It applies where strong user authentication is required. The trigger is a legal or contractual requirement to use strong user authentication for online identification. Where no such requirement exists, the acceptance obligation does not attach.

Everything else on this page is optional. Verifying a recipient at the door, at a counter or at a locker, and checking age at handover, are not covered by the obligation. They are where most of the operational value sits, and they run on the same infrastructure — but they are choices, not compliance.

Which deadline applies

eIDAS 2 treats public and private services differently. Private companies in named sectors were given a three-year transition ending at the end of 2027. Public services were not: their obligation applies as soon as wallets are available, at the end of 2026.

Postal ownership across Europe is mixed. Some national operators remain state-owned or majority state-owned and are public sector bodies, which puts them on the earlier date. Others have been privatised, and the private parcel networks were never public at all.

The roles operators play under eIDAS 2

Verifier: the role with the deadline

As a verifier, an operator requests and checks credentials from customer wallets. Where a digital service already requires strong user authentication, it has to offer the wallet as one of the ways to satisfy it.

This means registering as a relying party with the national registrar, declaring which data each process will request, and being able to check that credentials received are genuine, still valid, and belong to the person presenting them. The same capability then serves the physical use cases below.

Issuer: optional

As an issuer, an operator can place its own credentials into customer wallets. Nothing in eIDAS 2 requires this. Delivery and collection confirmations are the plausible case — a verifiable record that a specific item was handed to a specific person at a specific time.

Wallet provider: optional

As a wallet provider, an operator would offer the wallet itself. This means meeting the EU's highest security requirements and passing a formal conformity assessment.

Every Member State must provide at least one certified wallet, so customers will already have one. The option is open, but it is a substantial undertaking and entirely separate from the acceptance obligation.

Core use cases at a glance

Online identification

This is the obligation. It applies to the digital channels where an operator is required to use strong user authentication.

Four things are involved:

• Register as a relying party with the national registrar, and declare which data each service will request. Wallets check requests against this registration.
• Support the standard protocols and formats. Credentials are presented over OID4VP, in the mandated formats, SD-JWT VC and ISO/IEC 18013-5.
• Validate what comes back. Check the signature, check the credential is still valid, and check it belongs to the person presenting it.
• Keep the alternatives. Customers who do not use a wallet must still be able to use the operator's digital services.

It also works the same for customers from any Member State, which the current process usually handles by exception.

Collection and handover

Outside the obligation, but with real benefits.

Registered items, insured parcels, legal notices, bank cards, passports and prescription medicines are often released against some form of identity check. That check happens in three quite different settings, and the wallet can help with all of them.

At the door. A courier currently glances at an ID card. With a wallet, the recipient presents a credential and it is verified against the issuing authority in seconds.

At a counter or collection point. The same check, but with the added problem that staff turnover and volume make consistency hard. Verification removes the variability entirely.

At a parcel locker. This is the interesting one, because there is nobody there at all. Locker collection today generally relies on a code, which can be forwarded, screenshotted or intercepted — so the locker knows someone has the code, not that they are the recipient. A wallet presentation is the first thing that actually answers the question in an unattended setting.

And it can ask for less. Confirming that the person collecting is the named addressee does not require seeing their full identity document. The wallet lets the operator request exactly the attribute the process needs.

Age-restricted deliveries

Also outside the obligation, and also worth doing.

Alcohol, tobacco, vaping products, knives, certain medicines and some other goods can only be handed to someone above a given age. E-commerce has made this a routine part of parcel delivery.

The current options are all poor. A courier estimating age is unreliable and awkward. Asking for an ID document at the door is intrusive and slow, and the courier still cannot verify it.

A proof of age from a wallet resolves it in one step. The recipient presents it, the operator learns only that they are above the threshold — no name, no date of birth, no document — and the handover proceeds. As with collection, the locker case benefits most, since an age check with no member of staff present is otherwise close to impossible.

Build vs buy: how to build a compliant solution

Whether acting as verifier, issuer, or both, a postal or delivery operator faces the same decision as every other organisation in the ecosystem: how much of the solution to build, and how much to buy. The customer-facing applications — the app, the tracking experience, the courier's handheld, the counter system — are where an operator differentiates and will always be built in-house or with existing partners. The identity layer underneath — credential formats, exchange protocols, trust checks, key management, revocation — is standardised by definition and changes every time the EU specifications evolve. For that layer, there are three possible implementation paths:

• Build apps, buy infrastructure (recommended) — build only the customer-facing applications and use a proven, standards-compliant provider for the identity layer. Fastest time to market, lowest regulatory and technical risk.
• Build apps, own infrastructure — use open-source identity infrastructure to retain full control of the stack, while still avoiding implementing the credential formats, protocols, and trust validation from scratch.
• Build everything in-house — implement and maintain the full stack internally, and keep it current as the specifications evolve. Viable only for organisations with a dedicated identity engineering team.

The walt.id solution

walt.id covers both of the first two paths. The walt.id Community Stack provides open-source issuer, verifier, and wallet infrastructure for organisations that want to own their stack; the walt.id Enterprise Stack is the enterprise-grade offering on top of it — built on open-source technology used by more than +55.000 developers, governments, and businesses. For postal and delivery specifically:

• Verifier — accept the EUDI Wallet for online identification, and use the same verification for handover, collection and age checks in app, at the counter, on a handheld and at a locker, with trust, revocation and wallet-authenticity checks handled automatically.
• Issuer — issue delivery and collection confirmations in all mandated formats (SD-JWT VC, ISO/IEC 18013-5, W3C VC), with revocation built into the issuance workflow.
• Cross-border by default — the same verification works for recipients from every Member State, without country-by-country integration.

A role-by-role compliance breakdown is available in the eIDAS 2 Implementers Guide or reach out to our team to learn more.

Frequently asked questions

What exactly does eIDAS 2 require of postal and delivery operators?

Postal service providers must accept the EUDI Wallet for online identification where they are legally or contractually required to use strong user authentication.

When does the deadline apply?

Private relying parties in named sectors, postal services among them, must accept the wallet by the end of 2027. State-owned operators which are public sector bodies must accept it as soon as wallets are available — the end of 2026.

Does the obligation cover identity checks at the door?

No. The requirement is about online identification. Verifying recipients at handover, at a collection point or at a locker sits currently outside it.

What does accepting the wallet actually involve?

Registering as a relying party with the national registrar and declaring which data each service will request; supporting the standard presentation protocol and mandated credential formats; validating that credentials received are genuine, valid and belong to the person presenting them; and keeping existing routes available for people who do not use a wallet.

Can operators use the wallet to verify recipients at the door or at a locker?

Yes, and the locker case is the most useful. Collection from a locker generally relies on a code, which can be forwarded or intercepted — so the locker knows someone has the code, not that they are the recipient. A wallet presentation verifies the person, with no member of staff present.

How does this help with age-restricted deliveries?

The recipient presents a proof of age and the operator learns only that they are above the relevant threshold — no name, no date of birth, no document. It works at the door, at a counter and at an unattended locker, where an age check is otherwise close to impossible.

Do operators have to issue credentials as well as accept them?

No. eIDAS 2 requires acceptance, not issuance. Issuing delivery or collection confirmations into customer wallets is possible but entirely optional.

Do operators need to build their own wallet?

No. Every Member State must provide at least one, so customers will already have one.

What about recipients who don't use a wallet?

They must still be able to receive and collect their post on equal terms. Wallet-based verification is an additional option, never a replacement for existing routes.