Microsoft Retires SMS and Voice MFA on February 1, 2027. The Part That Breaks First Is Account Recovery.

Two dates, one of them optional and one of them not.

On September 1, 2026, Microsoft starts automatically moving users who are still enabled for SMS or voice toward passkeys. On February 1, 2027, Microsoft-provided SMS and voice authentication in Microsoft Entra ID retires. There is no opt-out from that second date.

For an MSP, this is not a change notification to file away. It touches how users sign in, how they recover their own accounts, and how you sequence work across every tenant in your book.

Why users who never touch SMS are still in scope#

A user can authenticate with Microsoft Authenticator every single day and never consciously pick SMS. That does not put them out of scope.

Scope comes from policy. If SMS is still enabled in the tenant's Authentication Methods Policy, that user is in range for Microsoft's migration behavior and will get nudged to set up a passkey. The September change applies to users enabled for SMS or voice through the modern Authentication Methods Policy or through applicable legacy MFA settings.

Check the migration status on that same page. If it does not read Complete, the tenant has not fully moved off the legacy authentication method settings, and you need to review the legacy MFA configuration (opens in new tab) as well. Microsoft's retirement scope deliberately covers both paths. If that migration is still outstanding for a customer, start with the consolidation onto the Authentication methods policy before touching anything here.

The dependency that breaks quietly: self-service password reset#

Sign-in is the part everyone watches. Recovery is the part that fails silently.

Picture an SSPR policy that requires two methods, and a user who has Microsoft Authenticator and SMS. Today that satisfies the requirement. Now add a passkey and the user appears to have three methods: passkey, Authenticator, SMS.

They do not. Passkeys are not currently listed as an SSPR verification method, while Authenticator and SMS are. When SMS disappears, that user's recovery posture changes even though their everyday sign-in got stronger.

Microsoft's own guidance is to register more methods than the minimum required for reset, so users have somewhere to go when one method is unavailable. Treat that as the design rule, not a nice-to-have.

Build the inventory before you change anything#

Two places to look, in this order.

The policy. Entra ID > Authentication methods > Policies. Review SMS and Voice call: are they enabled, and which users or groups are targeted?

The users. Entra ID > Authentication methods > Activity > Registration. The user registration details report shows each user's registered methods plus whether they are MFA capable, passwordless capable, SSPR enabled, SSPR registered, and SSPR capable. It covers Mobile phone, Microsoft Authenticator, FIDO2, Email, Software OATH, and Windows Hello for Business.

Policy tells you who is in scope. The registration report tells you who would actually be stranded.

Buy time without missing the deadline#

You may not want Microsoft prompting hundreds of customer users for passkeys on September 1, in the middle of a week you did not plan for.

Microsoft provides a temporary opt-out from the automatic passkey enablement (opens in new tab) and the associated registration campaign changes during the migration period. It gives you room to run your own plan. It does not delay the February 1, 2027 retirement.

The other way to avoid the automatic behavior is to move users out of SMS and voice scope before September 1, and Microsoft recommends exactly that if you do not want the automatic migration. One condition: only after those users have another working method.

So the decision per tenant is short. Ready, and you start migrating now. Not ready, and you delay Microsoft's automatic rollout while you communicate and stage the work yourself.

Stage the rollout with registration campaigns#

Microsoft's default user experience is not the only option. Entra ID > Authentication methods > Registration campaign lets you nudge users toward either a passkey or Microsoft Authenticator, include or exclude specific users and groups, and configure the snooze experience while you manage the campaign.

One limitation shapes everything: a tenant can target only one method at a time. Running a passkey campaign for one group while running an Authenticator campaign for another is not available, so sequence matters.

Option A, straight to passkeys. For organizations ready for passwordless: SMS users, passkey registration campaign, validate, remove SMS.

Option B, Authenticator first. For organizations that are not: SMS users, Authenticator registration campaign, validate Authenticator, remove SMS. Run the passkey campaign later.

Option B is the one that saves customer relationships. It gets SMS out of the tenant on Microsoft's timeline without forcing a passwordless rollout on a business that has not budgeted the change management.

Synced or device-bound, decided per population#

If you do go to passkeys, the type can vary by who the user is.

Synced passkeys live in credential managers such as Apple iCloud Keychain or Google Password Manager and follow the user across their devices. Microsoft recommends them where strict device-boundary control is not required, which describes most information workers.

Device-bound passkeys keep the private key on one specific device. That includes passkeys in Microsoft Authenticator, FIDO2 hardware security keys, and other device-bound credentials. They fit populations where control over the physical credential matters, especially privileged accounts.

Worth knowing how the pieces interact: the registration campaign targets Passkey generically, while the Passkey and FIDO2 Authentication Methods Policy and its profiles decide which passkey types users are allowed to register. A workable default is synced passkeys for standard users, device-bound passkeys or security keys for privileged users, and Microsoft Authenticator for customers who are not ready for either.

Test recovery separately from sign-in#

Before removing SMS anywhere, go to Entra ID > Password reset > Authentication methods and answer three questions. How many methods are required to reset? Which methods are allowed? Do the affected users actually have enough non-SMS methods registered?

Microsoft lets organizations require either one or two methods for a reset, and users who fall short cannot complete SSPR at all. They call the helpdesk instead, which is your helpdesk.

Aim one method above the requirement. Require one, target at least two registered. Require two, target at least three where it is practical. A recovery design that holds up after February 2027 usually looks like passkey or Windows Hello for authentication, Authenticator plus email or another supported option for SSPR, and helpdesk verification with a Temporary Access Pass as the emergency path.

Then test the recovery path on its own. A user can sign in perfectly and still be unable to reset their own password.

Where CloudCapsule fits#

One tenant is a task. Fifty, one hundred, or five hundred tenants is a program.

We built a new SMS and Voice Retirement report in CloudCapsule to answer the discovery question quickly across a whole customer base: which users are affected by the retirement, which still have phone authentication methods registered, and which have already moved to passkeys.

We are also working the Microsoft migration controls into the experience, so where the platform supports it you can understand and manage the rollout without opening dozens of customer tenants. The question we want answered in one screen: who is affected, why, and what happens next.

The migration order we would follow#

February 1, 2027 sounds distant. Spread across a customer base, it is not.

The real risk is not the user who authenticates by SMS every morning. It is the dependency nobody has looked at: SMS still allowed by policy, SMS sitting behind Authenticator as a backup, SMS quietly satisfying half of a two-method SSPR requirement, users who never registered anything stronger, and customers who start getting Microsoft's passkey prompts before you have told them it is coming.

Six steps, in order:

1. Discover. Find SMS and voice exposure in the policy.
2. Validate. Determine who actually depends on it, and check SSPR.
3. Control. Delay the automatic rollout where you need the time.
4. Migrate. Authenticator, synced passkeys, or device-bound passkeys, chosen by population.
5. Verify. Confirm both authentication and recovery work without SMS.
6. Enforce. Remove SMS and voice before Microsoft does it for you.

Microsoft published end user notification templates (opens in new tab) if you want a starting point for the customer comms, and the full announcement (opens in new tab) covers the scope in detail.

Handled well, this stops being a Microsoft deadline and becomes the reason every customer you manage finally modernized authentication.