What happens with your EUDI Wallet when you lose your phone?

Summary: What really happens to your EUDI Wallet when your phone disappears or you switch to a new one? The answer exposes a deeper conflict in Europe’s digital identity architecture — one where portability meets unmovable cryptographic trust. Dive in to see why your credentials can’t be copied, yet your identity remains recoverable.

At the recent Digital Asset Saloon organized by KPMG where the etonec team spoke around on the European Digital Identity (EUDI) Wallet, a vivid discussion evolved around the following question: "If I lose my phone, do I lose my EUDI Wallet and all my credentials?"

It's a great question because it exposes a tension in the regulations that surrounds Europe's entire identity architecture. On the one hand, General Data Protection Regulation (GDPR) guarantees data portability. On the other, the EUDI framework makes it impossible to move device-bound credentials between devices.

Why? Because a credential’s trust doesn’t come from the data it contains. It comes from the private key generated and stored inside the secure hardware of your phone, which the issuer trusts and which cannot be extracted or copied. If that key could move, the verifier would no longer know which device (or which person) produced a signature.

Is portability of data the same as portability of credentials?

Not at all. GDPR lets you move information. But EUDI credentials aren't just information — they're cryptographic artifacts tied to secure hardware. Your iCloud photos can be downloaded and re-uploaded. Your PID (the electronic equivalent to the physical ID document) cannot.

The Architectural Reference Framework (ARF) is unambiguous: you can’t back up a PID or any device-bound attestation in a way that lets it work on a new phone — the original issuer has to be involved again.

This is exactly how Apple Wallet and Google Wallet already behave. When you move to a new phone, your cards don’t simply “restore”; your bank has to re-provision new payment tokens tied to the new device’s secure element. That re-verification step — entering a CVV, an SMS code, or an in-app confirmation — is the bank authenticating you before issuing fresh cryptographic credentials to different hardware, i.e., a different phone. EUDI wallets follow the same logic: the list can move, but the keys must be re-issued.

So what can be migrated?

Migration Objects is the tool used for such migrations but that is more an inventory list than a backup. For your EUDI wallet the migration object will contain "a list of PIDs and attestations… together with the information needed to request (re-)issuance… [and] the transaction log." But it does not contain any private keys.

Its purpose is narrow: "The only function of the Migration Object is to simplify [re-issuance]."

So it helps a new EUDI Wallet to know what to request — but never gives it the ability to simply restore a credential.

As a side note, Topic B - Re-issuance and batch issuance of PIDs and Attestations explores how Wallets could quietly refresh and replace credentials in the background using OpenID4VCI refresh tokens.

How do you recover your Wallet?

Recovery works the same either way:

1. Revoke the old Wallet

2. Activate a new Wallet

3. Pull in the Migration Object

4. Request fresh credentials for everything that was tied to the old device's secure hardware

If you still have the old device, you generate the Migration Object locally. If not, your Wallet Provider retrieves it from backup. The ARF doesn't specify where that backup lives — only that recovery must work "independent of whether the User still has access to their existing Wallet Unit".

The requirement from Annex 2 explains that the wallet must record enough information in the Migration Object for the new device to request each PID or device-bound attestation again. That means noting the type of attestation and which provider issued it, along with where that provider can be reached. It must not include the attributes themselves and must never include any private keys.

Why can't private keys just be backed up?

Because that would break the trust model.

If private keys were exportable, malware, cloud breaches, or rogue apps could copy them. The ARF spells this out clearly that Wallets do not allow [private key] extraction under any circumstances. Lose the device, and those keys are gone forever — which is precisely the security guarantee the system is built on.

Is seamless migration ever possible?

The ARF does allow one alternative: remote signing, where the private keys live in a certified cloud Hardware Security Module (HSM) — a tamper-resistant security appliance used by banks and governments to store and use keys without ever exposing them. This model appears in high-assurance or multi-device environments — banks, enterprises, government roles — where devices can’t be trusted or continuity is critical. It’s powerful, but it’s not the model used for everyday EUDI wallets, and it doesn’t replace the device-bound approach citizens will encounter.

So do you lose your wallet when your phone is gone?

No. You lose one instance of it. The keys can't be cloned. Once the wallet is deactivated, it cannot be misused because revocation is immediate. Everything can be recovered — not by copying keys, but by requesting fresh credentials tied to your new device's secure hardware.

It's a clean separation: portability protects your rights; device-bound cryptography protects the trust model.

This means that recovery is a huge opportunity space. Like interoperability, it's hard but high value to get right — which means the Wallet Providers & Issuers who execute well on the UX will win. The ones who make re-issuance feel instant, who cache Migration Objects intelligently, who pre-authenticate common issuers, who turn a potential support nightmare into a 90-second flow — those are the ones users will trust when it matters.

The real question probably isn't what happens when you lose your Wallet. It's who builds recovery features so well that users never think about device-bound keys at all.