Microsoft Is Phasing Out SMS Codes—Set Up Recovery Before You Lose a Device

Microsoft says it will begin phasing out SMS as an authentication and account-recovery method for personal Microsoft accounts. Its recommended direction is passkeys plus a verified email address.

The right response is not to delete every old sign-in method tonight. It is to build a recovery setup that still works after a lost phone, broken laptop, changed number, or credential-manager problem.

A practical target is:

• two independent ways to sign in, and
• one recovery channel you have tested.

That gives you the security benefit of passkeys without making one device the key to your entire digital life.

Feature check: Microsoft, Apple, Google and FIDO passkey guidance was checked on August 2, 2026. Microsoft’s support page says SMS will be phased out, but it does not give one universal cutoff date. Available sign-in and recovery methods can differ by account, device, organisation and service.

What is changing—and what is not

Microsoft’s current support guidance says personal accounts are moving away from SMS codes because of phishing, SIM-swap and fraud risk. Users may be prompted to add a passkey and verified email instead.

A passkey replaces a typed password with a cryptographic credential. The service stores a public key; your device or credential manager holds the private credential and unlocks it with a PIN, fingerprint or face check. Because the passkey is tied to the legitimate website or app, it is designed to resist ordinary lookalike-site phishing.

That improves sign-in security. It does not remove the need for account recovery.

You can still be locked out when:

• the only device holding a device-bound passkey is lost or damaged;
• the account that syncs your passkeys is itself inaccessible;
• a work administrator restricts which credential managers are allowed;
• a service supports passkeys for sign-in but uses a different recovery process;
• you replace devices before confirming that credentials have synced correctly.

The important distinction is simple: a safer key is not automatically a complete recovery plan.

Use the two-route-plus-recovery rule

Before making an account passwordless, identify these three elements:

Not every website permits every combination. The framework is a test: if all three boxes ultimately depend on the same phone or cloud account, the setup is not genuinely independent.

Step 1: Map your “root accounts” first

Start with accounts that can reset or unlock other accounts:

• your primary email;
• your Microsoft, Apple or Google platform account;
• your password or passkey manager;
• work or school identity accounts;
• your mobile-carrier account;
• financial and government accounts with high recovery costs.

Draw a tiny recovery map:

Microsoft account -> recovery email -> email account -> passkey manager
Passkey manager -> Microsoft account

That example contains a loop. If access to either side depends entirely on the other, one lockout can trap both.

Break the loop by adding an independent route, such as a separately secured recovery email, another supported passkey location, a spare hardware key, or an administrator recovery process. Which route is appropriate depends on the service and your risk level.

Step 2: Secure the recovery email before relying on it

Microsoft is steering personal-account recovery toward verified email, so that mailbox becomes more valuable.

Before adding it as a recovery method:

1. Give it a unique password if it still uses passwords.
2. Add a passkey or phishing-resistant second factor where supported.
3. Review its own recovery email, phone and signed-in devices.
4. Make sure its recovery path does not depend only on the Microsoft account it is meant to recover.
5. Store any backup codes outside the mailbox itself.

A recovery address that you cannot access independently is decoration, not recovery.

Step 3: Choose where the passkey will live

Passkeys can be synced through a credential manager or bound to a device, including some physical security keys.

Synced passkey: best default for convenience

A synced credential manager can make passkeys available across devices signed in to the same provider. Apple says iCloud Keychain synchronises passwords and passkeys across approved Apple devices using end-to-end encryption. Google Password Manager and Microsoft Password Manager similarly support saved and synced passkeys in their supported environments.

This is the practical default for many people because replacing a phone or laptop does not necessarily mean recreating every passkey.

The trade-off is concentration: access now depends partly on the security and recovery of the credential-manager account.

Device-bound or hardware passkey: useful independent backup

A passkey stored locally with Windows Hello or on a compatible physical security key may provide separation from your main synced provider. A physical key can also be kept away from your everyday devices.

The trade-off is recoverability. A device-bound credential does not magically reappear after loss or damage. For high-value accounts, use a spare key or another independent route rather than owning exactly one physical key.

Google’s Advanced Protection guidance, for example, recommends a primary security key and at least one backup key for people choosing that route.

Step 4: Add the new route before removing the old one

Microsoft’s troubleshooting guidance gives the right migration order: set up new passkeys first, then remove credentials that no longer apply.

For each important account:

1. Add the passkey.
2. Name it clearly when the service allows it, such as Personal iPhone — Aug 2026 or Spare security key.
3. Confirm where it was stored; do not assume the browser chose the provider you intended.
4. Add the independent route.
5. Verify the recovery email or other recovery channel.
6. Only then consider removing obsolete devices, phone numbers or passwords.

Some services keep the password as a fallback even after adding a passkey. Others allow a passwordless configuration. Do not assume the behaviour is the same across accounts.

Step 5: Run a recovery drill

A recovery method is untested until you have signed in without the device you normally use.

Use a private browser window or a secondary device and test:

• whether the passkey appears from the expected provider;
• whether cross-device QR sign-in works when needed;
• whether Bluetooth and proximity requirements are understood;
• whether your independent key or second device works;
• whether the recovery email is current and accessible;
• whether you can identify and revoke a lost-device passkey.

Do not deliberately lock yourself out or remove the final working method. The goal is to test the routes while you still have normal access.

Which setup fits you?

Most personal accounts

Use a synced passkey for daily sign-in, a well-secured verified email for recovery, and another supported passkey or backup method for important accounts. This route can be free using built-in platform tools.

People who switch between Apple, Android and Windows

Choose a credential manager whose current platform support matches the devices you actually use. FIDO notes that cross-platform providers can make passkeys available after a platform switch; otherwise, an old device may be used to sign in and create a new passkey. Confirm provider support before retiring the old device.

Administrators, founders and high-risk users

Consider two compatible physical security keys, stored separately, plus the organisation’s documented recovery route. Check policy with IT first: work accounts may restrict credential providers, devices or passkey types.

Four mistakes that create a new lockout risk

Creating a passkey on a shared device

Anyone who can unlock that device may be able to use its passkey. Google explicitly advises creating Google Account passkeys only on personal devices you control.

Making one phone responsible for everything

A phone that holds the passkey, receives recovery messages and controls the recovery mailbox is not three methods. It is one device wearing three hats.

Removing fallbacks before testing

A successful passkey creation prompt proves only that a credential was created. It does not prove it synced to the expected place or works from another device.

Storing backup material inside the account it unlocks

A recovery code saved only in the same mailbox or cloud drive is unavailable precisely when that account is inaccessible. Store sensitive recovery material securely and separately; never paste it into an AI chatbot or untrusted document.

A 30-minute migration checklist

• Minutes 0–5: List your root accounts and current recovery channels.
• Minutes 5–10: Secure and verify the recovery email.
• Minutes 10–15: Add one passkey to a low-risk account and confirm where it is stored.
• Minutes 15–20: Test sign-in from a private window or second device.
• Minutes 20–25: Add an independent route to one high-value account.
• Minutes 25–30: Record device names, review old credentials and schedule removal only after the new setup is proven.

Conclusion

Microsoft’s move away from SMS is a useful security upgrade, but “use a passkey” is only half a plan.

The safer migration is to build two independent sign-in routes plus one tested recovery channel, secure the accounts that control those routes, and remove old methods only after a real sign-in drill. Passkeys reduce phishing risk. Good recovery design reduces the chance that you lock yourself out while improving security.

Sources

• Microsoft Support — Microsoft to stop sending SMS codes for personal accounts
• Microsoft Support — Create and save a passkey
• Microsoft Support — Troubleshoot signing in with a passkey
• FIDO Alliance — Passkeys FAQ and technical overview
• Apple Platform Security — iCloud Keychain security overview
• Google Account Help — Sign in with a passkey instead of a password
• Google Account Help — Advanced Protection questions and backup security keys