Entra ID passkeys: audit and migrate SMS users

On February 1, 2027, Microsoft Entra ID stops providing SMS and voice as authentication methods for most accounts. From that date, a user whose only MFA method is SMS or voice gets a blocking prompt to register a passkey. This article gives you the up-to-date timeline, a Microsoft Graph script to find exposed accounts, a pilot approach and the check to run before the SSPR change on November 9, 2026.

Timeline: three dates not to confuse

The February 1, 2027 date no longer applies to everyone. According to Microsoft Learn documentation, the retirement of Microsoft-provided SMS and voice affects all users, except global administrators and external users. For these two populations, the deadline is pushed back to July 1, 2027. Internal guests remain subject to February 1.

The full chronology, including the SSPR (Self-Service Password Reset) change, comes down to five milestones.

TOTP remains supported after February 1, 2027. SSPR security questions are retired in March 2027, according to the answer from Marcin Policht, MVP, quoted in the Microsoft Learn FAQ.

Who will actually have to create a passkey

Not all accounts will be forced. After the applicable date, only users whose sole MFA method is SMS or voice get the blocking prompt. A user who also has Microsoft Authenticator (push notification) or a software TOTP is not required to create a passkey.

One exception changes the picture: a Conditional Access policy requiring phishing-resistant MFA will force them to, according to the answer published on Microsoft Learn Q&A. If you already have this type of policy, your Authenticator users without a passkey will also be affected.

An illustrative scenario: an organisation with several hundred seats has human service accounts, field users and administrators. Field users often have only SMS. They, not the administrators, form the priority migration queue.

Passkeys by default since September 1, 2026

Since September 1, 2026, passkeys are enabled automatically for SMS/voice users. The registration campaign has moved to “Microsoft Managed”, with an unlimited number of postponements by default.

A temporary opt-out remains possible until February 1, 2027. It goes through Microsoft Graph, with the Policy.ReadWrite.AuthenticationMethod permission and the passkeyDynamicMigration property set to true. It does not protect you from the final enforcement on February 1. Consult the dedicated Microsoft Learn page for the exact request before making any change. Our article on postponing the automatic passkey rollout details this option, and the one on the September Passkey change explains the background.

On cost, Microsoft recommends that organisations move to passkeys, which are included in all Entra plans at no extra cost. The Security Store, opened on October 30, 2026, remains a paid route via a third-party carrier for those who must keep SMS or voice.

Implementation: audit authentication methods with Microsoft Graph

The script below goes through your users, reads their authentication methods and classifies each account. It is read-only: no dry run is needed.

• Required module: Microsoft Graph PowerShell. Installation: Install-Module Microsoft.Graph -Scope CurrentUser.
• Permissions: User.Read.All and UserAuthenticationMethod.Read.All as delegated. The account must also hold a Microsoft Entra role allowed to read methods, such as Global Reader.
• Output: a CSV file with one row per user and a summary by status in the console.

1# Connexion avec les permissions minimales en lecture
2Connect-MgGraph -Scopes 'User.Read.All','UserAuthenticationMethod.Read.All' -NoWelcome
3 
4# Types de méthodes lus dans la propriété @odata.type
5$tPhone  = '#microsoft.graph.phoneAuthenticationMethod'
6$tFido   = '#microsoft.graph.fido2AuthenticationMethod'
7$tAuth   = '#microsoft.graph.microsoftAuthenticatorAuthenticationMethod'
8$tOath   = '#microsoft.graph.softwareOathAuthenticationMethod'
9$tEmail  = '#microsoft.graph.emailAuthenticationMethod'
10$tPwd    = '#microsoft.graph.passwordAuthenticationMethod'
11 
12$rapport = foreach ($u in Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,AccountEnabled,UserType) {
13    try {
14        $methodes = Get-MgUserAuthenticationMethod -UserId $u.Id -ErrorAction Stop
15    }
16    catch {
17        Write-Warning "Lecture impossible pour $($u.UserPrincipalName) : $($_.Exception.Message)"
18        continue
19    }
20 
21    # Liste des types de méthodes enregistrées pour cet utilisateur
22    $types = @($methodes | ForEach-Object { $_.AdditionalProperties['@odata.type'] })
23 
24    $aPasskey = $types -contains $tFido
25    $aAuth    = $types -contains $tAuth
26    $aOath    = $types -contains $tOath
27    $aPhone   = $types -contains $tPhone
28    $aEmail   = $types -contains $tEmail
29    $autres   = @($types | Where-Object { $_ -ne $tPwd })
30 
31    # Classement : du plus avancé au plus exposé
32    if     ($aPasskey)           { $statut = 'Passkey enregistrée' }
33    elseif ($aAuth -or $aOath)   { $statut = 'Authenticator ou TOTP, sans passkey' }
34    elseif ($aPhone)             { $statut = 'SMS/voix seul : prioritaire' }
35    elseif ($autres.Count -gt 0) { $statut = 'Autre méthode uniquement' }
36    else                         { $statut = 'Aucune méthode hors mot de passe' }
37 
38    [pscustomobject]@{
39        UserPrincipalName = $u.UserPrincipalName
40        Compte_actif      = $u.AccountEnabled
41        Type_utilisateur  = $u.UserType
42        Passkey           = $aPasskey
43        Authenticator     = $aAuth
44        TOTP_logiciel     = $aOath
45        Telephone_SMS_voix = $aPhone
46        Email             = $aEmail
47        Statut            = $statut
48    }
49}
50 
51# Export et récapitulatif
52$rapport | Export-Csv -Path .\audit-methodes-auth.csv -NoTypeInformation -Encoding UTF8
53$rapport | Group-Object Statut | Select-Object Count, Name | Sort-Object Count -Descending

Three notes on reading the result. The phoneAuthenticationMethod type covers both SMS and voice; the script does not distinguish them. Passkeys are counted via fido2AuthenticationMethod: validate this mapping on a few pilot accounts before extrapolating, especially for passkeys hosted in Authenticator. Finally, Microsoft Learn publishes its own script for finding SMS/voice users, and Daniel Bradley (Our Cloud Network) offers an audit guide: cross-check the three results.

On a large directory, execution is slow because it issues one request per user. Filter on active accounts, or split by group, before scheduling the run.

Piloting the migration: a targeted registration policy

A pilot limits unpleasant surprises. Take 30 to 50 accounts from the report, spread across the “SMS/voice only” and “Authenticator or TOTP, no passkey” statuses.

The real obstacle is human. Daniel Bradley notes that the user who refuses to use a personal device for work is the main brake, with a possible cost: buying FIDO2 keys. Budget for these keys for the profiles concerned rather than discovering the need in February. For architecture and pitfalls at scale, see our article on enterprise deployment of FIDO2 passkeys and the one on passkey registration and its delays.

SSPR: the November 9, 2026 check

From November 9, 2026, self-service password reset accepts only explicitly registered methods. Phone numbers and emails from the directory (mobilePhone, businessPhone, otherMails) are no longer valid if they have not been registered.

Message Center MC1325414 initially mentioned November 7 for the start of enforcement, with action required before the 9th. General rollout runs from early to mid-November 2026. About 86% of SSPR verifications already use registered methods, which leaves a minority at risk.

Microsoft says to check coverage in the Entra admin center: Authentication methods, then User registration details. Every user, administrators included, must have at least one registered method compatible with your SSPR policy. Also plan a fallback procedure through support.

Frequently asked questions

Will a user with Authenticator and SMS have to create a passkey?

No, unless a policy says otherwise. A user who also has Authenticator (push) or a software TOTP is not required to create a passkey. A Conditional Access policy requiring phishing-resistant MFA will, however, force them to.

Can the passkey registration prompt be disabled?

Not the blocking prompt that follows the applicable date. Only automatic migration can be temporarily disabled, until February 1, 2027, via Microsoft Graph with the passkeyDynamicMigration property set to true. This opt-out does not protect you from the final enforcement.

Do passkeys cost an extra licence?

No. Passkeys are included in all Entra plans at no extra cost. The only possible cost comes from hardware, such as FIDO2 keys, or from a paid telecom provider via the Microsoft Security Store.

What happens to B2B guests?

They are within the scope of the SMS/voice retirement. Passkey support for B2B users and internal guests is announced for late 2026, and TOTP remains supported after February 1, 2027.

Where to start

The safest sequence is three moves: audit, handle SSPR before November 9, then migrate in waves.

If your organisation has global administrators or external users, do not use July 1, 2027 as a reason to wait: handle them in the same campaign, with the same report.

Further reading

• Passkeys by default and retirement of Microsoft-provided SMS/voice (Microsoft Learn): official timeline, detection script and temporary opt-out.
• FAQ on the retirement of SMS and voice (Microsoft Learn): administrators, external users, B2B guests and TOTP.
• Microsoft Entra ID security updates: What organizations need to do now (Tech Community): the official detail of the November 9, 2026 SSPR change.
• Microsoft are set to retire SMS & Voice authentication methods (Our Cloud Network): audit guide and practical migration difficulties.
• No More SMS One-time Codes and Voice Calls from Entra ID (Office 365 for IT Pros): Tony Redmond's analysis of the scale of the change.