What's the Difference Between a Digital ID and a Digital Wallet?

July 2, 2026 ·Mairi Kutberg ·

digital-iddigital-walleteudi-walletverifiable-credentialidentity-credentialidentity-verificationholder-bindingeidastrust-frameworkauthentication

A digital ID is the verifiable credential that proves who you are — issued by a trust framework like eIDAS, a passport chip, or a national eID scheme. A digital wallet is the user-controlled container that holds those credentials and presents them to verifiers under selective disclosure. The wallet does not produce identity; it carries identity that has to be issued at the proofing layer first.

What's the Difference Between a Digital ID and a Digital Wallet?

In our work helping institutions and platforms procure identity infrastructure across the EU and adjacent markets in 2026, the question "what's the difference between a digital ID and a digital wallet?" lands on the procurement desk at least once a month. Usually it shows up as a confused budget line: someone has been told to "ship a wallet" or "adopt the digital ID", and the integrator is trying to work out whether those are the same purchase, two purchases, or one purchase with a misnamed scope. They are two different layers of the trust framework, and the conflation costs money. This post is how I usually walk through it on the procurement call.

What does each one actually do?

They live at different layers of the trust framework, and the layers are not interchangeable.

A digital ID is the cryptographic record that attests to who someone is. Concretely: a verifiable credential issued by a trust framework participant — a Member State authority, a notified eID scheme, a QTSP, or a document chip like the ICAO 9303 passport NFC chip. The credential carries the identity claim (the holder's verified attributes), it carries the issuer's signature, and it carries a binding back to the proofing event that produced it. Under eIDAS 2.0 (Regulation (EU) 2024/1183) and the EUDI Wallet Architecture Reference Framework the credential is referred to as a Person Identification Data (PID) attestation when it carries the core identity attributes, or as an Electronic Attestation of Attributes (EAA) when it carries sub-attributes like over-18 or driving entitlement. The signature on the credential is what makes it verifiable — anyone with the issuer's public key can check that the attributes have not been tampered with and that they came from the trust framework participant the credential names.

A digital wallet is the holder-side container that stores those credentials and presents them. Concretely: software on the user's device (or sometimes hardware) that holds the private keys the user binds to credentials, holds the credentials themselves, runs the presentation protocol when a verifier asks for an attribute, and decides what to disclose (the holder can present the full credential, or — under selective disclosure protocols like SD-JWT under RFC 9901 — only the predicate the verifier needs). The wallet does not issue identity. It does not write attestations. It carries what was issued upstream and controls how the user presents it downstream. The European Commission's EUDI Wallet specifications describe the wallet as "a product that allows users to securely request, store, and share personal identification data and electronic attestations of attributes" — three verbs (request, store, share) that all sit on the holder side, none of which include issue.

The honest read is that the two answer different questions. Digital ID answers who is this person. Digital wallet answers how does this person carry the proof of who they are and reveal only the part the verifier needs. You can have a digital ID without a wallet (a passport with an NFC chip is one; a national eID card on a plastic token is another). You can have a wallet without any credentials in it (every EUDI Wallet on launch day in a Member State that has not yet provisioned its PID issuer is one). And in most regulated use cases — KYC, AML, eIDAS-bound signing — you need both, sourced from different parts of the stack.

Why does the difference matter in procurement?

Because buying a wallet does not get you identity, and buying identity does not get you the holder-side mechanism the regulator expects.

I have watched this confusion play out in procurement calls more than once. A Munich-based mid-market insurance carrier we worked with had its product CTO read about the EUDI Wallet rollout under Regulation (EU) 2024/1183, assume the EUDI Wallet is the identity, and budget accordingly. The integrator joined the project and discovered that the wallet is just the container — the platform still needed an identity-proofing service to issue the credential the user would carry in the wallet, or to consume a wallet-presented PID attestation that the Member State issuer had already provisioned. The original line item covered neither. Six weeks of replanning followed.

The mirror confusion is just as common. A Helsinki-based fintech bank's compliance lead procured an identity verification service for KYC, anchored on document scan plus liveness, got a verified record per onboarded customer, and was then told by the Finnish regulator that under the upcoming eIDAS interoperability rules the customer presentation had to be wallet-mediated. The verification produced a credential, but the credential lived in the bank's database, not in the customer's wallet — the bank had no way to issue it back to the customer's wallet without an additional integration. That integration is a separate piece of work from the verification flow itself, and almost nobody scopes it in the original procurement. The pattern is one we covered from a different angle in our earlier post on whether a single digital identity works everywhere — wallet portability is not the same as identity portability.

The pattern across both confusions is the same: the trust framework expects credentials to be issued at the identity layer and carried at the wallet layer. If the platform buys only one layer, the layer it didn't buy becomes the bottleneck. The way I usually structure the procurement conversation is by drawing the three roles on a whiteboard: issuer (produces the credential), holder + wallet (carries and presents the credential), verifier (consumes the credential). The platform almost always sits at issuer-and-verifier — and forgets the holder-and-wallet layer until the regulator's audit asks how the user actually presents the credential the platform issued.

The concrete examples of credential-issuance categories that a procurement team actually compares in 2026 include notified national eID schemes, QTSP-issued professional certificates under the EU Trusted List, and chip-anchored identity-verification services like IdentiGate's identity verification — passport NFC chip read for the 179 ICAO 9303 countries plus document authenticity and biometric face match for every remaining country, producing an AdES-bound record under eIDAS Article 26. The concrete examples of wallet implementations are different: the EUDI Wallet reference implementation and the Member State pilots being rolled out under Regulation (EU) 2024/1183, plus the broader category of device-OS wallet products carrying ISO mDL credentials. These are not the same procurement.

How do EUDI Wallets and identity issuers fit together in 2026?

The wallet is the container Member States must provision by 6 December 2026; the credential issuers are who fills it.

Regulation (EU) 2024/1183 (eIDAS 2.0) requires every Member State to offer at least one EUDI Wallet to its residents by 6 December 2026. The wallet itself is software/hardware on the user's device, certified against the Architecture Reference Framework, capable of receiving and presenting credentials. What it carries — the Person Identification Data (PID) attestation containing the core identity attributes, plus subsequent Electronic Attestations of Attributes (EAAs) covering things like driving licence, professional qualification, age, residence — is provisioned by issuers operating under the trust framework.

The PID issuer in each Member State is typically the national identity authority — the entity that already issues identity cards or eIDs. The EAA issuers can be more diverse: a university issues a verifiable diploma into the holder's wallet, a national driving authority issues a digital driving licence, a healthcare authority issues a prescription entitlement. Each EAA is a separate credential, issued under its own trust framework rules, and the wallet's job is to carry them all and let the user present whichever the verifier requests.

What I see in the institutional integration work in 2026 is that most EU service providers are wiring up to consume wallet-presented credentials — they are the verifier in the architecture diagram. Most are not setting up to be EAA issuers themselves, because that requires registration under the trust framework and a different compliance posture. Where IdentiGate sits in this picture is at the identity-proofing primitive layer that produces the binding evidence underneath the credentials — chip-anchored proof that the person presenting the document is the document's rightful holder, AdES-bound to the proofing event under eIDAS Article 26. That evidence can be consumed by a PID issuer who provisions an attestation into the wallet, or it can be used standalone in service flows that have not yet wired up wallet integration (most non-EU and many EU verifiers in mid-2026 still fall in this category). It is foundation-layer evidence, not a wallet, not a PID issuer's attestation — but the input that makes either of those trustworthy.

What I'd push back on hardest is the marketing framing that the EUDI Wallet replaces the identity-proofing layer. The wallet is a container with a presentation protocol. The credentials it carries still have to come from somewhere, and that somewhere is the identity-proofing service that produced the underlying attestation. The wallet doesn't shortcut the proofing — it standardises how the proof gets presented after the proofing has happened. Conflating the two is what produces the procurement gaps I described in the previous section.

Three-layer trust framework diagram showing the relationship between digital ID issuer (produces the credential), digital wallet (holder-side container that carries and presents credentials with selective disclosure), and verifier (consumes the credential). IdentiGate sits at the identity-proofing primitive layer that produces the binding evidence underneath the credential.

So where does IdentiGate sit — issuer side or wallet side?

Identity-proofing primitive — the layer underneath both, that issuers consume to produce credentials and that standalone verifiers consume directly.

This is the question the procurement calls eventually get to once the issuer / holder / verifier triangle is drawn. IdentiGate is not a digital wallet. We do not ship the EUDI Wallet software, we do not provide the holder-side credential storage, we do not run the presentation protocol when a verifier asks the user for an attribute. The European Commission's EUDI Wallet Reference Implementation and the Member State wallets built on it occupy that layer; we do not compete with them and we do not duplicate them.

IdentiGate is also not, strictly, a credential issuer in the eIDAS PID/EAA sense — we are not a notified PID issuer for any Member State, and the credential schemas we produce are not (yet) registered as Member State EAAs. What we ship is the Identity Verification primitive — the chip-anchored verification of who the person is, producing an AdES-bound record under eIDAS Article 26 — and the Unified Digital Identity primitive that ties multiple documents the same person holds into one cryptographic anchor. These are foundation-layer primitives that a PID issuer can consume to produce a wallet-ready attestation, or that a verifier can consume directly when the wallet integration isn't there.

The way this plays out in 2026 deployments is two-track. Track one — the wallet-mediated flow — the user presents a PID attestation from their EUDI Wallet to a verifier, the attestation was provisioned by the Member State PID issuer, the underlying proofing event used the chip-read primitive (ours or a peer service's). The verifier consumes the wallet-presented attestation under the eIDAS trust framework rules. Track two — the direct flow — the user verifies their identity through the IdentiGate Identity Verification product, the AdES record binds the verification to the document chip read, and the verifier consumes the record directly. Both tracks are live in production today; the second track is what most non-EU verifiers use because they sit outside the eIDAS wallet framework, and what many EU verifiers still use in 2026 because the wallet provisioning pipeline is not yet fully wired up.

The honest read for any platform-side procurement lead is to ask which track they actually need to support, and to stop conflating the two. If the platform serves only EU users whose Member States have launched wallet PID provisioning, the wallet-mediated track is the future-proof choice. If the platform serves cross-border users where the EUDI Wallet does not reach (non-EU travellers, transitional EU residents without provisioned wallets, third-country suppliers, Member States that miss the December 2026 deadline), the direct track stays operationally relevant for years. Most platforms we work with end up shipping both, and routing per user. That is what the procurement spec should describe — not a single layer, but the two tracks and the routing between them. The disclosure-protocol details that sit underneath the wallet-mediated track — selective disclosure, predicate proofs, holder binding — are covered in our earlier post on zero-knowledge proofs, and the consumer-side counterpart to this procurement-side framing is in our post on how to know if a website is who they say they are.

Sources

Primary — eIDAS and EUDI Wallet framework

Primary — verifiable credential and selective-disclosure standards

Primary — ICAO and document chip standards

ICAO Doc 9303 — Machine Readable Travel Documents

About the author

Mairi Kutberg is co-founder of IdentiGate. She focuses on identity-proofing operations under eIDAS, NIS2, AMLR, the AI Act, the EHDS, and adjacent regulatory frameworks, and on the institutional reality of running cross-border identity verification at scale.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.