# Passkeys and recovery

The client MPC share is encrypted inside the MoonPay Wallets embedded wallet runtime. Passkeys, identity-backed encryption, or both protect the key that decrypts this share. The available wraps determine how a user recovers wallet access.

## Client share protection

The client share is encrypted with AES-256-GCM under a per-user Data Encryption Key (DEK). The DEK is generated in the browser and wrapped once per enrolled passkey, so any enrolled passkey can unlock it, and enrolling a new passkey adds a wrap without touching the encrypted shares. Every ciphertext is bound to its expected user, credential, wallet, and chain context through authenticated data, so ciphertext presented in the wrong context fails to decrypt instead of yielding usable key material.

With passkey-only protection, MoonPay Wallets stores ciphertext and public metadata but does not hold the passkey secret needed to decrypt the DEK. [Identity-backed encryption](/security/identity-backed-encryption) adds a separate wrap under a MoonPay-operated KMS key. An eligible signed-in session can unlock that wrap without a passkey.

Practical consequences for integrators:

* Your application JavaScript cannot read the client share; it is handled in a cross-origin MoonPay Wallets iframe that your page cannot inspect.
* Wallet operations require scoped presence tokens. The accepted proof depends on the operation and available wraps. See [Sessions and presence](/security/sessions-and-presence).
* A stolen session does not replace a passkey for a passkey-only wallet. An eligible identity-backed session can authorize signing and ephemeral-signer actions.
* If a user imports an existing key, MoonPay Wallets splits it into MPC shares and discards the complete imported key after the import ceremony.

## Recovery

Recovery depends on the wraps already stored for the user's DEK:

* For passkey-only wallets, the user signs in and asserts an enrolled passkey on the new device. Synced passkeys can provide that credential.
* For identity-backed wallets, a signed-in user can recover access through a usable identity-backed wrap, even after losing every passkey.
* The server-side signer share is operated with encrypted backup and recovery controls, using hybrid encryption (RSA-OAEP-SHA256 key encapsulation with ChaCha20-Poly1305 data encryption), so signer infrastructure loss does not imply wallet loss.

<Note>
  A passkey-only user who loses every enrolled passkey and synced copy cannot recover the client share. Enabling identity-backed encryption afterward cannot recover that wallet. The user must add the identity-backed wrap while a passkey can still unlock the DEK.
</Note>

## Export

A user can run an explicit export ceremony to assemble and export the full private key:

* Export requires a fresh passkey assertion, or email OTP for an eligible identity-backed user with no passkeys and a verified email address.
* A session alone cannot authorize private-key export. The export ceremony reconstructs the key in the user's browser.
* Export remains available even to compliance-blocked accounts, preserving the user's ability to take custody of their funds. See [Compliance and data handling](/security/compliance-and-data-handling).

Export remains the escape hatch for self-custody. Developers should treat export as a user-controlled custody operation, not as a backend retrieval API.

## Related

<CardGroup cols={2}>
  <Card title="Passkeys & Key Protection" icon="shield-check" href="/wallets/passkeys">
    The full DEK, wrap, and enrollment lifecycle.
  </Card>

  <Card title="Identity-backed encryption" icon="fingerprint" href="/security/identity-backed-encryption">
    Recovery through account access and the trust placed in MoonPay's KMS.
  </Card>

  <Card title="Export a Wallet" icon="key" href="/wallets/embedded-wallets/export-a-wallet">
    How users explicitly export a wallet private key.
  </Card>
</CardGroup>