A new Android phone can restore apps, settings, and account access so smoothly that it looks as though one protected package moved from the old device to the new one. Android's Restore Credentials feature makes that experience even more seamless: a participating app can retrieve a restore key and sign one account back in without asking the user to repeat the normal login flow.
That convenience creates an important security question for password-manager users. If the app opens under the right account, did Android also restore the encrypted vault, the key that decrypts it, and the recovery path? Not necessarily. Identity restoration and data restoration are separate systems, and a zero-knowledge vault adds another cryptographic boundary.
Quick answer
Android Restore Credentials restores an app's ability to authenticate one account with its server. It does not by itself restore the contents of a password-manager vault: passwords, vault-held passkeys, notes, files, the vault database, or the key that decrypts it. Those assets need a separate encrypted backup or sync process. Krypt does not use Restore Credentials as a vault-recovery mechanism; Krypt recovery requires the correct encrypted recovery data and the Rescue Key that you control.
Four keys that solve four different problems
The word credential is overloaded. Separating these four objects prevents most migration mistakes.
1. Android restore key
A restore key is an app-specific public-key credential created through Android Credential Manager. The app's server registers the public key. On a replacement phone, Credential Manager can return the corresponding restore credential, and the server verifies it through logic similar to a passkey sign-in. The result is account reauthentication, not decryption of arbitrary app content.
Restore keys are system-managed, tied to the application's package name, and hidden from normal passkey-management pages. Android's implementation guidance says they should be cleared when the user signs out because Credential Manager does not infer app-session state.
2. Passkey
A passkey is a user sign-in credential scoped to a website or service. It proves control of a private key without sending a reusable password. Although passkeys and restore keys can share WebAuthn-style server code, their lifecycle and purpose differ: users create and manage passkeys for accounts, while the operating system manages restore keys to reestablish app access.
3. Vault encryption key
A vault encryption key unlocks encrypted vault contents. It is not an app login token. In a zero-knowledge design, the vendor cannot simply fetch or reset that key from a server. The key may be derived from user-held material, protected by device hardware, or wrapped by another key, but the essential property is the same: server authentication alone must not silently become permission to decrypt the vault.
4. Encrypted backup and Rescue Key
An encrypted backup contains protected vault data that can survive device loss. A Rescue Key is user-controlled recovery material that can unlock or restore that backup through the product's defined recovery flow. The backup supplies the encrypted bytes; the Rescue Key supplies the missing authority. Neither is interchangeable with a restore key.
How Restore Credentials moves to a new phone
On the old device, a participating app asks its server for public-key creation options, creates a restore credential through Credential Manager, and registers the public key with the server. The private side can remain local or be eligible for end-to-end encrypted cloud backup when the user has Android backup, a Google Account, and a screen lock configured.
During replacement-phone setup, the restore key can arrive through either path:
- Cloud restore: Android downloads the restore key with the user's backed-up setup data when cloud backup is enabled.
- Device-to-device transfer: Android moves the restore key when the old and new phones are connected during setup, including a supported cable-transfer flow.
The new app calls Credential Manager for a RestoreCredential, sends its signed response to the relying-party server, and receives an authenticated app session. That can happen on first launch or alongside app-data restoration. The two operations remain independent: a successful restore-key exchange says nothing about whether a vault file was present, complete, current, or decryptable.
Limits that matter during device replacement
Restore Credentials is deliberately narrower than a full migration system. Android currently supports one restored account per app, so a multi-account app must select a primary or recent account. On devices with personal and work profiles, the key is available only to the profile set up first. The feature is for mobile-device restoration and does not bridge every form factor. It also requires compatible Android, Google Play services, and Credential Manager components.
A restore key is tied to one package name. A vendor's companion app with a different package needs a different key. A cloud-only key cannot appear on the new phone if the old setup was local-only and no direct transfer occurs. These boundaries are useful reminders: seamless does not mean universal.
Restore Credentials is not Android Auto Backup
Android Auto Backup is a separate, file-based service that can upload eligible app files to the user's Google Drive account. Apps can include, exclude, or opt out of that data backup. Restore Credentials works independently of app-data restoration and, according to Android's implementation documentation, independently of the manifest's allowBackup setting.
Krypt sets android:allowBackup="false", opting its app data out of Android Auto Backup. That fact does not itself disable the Restore Credentials API for every app. The relevant product truth is that Krypt does not implement Restore Credentials as a vault-recovery shortcut. Its vault recovery is a separate, deliberate encrypted process.
Why app reauthentication cannot unlock a zero-knowledge vault
Imagine an app server accepts a restore credential and issues a fresh session token. The server now knows that Android presented the registered app-specific key. It still does not possess the vault encryption key, and it should not be able to derive that key from the session token. Otherwise, a server-side account reset or restore event could become a vault-decryption event, weakening the zero-knowledge boundary.
A trustworthy replacement-phone flow therefore has two independent success checks:
- Identity: Can the app establish the correct account or sync relationship?
- Cryptographic recovery: Are the expected encrypted vault data and user-controlled recovery material both available and valid?
Passing the first check must never be treated as proof of the second. Users should verify record counts, recent changes, attachments, passkeys, authenticator entries, and the ability to open the real vault before erasing the old device.
Krypt's answer: deliberate recovery, not silent vault reset
Krypt is a zero-knowledge password manager and local-first encrypted vault. It uses intentional encrypted sync or backup workflows rather than Android Auto Backup. Recovery depends on the encrypted vault material plus the Rescue Key held by the user in an offline Recovery Kit. Krypt has no server-side reset that can reconstruct a lost vault key.
This adds responsibility, but it preserves the security boundary. A cloud account, fresh app session, or support request cannot silently replace your recovery secret. Before switching phones, create or refresh the supported encrypted backup, confirm that the Rescue Key is readable, and keep the Recovery Kit somewhere that will survive loss of both devices.
Replacement-phone checklist
- Update the old vault first. Finish pending changes, lock and reopen the vault, and confirm important records are present.
- Create or verify complete encrypted recovery data. If you need files and every vault surface on the replacement phone, verify a full encrypted Backup ZIP or complete
.syncbundlerecovery path. A DB-only merge covers passwords, passkeys, and secure notes but excludes files and photos. Keep a separate protected backup for anything excluded; never substitute a plaintext export or Android app-data copy. - Inspect the Recovery Kit. Confirm the Rescue Key is complete, legible, and stored separately from the phone.
- Keep the old phone intact. Do not factory-reset, trade in, or wipe it before the replacement passes recovery checks.
- Restore on the new phone. Use Krypt's documented encrypted recovery path, not an assumption created by automatic app installation or sign-in.
- Verify the real vault. Check recent passwords, secure notes, authenticator entries, passkeys, and files. If the chosen mode excludes a surface, confirm that its separate protected backup exists and restores successfully before erasing the old device.
- Test account recovery. Confirm the Rescue Key and backup work before the old device becomes unavailable.
- Retire the old device safely. Only after verification, remove old sessions where appropriate and erase the device through the platform's supported process.
FAQ
Does Android Restore Credentials restore passwords and vault data?
No. It transfers an app-specific restore key that a participating app can use with its server to reauthenticate one account. Passwords, notes, files, vault databases, and vault encryption keys are separate data that require their own protected backup or sync design.
Is an Android restore key the same as a passkey?
No. They use similar public-key infrastructure, but a passkey is a user-managed sign-in credential for a service. A restore key is system-managed, package-specific, hidden from passkey-management pages, and used to restore app access on a new device.
How do I recover Krypt on a replacement Android phone?
Use Krypt's deliberate encrypted sync or backup workflow and the Rescue Key kept in your offline Recovery Kit. Krypt opts out of Android Auto Backup, does not implement Restore Credentials as a vault-recovery shortcut, and cannot reset a zero-knowledge vault from a server.
Technical references
Google's Restore Credentials overview explains the cloud and device-to-device flow, account/profile limits, and separation from other credential types. The implementation guide documents WebAuthn-style registration, cloud eligibility, retrieval, deletion, and independence from allowBackup. Android's data backup overview describes Auto Backup, key-value backup, app data, settings, and restore behavior.
Use Krypt to keep passwords, passkeys, recovery records, and private files in a local-first encrypted vault with a recovery path you control.
