Retiring SMS MFA in Microsoft Entra ID: a practical guide

From 1 February 2027 Microsoft stops sending SMS codes and voice calls for Entra ID sign-ins. This guide takes you from “who still depends on SMS?” to switching SMS off on your own date – with a fix for every account type: internal users, administrators, service and shared accounts, and guests.

What is changing and when

From 1 February 2027, Microsoft stops sending SMS codes and voice calls for Entra ID sign-ins. Global Administrators and external users follow on 1 July 2027 (MC1426371). After that, only a telecom provider your organisation contracts through the Microsoft Security Store can still deliver them.

Date	Milestone
1 Sep 2026	Passkeys become the default for users in the SMS/voice scope (rolling out gradually)
30 Oct 2026	Telecom providers can be chosen in the Microsoft Security Store
early Jan 2027	Finish the provider setup, if you need one – at least 4 weeks before the retirement
1 Feb 2027	Microsoft-provided SMS and voice stop for users
1 Jul 2027	The same for Global Administrators and external users

A user whose only second factor is SMS or a phone call will be stuck at sign-in on that date. The job is therefore simple to state: find every account that depends on SMS or voice, move it to another method, then switch SMS off yourself. Do this for all account types – internal users, administrators, service and shared accounts, and guests – because each needs a different fix.

This guide covers the assessment and the migration. A review of your Conditional Access policies as a whole is a separate topic.

Before you start

Licences: Microsoft Entra ID P1 for Conditional Access and authentication strengths (included in Microsoft 365 Business Premium, E3 and E5). PIM and access reviews need Entra ID P2 or ID Governance.
Roles: Global Reader covers the whole assessment (both scripts); Authentication Policy Administrator and Conditional Access Administrator for the changes.
Tools: PowerShell 7 with the Microsoft Graph PowerShell modules.
Two break-glass accounts that every Conditional Access policy in this guide excludes.

Step 1 – Check your tenant with Microsoft’s script

Start with Microsoft’s own entra-sms-voice-usage-analyzer on GitHub. It answers the first question: is SMS/voice switched on in your Authentication methods policy, and for whom?

The script Get-SmsVoicePolicyUsers.ps1 reports:

the state of the SMS and Voice call methods and their scope (included and excluded groups and users), exported to CSV
the state of the registration campaign (enabled, disabled or Microsoft-managed)
an impact summary against the retirement timeline

What you need:

Microsoft Graph PowerShell (modules Authentication, Identity.SignIns, Groups)
the scopes Policy.Read.All and Group.Read.All
at least Global Reader, Authentication Policy Administrator or Security Reader

Two tips from running it in a real tenant:

If Connect-MgGraph fails with a browser (WAM) error, connect with -UseDeviceCode.
If you see an assembly conflict for Microsoft.Graph.Authentication, start a fresh PowerShell 7 window and make sure only one version of the Graph modules is loaded.

The limit of this script is that it tells you who is allowed to use SMS, not who has it registered or relies on it. If the policy targets All users, that list is your whole tenant, so you need the next step.

Step 2 – Find out who has SMS and what else they have

My follow-up script, entra-sms-mfa-inventory on GitHub, reads every user’s registered authentication methods and answers the question Microsoft’s script leaves open: who has SMS or voice registered, and do they have anything else? That matters most in tenants where MFA registration was never tracked or managed from the start. It is read-only and writes one CSV row per user with a phone method, phone-only users first.

For each account the output shows:

UPN, display name, admin role yes/no, member or guest
every registered method, including the phone methods (mobile phone, alternate mobile phone, office phone) and the user’s preferred MFA method
a PhoneOnly flag: the phone is the only usable second factor. Email, security questions and a Temporary Access Pass don’t count; any other method does, including method types Microsoft adds later
last sign-in and days since, so you can tell active accounts from dead ones

What it needs: PowerShell 7 with the Microsoft.Graph.Authentication module, the delegated scopes AuditLog.Read.All and User.Read.All, the role Reports Reader (or Security Reader / Global Reader) and Entra ID P1. Disabled accounts aren’t part of Microsoft’s registration report, so they don’t appear in the result. Download and README: github.com/ameldzehverovic/entra-sms-mfa-inventory.

Sort the result into these groups. Each one gets its own fix in the steps below.

Group	How you recognise it	Fix
Internal users, phone-only	`PhoneOnly` = True, `userType` = member	Step 3
Administrators, phone-only or phone + other	`isAdmin` = True (check PIM-eligible roles and role-assignable groups too)	Step 3, with a phishing-resistant method
Service and shared accounts with SMS	Function mailboxes, service accounts, accounts several people share	Step 4
Guests from a company tenant	Guest whose domain has its own Entra tenant	Step 5
Guests with a personal address	Gmail, Hotmail, Outlook.com, GMX, iCloud and similar	Step 6
Long-inactive accounts	`DaysSinceSignIn` 90+ or empty	Disable or delete; don’t migrate them
Users with a phone and another method	`PhoneOnly` = False	Nothing to do; SMS simply disappears later

One more check is worth the effort: look at what people actually use, not only what is registered. Export the sign-ins from the beta Graph endpoint (/beta/auditLogs/signIns) and count the authenticationDetails entries with the method “Text message” or “Phone call”. In one tenant I assessed, many accounts had SMS registered, but only three used it to sign in during a whole week. Those three are the people to call first; the rest mostly need a nudge.

Step 3 – Internal users and administrators: require a better method

Put the SMS-only users in a group and let Conditional Access ask them, at their next sign-in, for a method that is not SMS. Entra then walks them through registering one; they confirm with SMS one last time to do it.

Create an authentication strength without SMS. Entra admin center → Entra ID → Authentication methods → Authentication strengths → New authentication strength. Name it e.g. “MFA without SMS/voice” and tick: Passkeys (FIDO2), Windows Hello for Business, Microsoft Authenticator (push and passwordless), software OATH token, hardware OATH token, certificate-based MFA. Leave every SMS and voice combination unticked. Don’t use the built-in “Multifactor authentication” strength: it still accepts SMS.
Create the group. Entra ID → Groups → New group, security, assigned membership, e.g. SG-MFA-SMS-Migration. Add the SMS-only users from step 2 with Members → Bulk operations → Import members (CSV of UPNs), or with New-MgGroupMember.
Tell people before you switch anything on. One short mail: what changes, on which date, which app to install, a two-minute how-to, and who to call. Users who get an unannounced prompt call the helpdesk or ignore it.
Create the Conditional Access policy. Entra ID → Conditional Access → Policies → New policy:
- Users: include SG-MFA-SMS-Migration; exclude your two break-glass accounts
- Target resources: All resources
- Grant: Require authentication strength → “MFA without SMS/voice”
- Enable policy: Report-only for 3–7 days, check the sign-in logs (Conditional Access → Report-only), then On
Optionally nudge as well. Authentication methods → Registration campaign: target the same group with Microsoft Authenticator and allow only a few snoozes. Since September 2026 Microsoft manages this campaign for passkeys by default, so check what it is already doing before you change it.
Track progress. Re-run the step 2 script weekly. The number of SMS-only members in the group should fall to zero before 1 February 2027.

Administrators follow the same steps with one difference: use the built-in Phishing-resistant MFA strength (passkey/FIDO2, Windows Hello for Business, certificate) instead of your custom one. Global Administrators technically have until 1 July 2027, but an admin account protected by SMS is the easiest target in your tenant, so do them first, not last. Check PIM-eligible roles and role-assignable groups as well, not only active assignments.

What can go wrong

A policy blocks registration where the user is. If another policy only allows security-info registration from the office network, people at home cannot complete the prompt. Give them a Temporary Access Pass (Authentication methods → Temporary Access Pass) or let them register in the office.
No company phone, no private app. Offer a FIDO2 security key or a hardware OATH token. Both work without a smartphone and cost little compared with an exception you must track for years (see the last section).
Old phones. Passkeys in Microsoft Authenticator need a reasonably current iOS or Android; on older phones use Authenticator push or a security key.
Lost phone on the day. Helpdesk issues a Temporary Access Pass; the user registers a new method with it.

Step 4 – Service and shared accounts

An SMS number on a service or shared account usually means a person’s mobile is the key to an account several people or a system depend on. Don’t move these to Authenticator; fix the account instead.

Service accounts used by scripts or apps: replace them with an app registration (certificate or secret) or a managed identity with only the permissions it needs. A workload identity doesn’t do MFA at all, so the SMS problem disappears with the account.
Shared mailboxes signed into directly: give the people who use them Full Access and Send As, then block sign-in for the mailbox account. Check the sign-in logs first: a shared mailbox that shows interactive sign-ins is being used with a password someone knows.
Function or device accounts that must sign in (kiosk, warehouse scanner, meeting room): limit them with Conditional Access to compliant devices and your office network instead of MFA, and document the exception (last section).
Accounts nobody can explain: disable them, wait 14 days for complaints, then delete.

Step 5 – Guests from partner companies

A guest from a company with its own Entra tenant can either register MFA in your tenant or bring the MFA from their tenant. The second option is usually better: one method for the guest, no registration for you to support, and their company stays responsible for it.

Option A – MFA registered in your tenant

Conditional Access → New policy.
Users: include “Guest or external users” → select B2B collaboration guest users (add B2B collaboration member users if you have them); exclude break-glass accounts.
Target resources: All resources (or at least Exchange, SharePoint and Teams).
Grant: Require authentication strength → “MFA without SMS/voice”.
Report-only first, then On.

At the next sign-in the guest is asked to register Microsoft Authenticator or another allowed method in your tenant.

Option B – trust the MFA from their home tenant

Entra admin center → Entra ID → External Identities → Cross-tenant access settings.
For all partners: Default settings → Inbound access settings → Edit inbound defaults → Trust settings → tick Trust multifactor authentication from Microsoft Entra tenants.
For selected partners only: Organizational settings → Add organization (tenant ID or domain) → Inbound access → Trust settings → Customize settings → tick the same option.
Keep the Conditional Access policy from option A. Trust settings change where MFA is done, not whether: without a policy that requires MFA for guests, the trust does nothing.

With trust on, a guest who has already done MFA at home is let straight in. A guest whose company has no MFA is asked to register in your tenant, exactly as in option A, so the two options work together.

What can go wrong

If your policy asks for an authentication strength (for example phishing-resistant), the method used at home must meet it; push or SMS at home won’t satisfy a phishing-resistant requirement.
A partner that still uses SMS at home is affected by the same retirement; your trust setting doesn’t change that.
Trusting device compliance or hybrid join from partner tenants is a separate tick box. Leave it off unless you know how the partner manages devices.

Step 6 – Guests with personal email addresses

Guests who use Gmail, Hotmail, Outlook.com, GMX or iCloud addresses have no Entra tenant at home, so there is no MFA you could trust. They are covered by the same Conditional Access policy as in option A of step 5 and must register a method in your tenant.

Make sure the guest policy from step 5 includes them. “B2B collaboration guest users” covers guests who sign in with a one-time email code, a Microsoft account or Google.
Allow a method they can use without your company: Microsoft Authenticator, or another authenticator app if third-party software OATH tokens are enabled in your Authentication methods policy.
Tell them before it happens. A private guest who gets an MFA prompt from an organisation they barely know often thinks it is phishing.
Note that the one-time email code they may use to sign in is their first factor, not a second one. It doesn’t count as MFA.

Use the migration to clean up as well:

Remove guests who no longer need access. Many personal-address guests never sign in again after the first project. Disable guests with no sign-in for 90+ days and run quarterly access reviews (ID Governance → Access reviews) on the rest.
Limit who can invite. External Identities → External collaboration settings → Guest invite settings. “Anyone in the organisation can invite” is how a tenant ends up with hundreds of private-address guests nobody owns.
Consider whether a private address is acceptable at all for guests who see internal data. A guest account tied to a company domain can be trusted, reviewed and offboarded through the partner.

Step 7 – Switch SMS off yourself

When the step 2 script shows no SMS-only accounts left (or only documented exceptions), turn SMS and voice off on your own date rather than waiting for Microsoft’s. You choose the day, the helpdesk is ready, and nobody is surprised on 1 February.

Check self-service password reset first. Users who reset their password with an SMS code lose that path too. Make sure they have another SSPR method, such as Authenticator or an alternate email address.
Narrow before you remove. Entra admin center → Entra ID → Authentication methods → Policies → SMS → change the target from All users to a small group, e.g. SG-MFA-SMS-Exceptions. Do the same for Voice call. Everyone outside that group loses SMS at once, and you can still help individuals.
Watch for a week. Sign-in logs → filter on failures with MFA-related errors, and helpdesk tickets.
Turn it off. Authentication methods → Policies → SMS → Enable = off → Save. Same for Voice call.
Check the legacy settings. Authentication methods → Policies → Manage migration should say Migration complete. If it doesn’t, the old per-user MFA settings (Text message to phone, Call to phone) and the SSPR method list can still offer phone methods. Untick them there too, then complete the migration.
Re-run both scripts. Microsoft’s script should report SMS and voice as disabled; yours should show no account depending on them.

If you decided to keep SMS for a few people through a telecom provider from the Microsoft Security Store, leave SMS enabled only for the exceptions group and set the provider up at least four weeks before 1 February 2027.

When you can’t move everyone

The steps above are the best case. Real organisations have people who won’t or can’t follow them: no company phone and no wish to put Authenticator on a private one, a senior manager who refuses, a device account that cannot do MFA at all. Exceptions are acceptable; untracked exceptions are not. An account left outside MFA is exactly the one an attacker with a phished password will find.

Be realistic about the politics as well. Boards are often more willing to bend the security posture than to ask a few people to adapt to IT’s standard. If that happens, make sure the decision is made consciously, by the people who own the risk, and written down.

Before you grant an exception, offer the alternatives:

a FIDO2 security key or a hardware OATH token for people without a company phone – no private phone involved
Windows Hello for Business on a company laptop for people who only work at their desk
a telecom provider from the Microsoft Security Store, if SMS really must stay for a few accounts (it costs money; let that be part of the decision)

If an exception is still needed, handle it like this:

One group for all exceptions (e.g. SG-MFA-Exceptions), excluded from the MFA policies by that group only, never by individual user.
Compensating controls in a separate policy for that group: sign-in only from the office network and/or compliant company devices, block sign-in from abroad, block legacy authentication, shortest practical session lifetime.
A register with owner, reason and expiry for every account (example below).
Expiry and review. Every exception ends on a date; a quarterly access review on the exceptions group makes the owner confirm it again.
Alerting. Alert on any sign-in by an exception account from outside its allowed conditions.
Risk acceptance. If you are ISO/IEC 27001 certified, record each exception as a risk acceptance in the risk treatment plan (Annex A 5.17 Authentication information, 8.5 Secure authentication). An auditor will ask for it.

Account	Reason	Approved by	Compensating controls	Expires
warehouse.scanner01	Shared device, cannot do MFA	Head of Logistics	Compliant device + office network only	31 Mar 2027

Checklist

Run Microsoft’s script: is SMS/voice enabled, and for whom?
Run the method inventory: who has SMS, who is SMS-only, members vs guests
Check sign-in logs for who actually uses SMS
Disable or delete inactive accounts instead of migrating them
Create the authentication strength “MFA without SMS/voice”
Internal SMS-only users: group + communication + Conditional Access policy
Administrators: phishing-resistant MFA, including PIM-eligible roles
Service and shared accounts: workload identities, delegated access, or documented device restrictions
Partner guests: guest MFA policy + cross-tenant MFA trust
Private-address guests: guest MFA policy, clean-up, invite restrictions
SSPR: everyone has a non-SMS reset method
Exceptions: one group, compensating controls, register with owner and expiry
Narrow SMS/voice to the exceptions group, watch a week, then switch off
Legacy MFA/SSPR settings: migration complete, phone methods unticked
Re-run both scripts to confirm

Sources

MC1426371 – Passkeys by default and retirement of Microsoft-provided SMS and voice authentication (Message Center, updated 15 Sep 2026)
microsoft/entra-sms-voice-usage-analyzer (GitHub)
ameldzehverovic/entra-sms-mfa-inventory (GitHub) – the inventory script from step 2
Microsoft to stop providing telephony-based authentication methods for MFA in February 2027 (Office 365 for IT Pros)