A Safe Passkey and Authenticator Migration Between Devices

Upgrading a phone is the moment most people lose access to an exchange account. The old handset still holds the authenticator secrets and the passkey, the new one is blank, and the account is still set to demand a code that only the old device can produce. The damage is rarely caused by the migration itself. It is caused by doing the migration in the wrong order, with no fallback, and with the old device wiped or reset before anyone has confirmed the new one actually works. This guide lays out a device-migration routine you can follow calmly over an afternoon: confirm what you can still log in with, generate and store backup codes, move one factor at a time, test with a small action before touching anything important, and only then retire the old hardware. It applies whether you are moving between two phones, from a phone to a tablet, or from an app to a hardware security key. The exact menu names differ between exchanges and app versions, so treat every screen description here as something to locate and confirm in your own account settings, the verification page, or the help centre rather than something fixed.

Map every factor before you touch anything

Start by writing an inventory of the ways your account can currently be accessed. On a sheet of paper or in a document that is not stored on either phone, list each factor separately: the password, the authenticator app codes, any passkey or biometric login, the email address tied to the account, the phone number used for SMS if you enabled it, and any withdrawal address allow-list. For each one, note which device currently holds it and whether you can still use it right now. This map is what stops you from removing a factor you can no longer replace.

Then log in once from the old device and once from a desktop browser, if you have one, without changing anything. The goal is only to confirm which paths still work and which have already quietly broken, for example an authenticator that was restored from a cloud backup with missing entries. If a path fails, stop and fix that specific path first through the account recovery flow described in the help centre before you begin any migration. Do not disable a working factor to make the list look tidy.

Finally, decide the order in which factors will move. The safe pattern is to add the new device as an additional factor while the old one is still active, verify it, and only then remove the old one. Removing first leaves a window where the account depends on a device you have not yet proven works.

Backup codes and recovery details first

Before any factor is added or removed, generate a fresh set of backup or recovery codes from the security settings area of the account. These are the only thing that will let you back in if the new device is lost, reset, or fails to register properly. Write them down or print them, keep them somewhere physically separate from both phones, and do not photograph them onto the device you are about to migrate. If the account shows an existing set you never stored, replace it now rather than later.

While you are in those settings, confirm the recovery email and recovery phone number are ones you still control, and that you can receive mail and messages on them from a device other than the phone being replaced. A recovery address you lost access to years ago is a common reason migrations stall. If the exchange lets you register more than one passkey or security key, add a second one on different hardware as a spare and label it clearly so you know which is which.

Record what you changed and when: the date, the factor added, the factor removed, and where the backup codes are stored. If you later need to contact support, this short log answers most of the questions you will be asked about what happened to the account.

Move one factor at a time and test it

Add the passkey or authenticator entry on the new device first, while the old device is still enrolled and switched on nearby. Follow the prompts in the security settings, approve the registration on the new device, and give it a clear name so it is distinguishable from the old entry in the list. If the exchange supports passkeys, the passkey is generally the smoother of the two to move because it is bound to the device or platform account rather than to a secret string you copy by hand.

Then test before you remove anything. Log out completely, log back in using only the new device, and perform one small, reversible action that requires confirmation, such as viewing a withdrawal address list or adjusting a security setting. A login alone is not enough proof: some confirmation prompts use a different factor than the login step. If the confirmation fails, the new factor is not fully enrolled, and you should stop and re-add it rather than deleting the old one.

Only after a successful test should you remove the old factor from the account. Then repeat the test once more, because the removal itself changes the account state. Keep the old device powered on and connected to the network, but no longer enrolled, until you are confident the new setup is stable.

Retire, wipe, and keep a fallback

Once the new device is the only enrolled factor and the tests pass, deal with the old one deliberately. Sign out of the exchange app, remove any saved credentials from the browser or password manager that pointed at the old device, and only then reset or trade it in. If you wipe the old phone while it is still an enrolled factor, you have removed your own fallback and made any later problem harder to solve.

After the migration, confirm the account still shows the recovery email and phone you expect, that the backup codes you stored are the current set, and that any withdrawal address allow-list is intact. Some settings are tied to the factor that created them, so it is worth walking through the security page once and checking nothing was silently reset.

Keep a written fallback plan for the next migration: where the backup codes live, which second device or security key holds a spare factor, and which official page you would use to start account recovery. Store the plan separately from the devices. If something does go wrong, contact support through the help centre using the account email, and describe the sequence of factors you added and removed with the dates from your log. Do not attempt repeated recovery attempts in quick succession, as that can complicate the review.

Risk boundary: Kenya Crypto Guide

Digital assets are volatile and derivatives can amplify losses. This website has no login, wallet connection, deposit form or customer-support chat. A referral link only records attribution; it does not guarantee access, pricing, rewards, approval or investment results. Availability can differ by residence, legal entity and product, so no regional access is assumed from language or branding alone.

Scenario checkpoint

• Write down every access factor, which device holds it, and whether it still works before changing anything.
• Generate a fresh set of backup codes and store them away from both phones.
• Verify the recovery email and phone are ones you can still reach from another device.
• Add the new passkey or authenticator entry while the old device is still enrolled.
• Log out, log back in on the new device only, and complete one small confirmation action as a test.
• Remove the old factor only after the test passes, then re-test and log the change with dates.