Passkeys on a new phone: check the provider, not just the screen lock

Appuza editorial desk · Updated 2026-10-25 · 5 min read · AI-assisted source-based guide

A successful fingerprint prompt is only part of the story

Passkeys can make sign-in feel beautifully simple: approve a prompt with a device unlock method and continue. That simplicity can hide an important migration question. Where is the credential stored, and what makes it available on another device? The fingerprint or face check is the local approval action; it is not a complete explanation of the storage provider, synchronization path, or account recovery process. Before replacing a phone, identify those dependencies while the old device still works.

Start with the accounts whose loss would cause the most disruption: primary email, device accounts, password manager, and services used for work or essential administration. For each, record whether you use a passkey and which provider or device holds it. You do not need to copy secret material into this inventory. A simple note such as stored in the system password provider or stored in the password manager is more useful than an unexplained statement that the account uses biometrics.

Distinguish a synced credential from a device dependency

Different passkey arrangements can behave differently across devices. Some are available through a synchronized credential provider; others depend on a particular authenticator. A security key is also a physical object with its own availability considerations. Do not infer portability merely because the same service supports passkeys on both phones. Read the provider's current instructions for the actual path you use, including operating-system and application requirements.

For example, Bitwarden documents passkey storage in its vault and describes supported export and credential-exchange routes. Those details are specific to its implementation and supported platforms. Google's account documentation describes creating and managing passkeys for a Google Account. Neither page establishes that every passkey in every application transfers through the same process. Keep the distinction between the account you are signing into and the provider storing the credential: they can be different services, each with its own recovery dependency.

Add and verify the replacement before removing the original

When the service permits multiple authenticators or sign-in methods, establish the replacement while you still have working access. Use the service's known account settings rather than a link in an unsolicited message. After adding the intended method, test it in a context that actually requires sign-in. Merely reopening an already authenticated app does not demonstrate that the new credential works. Keep the original device secure and available until the test succeeds.

The test should answer a concrete question: can I sign into this account using the replacement phone and the intended credential provider without relying on the old phone? If a prompt silently asks the old device to approve the attempt, you have learned that the dependency remains. That may be an acceptable temporary arrangement, but it is not proof that the old device can be erased. Observe the flow carefully and document which device or provider completed the approval.

Preserve recovery without weakening ordinary sign-in

A passkey does not eliminate the need to understand account recovery. Check the service's supported recovery options and confirm that contact details remain current. Where recovery codes or other backup materials are offered, store them in a way that does not depend entirely on the device being replaced. The useful question is not whether you have a backup somewhere, but whether you can reach it when the primary device and its active sessions are unavailable.

Avoid treating recovery as an excuse to scatter credentials across ordinary notes, email drafts, and screenshots. That creates more copies to protect and makes it difficult to know which are current. Choose a deliberate storage method and label the material by account and purpose. If a password remains enabled alongside a passkey, it still deserves a strong, unique value. Adding a convenient sign-in method does not automatically remove the risks associated with other methods that the account continues to accept.

Understand what an export does and does not prove

A password-manager export can be useful during a move, but format matters. Bitwarden's documentation distinguishes formats and notes passkey support in its JSON export path. A CSV containing ordinary usernames and passwords should not be assumed to preserve passkeys. Direct transfer mechanisms also depend on support in both applications and the relevant operating system. Check the current compatibility instructions instead of assuming that a menu labeled export includes every credential type.

Even when a format contains the relevant data, a file sitting on disk is not the same as a verified working sign-in on the destination. Preserve the original provider until you have checked representative accounts through the new route. Handle exported material according to its sensitivity and encryption status. Do not upload it to an online converter merely because the destination rejects a file. If compatibility is unclear, adding a new supported passkey through the account itself may be more understandable than attempting an undocumented conversion.

Retire old devices and keep a small credential map

Once the replacement works, review the account's listed passkeys and devices. Remove credentials or sessions that should no longer remain active, following the service's own controls. Be precise: removing an old device session and deleting a passkey are different actions, and either may leave the other unchanged. If the phone is being sold or traded in, complete the operating system's official preparation and erasure process only after the account checks are finished.

Keep a short map of important accounts, their intended credential provider, and the location of recovery instructions. Update it when you add a hardware key, change password managers, or switch ecosystems. This is not a secret database; it is a description of dependencies. Its value becomes clear during the next device change, when you can distinguish a credential that will be available through a verified provider from one that still depends on a device in your hand. The best migration outcome is predictable access, not simply a successful unlock animation.

Official references

These are editorial walkthroughs based on documented features, not claims of a completed device test. Product behavior can change. Send a correction.