Microsoft Entra: scheduled end of life for SMS and voice call MFA - the full preparation guide

Microsoft has announced through Message Center notification MC1426371 that SMS and phone calls will no longer be supported as built-in authentication methods in Microsoft Entra.

This is a major change for organizations still relying on telecom-based MFA methods.

Starting September 1, 2026, passkeys will become the default authentication experience in Microsoft Entra. SMS and voice calls will then be phased out and moved to a customer-configured provider model through the Microsoft Security Store.

What is changing?

Microsoft is moving Microsoft Entra toward stronger, phishing-resistant authentication methods.

In practical terms:

• Passkeys become the default and recommended authentication method.
• SMS and voice calls will no longer be available as native Microsoft Entra MFA methods.
• Organizations that still need SMS or voice will have to configure a third-party telecom provider through the Microsoft Security Store.
• The transition starts in 2026 and ends on February 1, 2027.

Microsoft explains the change clearly in its blog:

As identity attacks grow more sophisticated in the AI era, organizations need stronger authentication methods that protect users from phishing, credential theft, and social engineering. To address these evolving threats, Microsoft Entra ID is updating its authentication experience by making passkeys the default phishing-resistant authentication method, helping customers reduce reliance on phishable methods such as SMS and voice.

Microsoft also states that passwords, SMS one-time passcodes, and voice-based verification remain vulnerable to phishing, interception, and social engineering attacks.

Scope of the change

Before going through the timeline, it is worth clarifying what is actually in scope:

• Public cloud environments only. Other cloud environments will follow on a later schedule, with advance communications.
• Azure AD B2C is out of scope. For Microsoft Entra External ID, the change is planned for next year with a separate announcement.
• Passkey support for B2B users and internal guest users is planned for the end of calendar year 2026. These users are in scope of the retirement.
• External MFA methods are not impacted, unless the same users are also enabled for SMS or voice.
• SSPR is in scope. See the dedicated section below.

Source: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement-faq

Timeline

September 1, 2026

Microsoft starts the phased deployment.

For tenants with users enabled for MFA through SMS or voice call, either through the modern Microsoft Entra authentication methods policy (AMP) or through legacy per-user MFA settings:

• These users will be automatically enabled for passkeys.
• They will be placed into a passkey profile allowing all types of passkeys.
• Microsoft will automatically set the registration campaign to Microsoft managed in order to prompt these users to register a passkey.
• The next time these users sign in and complete MFA, they will be prompted to register a passkey.
• By default, they will be able to snooze this prompt without limit.
• This ability to snooze should not be interpreted as a lack of urgency: starting February 1, 2027, users whose only available MFA method is SMS or voice will be blocked until they register a passkey.
• End users must be informed about the upcoming change. Microsoft recommends using the passkey deployment guide to prepare the environment.

An important nuance: the trigger for this auto-enablement is the policy scope, not actual usage. A user who is in the scope of the sms or voice policy but who authenticates exclusively with Microsoft Authenticator will still be auto-enabled for passkeys and nudged. Conversely, users already signing in with passkeys, Windows Hello for Business or another phishing-resistant method are unaffected, unless they are also enabled for SMS or voice.

Note that the registration campaign is a consequence, not a cause. Microsoft looks at the sms and voice scope, derives the impacted users, auto-enables them for passkeys, and only then updates the campaign to nudge them. Changing the campaign state does not change who is in scope. More on this in the opt-out section below.

This does not mean SMS and voice calls stop working immediately, but it marks the beginning of the migration path toward passkeys.

September 18, 2026

The Microsoft Security Store allows organizations to evaluate third-party telecom operators.

This option is meant for organizations that cannot fully transition to stronger authentication methods yet.

It should be treated as an exception path, not as the target state. Note that it comes with a cost: pricing varies by provider and region, and is typically charged per message depending on volume and geographic distribution. Migrating users to passkeys incurs no additional cost.

October 30, 2026

Organizations that want to continue using SMS or voice calls can select an available telecom operator through the Microsoft Security Store.

From this point, SMS and voice move from Microsoft-provided methods to customer-configured telecom provider methods.

February 1, 2027

Microsoft discontinues SMS and voice call authentication as native Microsoft Entra MFA methods.

Note: the official documentation and Message Center both state February 1, 2027, while the Microsoft PowerShell analyzer script and its README currently display January 28, 2027 in their impact summary. Plan against February 1, 2027, and keep the discrepancy in mind when reading the script output.

After February 1, 2027

Passkeys become the default and recommended authentication method.

Users whose only available MFA method is SMS or voice will be required to register a passkey during sign-in to continue accessing their account. This prompt will be blocking. Users must register a passkey before they can continue to sign in to their account.

Microsoft is explicit that users are not locked out: they face a blocking registration prompt they can no longer skip, not a denied sign-in.

There is no opt out from this February 1 behavior. It will be enforced for all tenants.

Migrate users to a phishing-resistant method or choose a telecom provider to continue using SMS or voice.

Why this matters

SMS and voice MFA have been useful transitional methods, but they are no longer strong enough for modern identity security.

They remain exposed to several risks:

• Phishing
• SIM swapping
• OTP interception
• Social engineering
• Voice call abuse
• User fatigue and poor assurance

Passkeys provide a stronger authentication model because they are phishing-resistant by design.

For Microsoft Entra environments, this is also consistent with the broader move toward passwordless authentication, Conditional Access, authentication strengths, and stronger identity protection.

Don't forget SSPR

The retirement applies across Entra, and that includes self-service password reset. SMS and voice call will no longer be available as SSPR verification options either, unless you configure a telecom provider through the Security Store.

Microsoft has also indicated that support for password change for users who sign in with a passwordless method is planned, with more details to come. If your SSPR flows currently rely on the mobile phone option for a large part of your population, this needs to be part of the same project, not an afterthought.

Source: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement-faq

What administrators should do now

Do not wait until 2027.

If your tenant still relies on SMS or voice MFA, start by identifying the impacted users and authentication method usage.

Understand the three different populations

This is where most inventories go wrong. There are three distinct questions, and they require three different tools:

1. Who is in scope of the sms and voice policies (AMP or legacy per-user MFA settings)? This is the only criterion that triggers the September 1, 2026 auto-enablement.
2. Who has actually registered a phone number as an authentication method?
3. Who actually uses SMS or voice call to authenticate?

A sign-in log query only answers the third question. It tells you who used the method, not who is enabled for it, and not who is registered for it. Someone in the scope of the sms policy who never uses SMS will not appear in the results and will still be impacted.

Identify who is in policy scope

Microsoft publishes a PowerShell script for this: https://github.com/microsoft/entra-sms-voice-usage-analyzer

Required role: Global Reader, Authentication Policy Administrator or Security Reader. Required Graph scopes: Policy.Read.All and Group.Read.All.

Install-Module Microsoft.Graph.Authentication -Scope CurrentUser
Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser
Install-Module Microsoft.Graph.Groups -Scope CurrentUser

.\Get-SmsVoicePolicyUsers.ps1 -TenantId "contoso.onmicrosoft.com"

The script reads the registration campaign state (a value of default means Microsoft managed), reads the sms and voice authentication method configurations, resolves the included and excluded targets to group display names, exports a CSV named SmsVoicePolicyTargets_<timestamp>.csv, and prints an impact summary.

How to read the output: an SMS state or Voice state of enabled combined with Include: ALL USERS means your entire tenant, minus exclusions, will be auto-enabled for passkeys on September 1. Any non-empty scope means you are in scope.

What the script does not do, and what you still have to do yourself:

• It does not expand group membership. You get a scope, not a nominative list of users.
• It does not cover legacy per-user MFA settings, which are in scope of the change.
• It does not measure any actual usage.

If you prefer to check it yourself without the script:

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

foreach ($m in "sms","voice") {
    $c = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/$m" -OutputType PSObject
    "=== $m : $($c.state) ==="
    "include:"; $c.includeTargets | ConvertTo-Json -Depth 3
    "exclude:"; $c.excludeTargets | ConvertTo-Json -Depth 3
}

If both come back as disabled, nobody is in scope, nothing happens to your tenant on September 1, and the opt-out described below is unnecessary. Check this before doing anything else. A lot of admins will apply the opt-out without ever verifying whether they are actually affected.

Identify who has registered a phone number

Use the User registration details report in the Entra portal: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/UserRegistrationDetails/fromNav/Identity

Or through Microsoft Graph, for a nominative export:

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

Get-MgReportAuthenticationMethodUserRegistrationDetail -All | Where-Object { $_.MethodsRegistered -contains "mobilePhone" } | Select-Object UserPrincipalName, IsMfaRegistered, IsPasswordlessCapable, @{n="Methods";e={$_.MethodsRegistered -join ","}} | Export-Csv .\PhoneRegisteredUsers.csv -NoTypeInformation

Measure actual usage

Three ways to do this, depending on what you have available. Pick the one that matches your environment.

With PS365

The quickest route. My PS365 module wraps the sign-in log query, handles paging and date conversion and exposes the authentication details in a usable form:

Install-Module PS365 -Scope CurrentUser
Import-Module PS365

Get-MgAuditLogSigninInfo -TimeRange Maximum -SmsVoiceMFASignInsOnly -ExportToExcel

TimeRange Maximum means the full retention window available in Entra ID, which is 30 days with an Entra ID P1 or P2 license and 7 days otherwise.

With Microsoft Graph only

If you would rather not add a module, query the beta endpoint directly. Note that choice: the v1.0 list endpoint does not reliably return the authenticationDetails property, which is exactly the one you need here.

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

$days = 1
$since = (Get-Date).AddDays(-$days).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
$uri = "https://graph.microsoft.com/beta/auditLogs/signIns?`$filter=createdDateTime ge $since&`$top=999"
$csvPath = ".\SmsVoiceUsageByUser_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv"

[System.Collections.Generic.List[PSCustomObject]]$signInLogList = @()

while ($uri) {
    $response = Invoke-MgGraphRequest -Method GET -Uri $uri -OutputType PSObject
    if ($response.value) {
        $signInLogList.AddRange([PSCustomObject[]]$response.value)
    }
    Write-Host "Retrieved $($signInLogList.Count) records"
    $uri = $response.'@odata.nextLink'
}

[System.Collections.Generic.List[PSCustomObject]]$phoneSignInList = @()

foreach ($signIn in $signInLogList) {
    $phoneMethods = @($signIn.authenticationDetails | Where-Object { $_.authenticationMethod -match "Text message|SMS|Voice call|Phone call approval" })
    if ($phoneMethods.Count -eq 0) { continue }

    $phoneSignIn = [PSCustomObject][ordered]@{
        UserPrincipalName = $signIn.userPrincipalName
        CreatedDateTime   = $signIn.createdDateTime
        ErrorCode         = $signIn.status.errorCode
        AppDisplayName    = $signIn.appDisplayName
        IPAddress         = $signIn.ipAddress
        Methods           = ($phoneMethods.authenticationMethod | Sort-Object -Unique) -join ","
    }

    $phoneSignInList.Add($phoneSignIn)
}

$phoneSignInList | Group-Object UserPrincipalName | ForEach-Object {
    [PSCustomObject][ordered]@{
        UserPrincipalName = $_.Name
        Attempts          = $_.Count
        Success           = ($_.Group | Where-Object { $_.ErrorCode -eq 0 }).Count
        LastUsed          = ($_.Group.CreatedDateTime | Measure-Object -Maximum).Maximum
        Methods           = ($_.Group.Methods -split "," | Sort-Object -Unique) -join ","
    }
} | Sort-Object LastUsed -Descending | Export-Csv -Path $csvPath -NoTypeInformation -Encoding UTF8

Two things to expect. On an active tenant, 30 days of sign-ins run into hundreds of thousands of records, and the filtering on authenticationDetails happens client-side because that property is not filterable server-side. Start with a smaller window for a first run. Throttling is also likely on large volumes, so add a Start-Sleep inside the loop if you get 429 responses.

With Log Analytics or Sentinel

If your sign-in logs are exported to a workspace, KQL is the better option, because you are no longer limited to the Entra retention window. Workspace retention is what applies, and it can go well beyond 30 days.

Check what you actually have before choosing a window:

SigninLogs
| summarize Oldest = min(TimeGenerated), Newest = max(TimeGenerated)

Then adjust lookback accordingly:

let lookback = 90d;
SigninLogs
| where TimeGenerated > ago(lookback)
| mv-expand AuthDetail = parse_json(AuthenticationDetails)
| extend AuthMethod = tostring(AuthDetail.authenticationMethod)
| where AuthMethod has_any ("Text message", "SMS", "Voice call", "Phone call approval")
| summarize Attempts = count(), Success = countif(ResultType == 0), LastUsed = max(TimeGenerated), Methods = make_set(AuthMethod) by UserPrincipalName
| sort by LastUsed desc

Keep these limitations in mind, whichever route you take:

• Filtering on successful sign-ins only would hide failed attempts, and a user failing an SMS challenge is just as much in scope. The queries above count both.
• The authenticationMethod values are not stable across scenarios (SMS, Text message, Voice call, Phone call approval (Authentication phone), Phone call approval (Office phone)), so a pattern match is safer than an exact list.
• A diagnostic setting does not backfill. If you enabled the export to Log Analytics two months ago, you have two months of history, whatever the retention setting says.
• Quarterly or seasonal users may simply not show up in any window you can query. Absence from the usage report is not proof that nobody needs the method.

Cross-referencing the three populations is what gives you an action plan. Users present in the policy scope export but absent from the usage report are the ones you can move out of the SMS/Voice scope first.

Remove users from the SMS and voice scope

This is the most effective lever, and it must be pulled before September 1, 2026.

"Move users out of SMS or Voice in AMP" can be misleading. The Authentication Methods Policy is not a container users are enrolled into. It is a set of per-method configurations, each with a state and its own includeTargets and excludeTargets. A user is in scope for SMS simply because the sms configuration is enabled and they fall within its include targets without being excluded. Moving users out therefore means one of three things: disabling the method, narrowing its include targets, or adding the users to its exclude targets. There is no separate operation.

Check policyMigrationState on the policy first. A value of migrationComplete means legacy per-user MFA settings are no longer a separate source of scope, and everything is decided in the AMP. Otherwise both need to be handled.

(Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/policies/authenticationmethodspolicy" -OutputType PSObject).policyMigrationState

In the Entra admin center, go to Entra ID > Authentication methods > Policies, then open SMS and Voice call. You can:

• Set the method state to Disabled if no one needs it,
• or remove the targeted groups and users,
• or move the relevant populations into the exclusion list.

The same thing in PowerShell, disabling both methods entirely:

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

foreach ($m in "sms","voice") {
    $body = @{ "@odata.type" = "#microsoft.graph.${m}AuthenticationMethodConfiguration"; id = $m; state = "disabled" } | ConvertTo-Json -Depth 3
    Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/$m" -Body $body -ContentType "application/json"
}

Or narrowing the scope to a single group:

$groupId = "00000000-0000-0000-0000-000000000000"

$body = @{
    "@odata.type" = "#microsoft.graph.smsAuthenticationMethodConfiguration"
    id = "sms"
    state = "enabled"
    includeTargets = @(
        @{ targetType = "group"; id = $groupId; isRegistrationRequired = $false }
    )
} | ConvertTo-Json -Depth 4

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/sms" -Body $body -ContentType "application/json"

includeTargets is replaced as a whole, not merged. Back up the current configuration before patching:

Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/sms" -OutputType PSObject | ConvertTo-Json -Depth 5 | Out-File .\sms-policy-backup.json

Order matters. Run the inventory first, or you will cut SMS for users who have nothing else. Users whose phone is their only registered method must register something else beforehand, otherwise they end up with no usable MFA at their next sign-in.

Users removed from the scope before September 1 are not auto-enabled for passkeys and are not automatically brought into the Microsoft managed registration campaign.

If you need more time: the temporary opt-out

A temporary opt-out covers the September 1, 2026 to February 1, 2027 period. It delays the automatic passkey enablement and the registration campaign rollout while you complete transition activities, such as configuring a customer-managed telecom provider or migrating users to another method.

It requires the Microsoft Graph permission Policy.ReadWrite.AuthenticationMethod:

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json

{
   "optOutSettings": {
     "passkeyDynamicMigration": true
   }
}

In PowerShell:

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

$body = @{ optOutSettings = @{ passkeyDynamicMigration = $true } } | ConvertTo-Json -Depth 3

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/beta/policies/authenticationmethodspolicy" -Body $body -ContentType "application/json"

To check the current value:

$policy = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/policies/authenticationmethodspolicy" -OutputType PSObject

if ($null -eq $policy.optOutSettings) {
    "optOutSettings not set - tenant is NOT opted out"
} else {
    $policy.optOutSettings | ConvertTo-Json -Depth 3
}

optOutSettings appears in the policy schema but comes back as null until it has been written at least once. A null value is the default state and means the tenant is not opted out. Setting passkeyDynamicMigration back to false reverts to standard behavior.

Two warnings. First, this only buys time until February 1, 2027: standard migration and enforcement timelines apply from that date regardless of the setting, and there is no opt out for the February 1 enforcement. Second, you may read elsewhere that simply moving the registration campaign out of the Microsoft managed state is enough to defer the impact. That is not what Microsoft documents. The registration campaign and the sms and voice method configurations are two separate objects, and the campaign is downstream of the scope, not the other way around. The two documented levers are removing users from the SMS/Voice scope, and the passkeyDynamicMigration opt-out. Do not rely on the campaign state alone.

One side effect worth anticipating: if you already run a registration campaign for another method, Microsoft will overwrite that configuration on September 1 for tenants in scope, including its state and its targeted method.

Choose your passkey types deliberately

Microsoft Entra ID supports two categories of passkeys, and the choice has a direct impact on your helpdesk load:

• Device-bound passkeys: passkey in Microsoft Authenticator, Entra Passkey on Windows, FIDO2 hardware security keys. The credential is created and stored on one device and cannot be transferred to a new device, even when Microsoft Authenticator backup is configured. Expect re-registration calls at every device refresh, loss or theft.
• Synced passkeys: stored in a platform credential manager such as iCloud Keychain or Google Password Manager, and synced across the user's devices. A pragmatic option for lower-risk populations, and a way to reduce the support overhead of device-bound credentials.

A common pattern is device-bound or FIDO2 keys for privileged and high-risk users, synced passkeys allowed for standard users.

Prepare the rollout and the bootstrap

• Validate supported devices, OS versions, browsers, applications, VDI scenarios, user populations, onboarding flows and helpdesk processes. This is usually where the hidden complexity lives, and where a "simple" uplift turns into a six-month project.
• Make sure Passkey (FIDO2) is enabled as an authentication method and that your SMS and voice users are included in a passkey-enabled authentication methods policy before you drive any registration.
• Be careful with Conditional Access. Enforcing phishing-resistant authentication too broadly can break the passkey registration flow itself, since the user has no phishing-resistant credential yet. Plan a bootstrap path, typically a Temporary Access Pass, and test it before enforcing.
• Run your own registration campaign proactively rather than waiting for the Microsoft managed one on September 1. Go to Entra ID > Authentication methods > Registration campaign, and target the security group of SMS and voice users you built in step 2.

Plan communication

Users need to understand what a passkey is, why they are being asked to register one, and what will change during sign-in. Microsoft recommends a phased plan: awareness, then action, then reminders for users who have not registered yet.

End-user communication templates are available at https://aka.ms/mfatemplates

Scope your messaging to the security group of SMS and voice users, so the right people hear from you at the right time.

Handle exceptions

Some users, shared scenarios, or operational accounts may require a different transition path. Document these cases early, and document the actual requirement (which regulation, which scenario) if you plan to justify a telecom provider.

Avoid making telecom fallback the default strategy

The Microsoft Security Store option is useful for organizations with genuine regulatory or operational constraints, but it should not replace the move to phishing-resistant authentication. It carries a recurring per-message cost and keeps a phishable method alive in your environment.

Key takeaway

This is not just another MFA configuration change.

Microsoft is clearly moving Entra authentication away from telecom-based MFA and toward phishing-resistant methods by default.

If SMS and voice are still part of your MFA strategy, the migration window is now visible:

• September 1, 2026: passkeys become the default experience, and users in the scope of the sms and voice policies are auto-enabled and nudged.
• February 1, 2027: native SMS and voice MFA are discontinued, with a blocking registration prompt and no opt out.

Two dates matter more than the deadline itself: the day you finish your inventory, and the day you decide who stays in the SMS/Voice scope after September 1. The right move is to start preparing passkey adoption now, before this becomes an urgent remediation project.

References

• https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement
• https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement-faq
• https://github.com/microsoft/entra-sms-voice-usage-analyzer
• https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication
• https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2
• https://github.com/bastienperez/PS365