Move Microsoft Authenticator to a new phone safely

01 · decision point

Inventory the account types before touching either phone

Microsoft Authenticator can hold several things that look similar in one list but recover differently. A personal Microsoft account, a work or school identity controlled through Microsoft Entra, and a third-party time-based code are not one interchangeable backup unit. Write down the service name, account label, sign-in owner, current recovery email, and whether the entry provides a push approval, a rotating code, or passwordless sign-in. Do not record the live code or QR secret in that inventory.

The distinction determines who can repair a failure. A consumer can manage a personal Microsoft account at the Microsoft account security page. An employee or student may need an authorized identity administrator to register the replacement device or issue a temporary access route. A third-party code belongs to the website that created its QR secret. Microsoft Authenticator can display that code, but Microsoft cannot reset the underlying Amazon, social, banking, or developer account for you.

02 · decision point

Understand what Microsoft backup does and does not promise

Microsoft's current support documentation says Authenticator can back up account credentials and related app settings so they can be recovered on a new device. It also states that backup and restore remain within the same device type: an iOS backup cannot be restored to Android, and an Android backup cannot be restored to iOS. Treat a platform change as a service-by-service re-enrollment project, not as a normal cloud restore.

The restored result varies by entry. Microsoft documents that some personal or passwordless accounts and work or school accounts may restore only the account name and then require sign-in or verification again. Third-party rotating-code entries may return through the backup when their secret was included. A visible tile after restore is therefore not proof that the new phone can complete a real sign-in. The verification test must happen at the service itself while another recovery route still exists.

03 · decision point

Create the backup from a trusted, current session

Update Authenticator from the official app store, open its settings, and confirm the backup control is enabled under the Microsoft-documented flow for the phone's operating system. On iOS, the recovery path also depends on the Apple account and iCloud configuration described by Microsoft. On Android, select the intended personal Microsoft recovery account. Label that account in your offline plan because choosing the wrong recovery identity can make a later restore appear empty.

Do not begin from an emailed QR code or a caller's instructions. A setup QR code can enroll a durable authenticator secret, and an attacker can use a fake one to redirect your approvals or persuade you to remove a working method. Start from the verified account security page or an employer-managed enrollment prompt you independently opened. If the old phone is already lost, preserve any browser or desktop session that still works and contact the correct provider or organization before changing credentials.

04 · decision point

Restore first, then prove each high-impact account

Install Authenticator from the official store on the replacement phone and choose the recovery option before adding unrelated accounts. Sign in with the same recovery account used for backup. Compare the restored list with the inventory. If an entry says action is required, follow the service's verified security page or your organization's instructions. Do not delete a duplicate simply because two tiles share a label; first determine which tile produces a valid response for the intended account.

Test email, the password manager, the Microsoft account that controls the backup, and work administrator access before routine services. Use a private browser or a separate signed-out session so the test actually invokes the new factor. Keep the original trusted session open until the replacement succeeds. A test should end with a complete sign-in and a review of registered authentication methods, not merely a push notification appearing on the new phone.

05 · decision point

Retire the old device only after recovery is independent

Once tests pass, review each important service's device and security-method list. Remove the old phone from the service where appropriate, replace stale recovery codes, and confirm a second method that does not depend on the replacement phone. A hardware key, a separately stored recovery code, or an independently recoverable passkey provider can prevent one lost handset from becoming the only route to email, work, and the password vault.

Erase or trade in the old phone only after the checks are recorded. If the device was lost or stolen, use the operating-system lost-device controls, revoke sessions where available, and notify the work or school administrator. An Authenticator backup is not a complete incident response: the attacker may also have an unlocked mail app, saved browser session, or mobile carrier access. Review those dependencies separately instead of assuming that restoring the authenticator closed every path.

Practical sequence

Use this two-phone migration sequence

1. 01

   List every Authenticator entry by owner and method without copying secrets or live codes.

2. 02

   Enable the documented backup on the old phone and record the correct recovery account.

3. 03

   Preserve the old phone, active browser sessions, and independent recovery codes during the move.

4. 04

   Restore on the same mobile platform and resolve every entry marked for additional action.

5. 05

   Complete fresh sign-ins to email, password manager, Microsoft, and work accounts before routine services.

6. 06

   Remove the old device and erase it only after a separate recovery route has been tested.

Original research element

Classify each tile by who can restore it

This original migration ledger prevents a restored icon from being mistaken for working access.

Continue on login.com

Related independent guidance

• Compare authenticator migration models before switching apps
• Separate Duo-managed enrollment from ordinary code transfer
• Map the accounts and devices your recovery plan depends on
• Respond safely to unexpected approval prompts