If the old phone still works: do not wipe it, do not hand it in, do not reset it. Move the codes across first, confirm the new phone produces a working code on every account, and only then erase the old device.
If the old phone is gone: stop looking for a shortcut. Use your backup codes if you have them. If you do not, you are going through the exchange's account recovery process, and the fastest route through it is a complete, accurate first submission.
Case one: moving your authenticator while the old phone still works
This is the easy version, and the only real risk is doing the steps in the wrong order. People wipe the old phone first because the shop wants it, or because the new one is already set up and the old one feels finished. That single act converts case one into case two.
The order that works:
- Install the authenticator app on the new phone first. Do not sign in to anything else yet.
- Use the app's own transfer function if it has one. Most authenticator apps can export accounts to a QR code that the new device scans. This moves the secrets directly, without going near the exchange.
- Where there is no export, re-enrol account by account. Sign in to each service on the old phone, turn off two-factor authentication, turn it straight back on, and scan the new code with the new phone. Tedious, reliable.
- Test every account on the new phone. Actually log in. A code that looks plausible is not the same as a code the server accepts.
- Only now wipe the old device. Factory reset, and remove it from the exchange's list of trusted devices while you are at it.
If the app is Google Authenticator
Google Authenticator has a transfer function, and it turns step two into a two-minute job instead of an account-by-account slog.
- On the old phone, open the app, open the menu and choose the transfer or export option.
- Tick the accounts to move. The app draws a QR code, or several if you have a lot of entries.
- On the new phone, install the app, choose to import, and scan each code in turn.
Two things about it that catch people out. The QR code contains the actual secrets in plain form, so do not photograph it, do not screenshot it, and do not leave it on screen while somebody else is in the room — treat it exactly as you would a written list of your passwords. And exporting does not remove the entries from the old phone; the old device keeps producing valid codes until you wipe it, which is why step five matters.
Recent versions of the app can also sync entries to a Google account. If you have that switched on, the entries may simply be there when you sign in on the new phone. That is convenient, and it also puts your second factor inside your Google account — which is an argument for making sure that account is not itself protected by a text message.
One thing worth doing during step three, since you are already in the security settings: check whether the account still accepts a text-message code as an alternative. If it does, the work you just did is capped by the strength of that fallback, which is a different argument entirely.
Some exchanges hold withdrawals after a security change. Binance says withdrawals, P2P selling and payment services are disabled for 48 hours after a 2FA reset, and Binance.US says withdrawals are not possible for 24 hours after a password change. That is expected behaviour, not a sign that something went wrong. If you were planning to move funds the same day, do the migration earlier in the week.
Case two: the old phone is lost, stolen or already wiped
Work through these in order and stop at the first one that gets you in.
You saved backup codes
Use one to sign in, then immediately enrol the new device and generate a fresh set of codes. The old set is spent. This is the whole reason writing them down at setup is worth two minutes.
You have a second method registered
A passkey, a hardware key or an email-based verification path will usually let you in and let you reset the authenticator from inside the account. Check the sign-in screen for a "try another way" style option before assuming there is none.
The authenticator app synced to a cloud account
Some apps back the secrets up to a platform account. Sign in to the app on the new phone with that same account and the entries may simply reappear. Whether this is on depends on what you chose at install time.
None of the above
Account recovery through the exchange. This is an identity process, not a support request, because it has to tell you apart from someone claiming to be you. On Binance it starts on the sign-in verification pop-up: choose the method you no longer have and click "Security verification unavailable?". Its guide says a request marked Under Review can take up to 48 hours, that withdrawals are disabled for 48 hours after the reset, and that if the request is denied or you cannot reach the reset at all, the next step is customer support from inside the site.
How to get through exchange 2FA recovery in one pass
Four things keep a recovery request from stalling, and all of them are in your hands.
Submit from the device and network you normally use. A request that arrives from an unfamiliar country on a brand new device looks exactly like what the process is designed to catch.
Give the details only the real owner would know — when the account was opened, the last few transactions, which payment method was used, the address a withdrawal went to. Vague answers extend the review.
Use the email address on the account. It is the one address the exchange can already tie to you.
Then wait, and do not submit it twice. A second request adds a second case for the same problem, not speed; no platform page we have read describes a way to jump the queue, and anyone who contacts you offering one is running a script we have written about separately. If the request is refused, read the stated reason before trying again, and fix that one thing.
List every account your authenticator holds
An authenticator usually holds more entries than you can name from memory — and the forgotten ones are the ones that matter least right up until they matter enormously. An old exchange account with a balance in it. The email provider. The domain registrar. A password manager.
Making the list takes ten minutes and it is best done now, on the phone that still works, rather than reconstructed later from memory. Open the authenticator, write down every entry it contains, and against each one note two things: whether you have backup codes for it, and whether a second verification method is registered.
What that list gives you is a rescue order for the bad version of this. If the phone goes into a river, you will not have time to work out which accounts to rescue first while also being locked out of most of them. With the list in front of you, the sequence is obvious: the email account first, because it is the recovery path for the others, then anything holding money, then everything else at leisure.
Keep the list with the backup codes rather than on the phone. It contains no secrets — an account name is not a credential — so it does not need to be protected the way the codes do. It only needs to survive the same event.
Setting the new phone up so this does not happen twice
While the enrolment screens are open anyway, three changes make the next phone swap uneventful.
Save the backup codes properly this time, somewhere that is not the phone and not the same cloud account the phone syncs to. Register a second method — a passkey, or a hardware key — so that a lost phone is an inconvenience rather than a crisis. And keep the inventory described above up to date, because it is the thing that turns the next migration into a chore rather than an emergency.
Then, once you are back in, spend two minutes in the account's device and session list and remove anything you do not recognise, including the phone you just retired. That list is worth knowing how to read before you need it in a hurry.
Written against the two-factor and account-security pages an exchange publishes for its own users, read in September 2026, and the generic behaviour of the mainstream authenticator apps. The reset route and the 48-hour holds come from Binance's guide to resetting 2FA, and the 24-hour hold after a password change from Binance.US's security page, both read on 3 October 2026. Exact menu names differ between exchanges and between the app and the website, so treat the wording above as a description of the step rather than a label to search for. This describes the procedure rather than a case we worked; how an individual recovery is decided is not something we can tell you.