Microsoft Entra SMS and voice authentication retirement: what admins need to do now

February 1, 2027 is the hard date that matters: Microsoft-provided SMS and voice delivery in Microsoft Entra ID goes away, and there is no opt-out from that enforcement date. If you still have users whose only workable MFA path is a text message or phone call, this stops being a future cleanup task and becomes an identity migration project.

The source article is directionally right, and the official Microsoft guidance makes the stakes even clearer. Starting September 1, 2026, passkeys become the default experience for users enabled for SMS or voice. Microsoft will automatically enable passkeys for those users in the Authentication Methods Policy, and the registration campaign is moved to Microsoft-managed for them. From that point on, users get nudged to register a passkey when they complete MFA. By default, those nudges have unlimited snoozes.

That last detail matters. A nudge with unlimited snoozes is not a migration plan. If you want this done before the deadline, you need an actual rollout: identify affected users, segment them, communicate early, and decide which populations genuinely need a telecom fallback.

What is actually retiring?

Microsoft is not banning SMS or voice as concepts. It is retiring Microsoft-provided telecom delivery for those methods in Entra ID. If you still need them for regulatory, operational, or regional reasons, Microsoft says you will be able to configure a customer-managed telecom provider through the Microsoft Security Store.

The timeline from Microsoft is straightforward:

There is a temporary opt-out for the September to February transition period, but not for the February 1 enforcement. After that date, if a user only has SMS or voice available and you did not configure a provider, Microsoft says the passkey registration prompt becomes blocking.

Why this is the right move

On security grounds, this is overdue. SMS and voice are phishable and weak compared with passkeys, Windows Hello for Business, or other phishing-resistant methods. For identity teams, Microsoft is basically forcing the move many orgs should already have made.

I think that part is good.

The messier part is operations. Some users still depend on telephony because they do not want work authentication on a personal phone, they have poor device coverage, or they sit in edge-case roles nobody designed for properly. Those users do not disappear because a roadmap says passkeys are better. If you run frontline, shared-device, or contractor-heavy environments, check now whether your plan is really a passkey plan or just wishful thinking.

If you need help designing that migration, this is exactly the kind of identity-heavy change where a proper AI and automation audit or targeted Microsoft Copilot and AI agents workstream can help with communications, service desk load reduction, and user-flow design. For the tenant-side reporting and remediation work, this also fits well with PowerShell and Azure automation.

How to find users still relying on phone methods

The most useful practical step is to audit your tenant now.

In the Entra admin center, go to Authentication methods and then User registration details. Filter by registered methods such as mobile phone, office phone, and alternate phone.

For repeatable reporting, PowerShell is better. Microsoft documents the user registration details report, including fields like methodsRegistered, systemPreferredAuthenticationMethods, and the user’s preferred MFA method. A simple Graph-based pull looks like this:

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"

$uri = "https://graph.microsoft.com/beta/reports/authenticationMethods/userRegistrationDetails"
$results = @()

do {
    $response = Invoke-MgGraphRequest -Method GET -Uri $uri
    $json = $response | ConvertFrom-Json
    $results += $json.value
    $uri = $json.'@odata.nextLink'
} while ($uri)

$phoneUsers = $results | Where-Object {
    $_.methodsRegistered -contains "mobilePhone" -or
    $_.methodsRegistered -contains "officePhone"
}

$phoneUsers |
    Select-Object userPrincipalName,userDisplayName,methodsRegistered,systemPreferredAuthenticationMethods,userPreferredMethodForSecondaryAuthentication |
    Export-Csv .\entra-phone-auth-users.csv -NoTypeInformation

If you want least privilege, Microsoft lists reader-style roles such as Reports Reader, Security Reader, Security Administrator, and Global Reader for the registration details report. Do not hand out broad admin access for a reporting exercise when a reader role will do.

What I would do

First, stop treating SMS MFA as a harmless fallback. Second, identify the users who have phone methods registered and separate them into three groups: easy passkey migrations, users who can move to another phishing-resistant method, and the genuinely hard exceptions.

For most organizations, the smart path is to move users off telephony entirely. Third-party telecom support is useful for narrow cases, but pricing will vary by provider and region, and metered per-message services have a habit of turning neglected exception groups into permanent cost lines. If you can avoid building a long-term dependency on paid fallback SMS, do it.

My practical takeaway: audit now, pilot passkeys early, and reserve telecom only for the users who can justify it.