How the EUDI Wallet works: the technology explained simply

The EUDI Wallet is more than a photo of your ID card on your phone. Your credentials are digitally signed, bound to your device and can be shared attribute by attribute. Anyone requesting data must identify themselves. This page explains the flow in three steps – issue, present, verify – and why it benefits both users and businesses. Terms are explained in the glossary.

Who is involved

• Issuers: bodies that issue credentials. The most important are the providers of person identification data (PID), the digital proof of identity. Then there are issuers of attestations of attributes, such as driving licence authorities, universities or banks.
• User with wallet: the wallet app on the smartphone stores the credentials; a secure cryptographic device holds the secret keys.
• Relying party: companies or authorities that request data from the wallet, such as a bank opening an account.
• In the background: trusted lists and the national registers of relying parties. They determine who may issue and who may request.

Step 1: Getting credentials into the wallet

When the wallet is set up, it first obtains the PID. In Germany, for example, the d-you wallet reads the ID card once via its online ID function. The issuer checks that the wallet is genuine: the wallet provider confirms this with a wallet unit attestation.

The issuer then signs the credential and binds it cryptographically to a key that exists only in your wallet (Implementing Regulation 2024/2977, Art. 2(4)). A copied credential is therefore useless: without the key it cannot be presented. Further credentials such as a driving licence or diploma are added the same way.

Step 2: Request and presentation

A relying party sends a request to the wallet. It authenticates itself with its access certificate and names the data it needs. The registration certificate also shows which data it has registered for this purpose. The wallet must authenticate the relying party (Art. 5a(5)(c), Art. 5b(8)).

You then see on the screen who is asking and which attributes are requested. Only when you approve with your PIN or fingerprint does the wallet send the data – and only the data requested.

This works in two ways:

• Online: in a browser or app, for example by scanning a QR code on a computer or directly on the smartphone.
• In person: at a checkout, a counter or a check via NFC, Bluetooth or QR code, even without an internet connection (offline mode, Art. 3(57)).

Step 3: Verification

The relying party checks three things itself:

1. Is the signature genuine? It traces the issuer’s signature back to a recognised body via the trusted lists.
2. Does the credential belong to this wallet? The wallet proves with its secret key that it is the legitimate holder.
3. Is the credential still valid? Issuers publish the validity status of their credentials in a privacy-preserving way so that revoked credentials can be detected (Implementing Regulation 2024/2977, Art. 5).

The issuer is not involved in this check and therefore does not learn where you present your credential. The regulation prohibits issuers from obtaining data after issuance that would allow your use to be tracked (Art. 5a(16)).

Sharing only what is needed

With a plastic ID card, the other side sees everything: name, address, date of birth, photo, card number. The wallet, by contrast, must support selective disclosure (Art. 5a(4)(a)). For an age check, “over 18” is enough.

Technically, it works like this: the issuer does not sign the attributes themselves but a digest for each attribute. The wallet reveals only the attributes you approve; the relying party checks them against the signed digests, while the rest stay hidden. Both formats used in the technical framework work this way: SD-JWT VC and mdoc.

Where identification is not required by law, relying parties must also not refuse pseudonyms (Art. 5b(9)).

Protection against misuse

The wallet alone does not protect against curious companies. That is why there are several safeguards:

• Registration: every relying party must register in advance and state which data it requests and why. It must not request anything else (Art. 5b(3)). The registers are public.
• Certificates: without a valid access certificate the wallet releases nothing. In case of violations the registrar can suspend the registration, and the certificates are then revoked (Implementing Regulation 2025/848, Art. 9).
• Issuer rules: issuers can embed a disclosure policy in a credential, for example “employers only”. The wallet evaluates it for each request (Implementing Regulation 2024/2979, Art. 10).
• Dashboard: the wallet logs all transactions. From there you can ask for your data to be erased and report suspicious requests to the data protection authority (Art. 5a(4)(d)).

Critics argue that these safeguards do not go far enough: registration barely checks purpose and necessity, and signed data is easier to pass on.

Comparison: wallet, German eID and video identification

For businesses this means no manually typed data, no ID copies and no waiting in a video call. The data arrives machine-readable and verifiable.

Standards behind the wallet

The regulation defines what the wallet must do. How it works technically is described by the Architecture and Reference Framework (ARF). Since 11 August 2026 the standards have been binding through Implementing Regulation (EU) 2026/1731, which refers to three ETSI profiles (TS 119 472-1 to -3):

• Issuance: OpenID4VCI
• Online presentation: OpenID4VP in the HAIP profile or ISO/IEC 18013-7 (Annex C), both also via the browser’s Digital Credentials API
• In-person presentation: ISO/IEC 18013-5 (mdoc)
• Credential formats: SD-JWT VC and mdoc
• Revocation: the IETF Token Status List

Some of these standards are still moving: SD-JWT VC and the Token Status List are still IETF drafts (as of 12 October 2026). Which version currently applies and what the regulation requires is shown in our standards overview.