# Identity-Backed Encryption

With passkey-only protection, an enrolled passkey must unlock the user's Data Encryption Key (DEK). The DEK decrypts the client-side MPC keyshare. Losing every passkey and synced copy makes the client share unrecoverable. See [Passkeys & Key Protection](/wallets/passkeys).

Identity-backed encryption adds a second, independent wrap of the same DEK. This one is not held by an authenticator. It is held by a cloud key management service (KMS) key that MoonPay operates, and the KMS will only decrypt for a request that proves it is acting for one specific user of one specific app. The user's signed-in identity is what unlocks it.

With a usable identity-backed wrap, a signed-in user can unlock their wallet without a passkey, including after losing every passkey.

This page covers the model and the tradeoff. For the React SDK recipe that makes it the default for every account, see [Identity-First Setup](/wallets/identity-first-setup).

<Info>
  Both wraps protect one DEK. Enabling identity-backed encryption does not replace passkeys or weaken an existing passkey wrap, and a user can hold both at once. Either wrap opens the same DEK.
</Info>

## What this changes for your users

* They can read and write wallet keyshares, prove key ownership, and sign, using only their current session. No passkey prompt.
* If they have no passkeys at all, an email OTP can also serve as a presence proof.
* Losing every passkey no longer means losing the wallet, as long as they can still sign in.
* They can still enroll passkeys later, and adding one does not remove the identity wrap.

## What this does not change

Standard signing remains 2-of-2 MPC between the client share and the server-side signer share. The full private key is not assembled during signing. Identity-backed encryption changes access to the client share by adding a MoonPay-operated KMS route. See [MPC key custody](/security/key-custody).

Sensitive operations still require a fresh presence proof. Identity-backed encryption widens what can *produce* that proof; it does not remove the requirement.

## The trust tradeoff

This is a different guarantee from a passkey wrap, not a strictly better one, and it is worth stating plainly before you enable it.

* With a **passkey wrap**, the wrapping secret stays within the user's authenticator and wallet runtime. MoonPay does not hold that secret.
* With an **identity-backed wrap**, unwrapping depends on a KMS key that MoonPay operates. The release of that decryption is bound to the individual user, and each ciphertext is bound to the app and user it was created for, so one user's wrap cannot be used to open another's, and one app's wrap cannot be used in another app. But MoonPay operates the key, so MoonPay is in the unwrap path.

Identity-backed encryption allows recovery through sign-in but adds trust in MoonPay's KMS and identity authorization. See the [security model](/security/identity-backed-encryption) for account-compromise risks and the effect of keeping both wraps.

<Warning>
  Identity-backed encryption ties wallet access to the account a user signs in with. Anyone who can take over that account can unlock the wallet without a passkey. Account-recovery strength becomes wallet-recovery strength, so treat your sign-in flow accordingly.
</Warning>

## Presence proofs

A presence proof is a short-lived token that authorizes one sensitive operation. What a proof can authorize depends on how it was produced.

| Operation | Passkey assertion | Email OTP | Session alone |
| --- | --- | --- | --- |
| Read a wallet keyshare | Yes | Yes | Yes |
| Write a wallet keyshare | Yes | Yes | Yes |
| Prove key ownership | Yes | Yes | Yes |
| Sign | Yes | Yes | Yes |
| Provision or re-provision an ephemeral signer | Yes | Yes | Yes |
| Revoke an ephemeral signer | Yes | Yes | Yes |
| Export a private key | Yes | Yes | No |
| Enroll a passkey | Yes | Yes | No |
| Add a wrap | Yes | Yes | No |
| Remove the identity-backed wrap | Yes | No | No |

For an existing DEK, email OTP and session proofs require enabled, available identity-backed encryption and a usable identity-backed wrap. Email OTP also requires no enrolled passkeys and a verified email address. An eligible session can authorize signer provisioning and revocation without email OTP or a verified email address.

The SDK prefers an enrolled passkey. If the assertion fails or the user cancels it, an eligible session can authorize supported operations. See [Set up an identity-backed signer](/wallets/ephemeral-signers/identity-backed-setup) for the setup flow.

See [Presence Tokens](/authentication/user-authentication/presence-tokens) for the developer-facing flow.

## Removing passkeys and wraps

Two rules keep a user from stranding themselves:

1. A user may remove their **last** passkey when a usable identity-backed wrap remains. Without identity-backed encryption this is refused, because it would leave the DEK unopenable.
2. Removing the **identity-backed wrap** always requires a passkey assertion. A session cannot authorize it, and neither can an email OTP, because that would let the weaker proof destroy the stronger one's only alternative.

Together these mean a user can end up passkey-only, or identity-only, but not with nothing.

## Enabling it

Identity-backed encryption runs on shared MoonPay infrastructure, so there is nothing for an application to configure. MoonPay enables it per app during onboarding. The Wallets page of your dashboard shows whether it is on for the app you are viewing, as a read-only status.

If the status reads "Not enabled", passkeys are the only way your users can unlock their wallets. Contact MoonPay to turn it on. App enablement alone does not add a user's wrap. Use `enableAccountRecovery()` as shown in [Identity-First Setup](/wallets/identity-first-setup).

Once an app has stored its first identity-backed wrap, the configuration behind it is fixed for that app. Changing it would orphan every wrap already created.

## Related

<CardGroup cols={2}>
  <Card title="Identity-backed security model" icon="shield-check" href="/security/identity-backed-encryption">
    The KMS trust model, recovery limits, and session-authorized signer actions.
  </Card>

  <Card title="Identity-First Setup" icon="rocket" href="/wallets/identity-first-setup">
    The React SDK recipe: turn it on at signup, gate wallet actions on either wrap, and offer passkeys as an upgrade.
  </Card>

  <Card title="Passkeys & Key Protection" icon="key" href="/wallets/passkeys">
    How the passkey wrap works, the enrollment and deletion lifecycle, and what happens when passkeys are lost.
  </Card>

  <Card title="Passkeys and recovery" icon="shield-check" href="/security/passkeys-and-recovery">
    The recovery model these two wraps sit inside.
  </Card>

  <Card title="Presence Tokens" icon="lock" href="/authentication/user-authentication/presence-tokens">
    Minting and verifying the short-lived proofs that gate sensitive operations.
  </Card>

  <Card title="MPC key custody" icon="server" href="/security/key-custody">
    Why unwrapping a DEK is not the same as being able to sign.
  </Card>
</CardGroup>