Wallet recovery methods
Wallet recovery basics
Recovering the embedded wallet is needed when a user logs into a new device or when access to the embedded wallet is lost.
Openfort embedded wallets have two core recovery modes: automatic recovery and user-based recovery. At a high-level, this setting modulates how the embedded wallet's recovery share is encrypted and stored.
-
Automatic recovery: The recovery share is encrypted with a combination of project entropy and Openfort's entropy. When logging into a new device, users can immediately access their embedded wallet.
-
Password recovery: The recovery share is encrypted by user-provided entropy. When logging into a new device, users must enter in their password to recover the embedded wallet on the new device. Once the embedded wallet has been recovered on a device, users will not need to enter their password on that devices again.
-
Passkey recovery: The recovery share is encrypted by a hardware-backed credential (WebAuthn). When logging into a new device, users must authenticate with their passkey (Face ID/Touch ID or device unlock) to recover the embedded wallet on the new device. Once the embedded wallet has been recovered on a device, users will not need to authenticate with their passkey on that devices again.
Choose your wallet recovery method
Use this guide to quickly compare our three recovery options and pick the one that best fits your product and platform constraints.
| Feature | Automatic recovery | Password recovery | Passkey recovery |
|---|---|---|---|
| User friction | None during normal use; silent recovery | User enters a password when recovering | System prompts to create/use a passkey; biometric-friendly |
| Security factor | App-managed recovery via server-issued encryption session | User-chosen secret (password) | Hardware-backed credential (WebAuthn/Passkey) |
| Backend required | Yes — one endpoint + server-only encryption share | No | No |
| Device portability | Seamless across devices (via your backend) | Works anywhere user knows password | Works across devices that sync passkeys (iCloud Keychain, Google Password Manager) |
| Platform support | Any | Any | iOS 16+/macOS 13+, Android 9+, modern browsers (Chrome/Safari/Edge with passkeys) |
| Best for | Highest conversion, invisible UX | Familiar flows, broad compatibility | Strong phishing-resistant UX with biometrics |
How to choose
- If you need the lowest friction and can run a tiny backend, choose Automatic recovery.
- If you want a familiar, backend-free option, choose Password recovery.
- If your audience has modern devices and you want biometrics + phishing resistance, choose Passkey recovery (React Native coming soon).
Automatic recovery
Automatic recovery restores a user's non-custodial wallet using a short-lived encryption session issued by your backend. This keeps day-to-day UX invisible while preserving ownership and security.
- Pros: Zero extra steps for users; seamless multi-device; minimal UX surface area.
- Cons: Requires a small backend endpoint; you must keep Shield keys secure.
- Requirements: A recovery endpoint that mints an encryption session (one API route).
Password recovery
Password and Passkey are user-based recovery methods (encrypted with user-provided entropy).
Password recovery protects the user's wallet with a secret they know. On a new device, users enter their password to recover and continue.
- Pros: No backend needed; universally understood; works on any platform.
- Cons: Users must remember/manage a secret; risk of weak or forgotten passwords.
- Requirements: None beyond configuring the recovery method in your app.
Passkey recovery
Passkey recovery uses platform passkeys (WebAuthn) for phishing-resistant, biometric-friendly recovery. Users authenticate with Face ID/Touch ID or device unlock.
- Pros: Strong, hardware-backed security; excellent UX with biometrics; resistant to phishing.
- Cons: Requires modern OS/browser support; users may need a platform account to sync passkeys across devices.
- Requirements: Device/platforms that support passkeys; configure recovery method.
Implementation notes
- Automatic recovery needs a one-route backend to mint a Shield encryption session used during recovery.
- User-based recovery (Password, Passkey) is fully client-side and only requires configuring your SDK's
recoveryMethod. - You can switch methods at any time; existing wallets continue to work, and new wallets use the newly configured method.