A few days ago Microsoft has announced that the Microsoft-provided SMS and voice call authentication methods will be retired from Microsoft Entra ID. These methods will no longer be available as built-in options for multi-factor authentication (MFA) or self-service password resets (SSPR). Consequently, organisations that still rely on SMS or voice authentication must prepare for this change and migrate affected users to alternative authentication methods. As part of this change, Microsoft will promote passkeys as the default sign-in method for users currently using the SMS or voice authentication methods.
This news post will provide an overview of the changes, explain how to check if you are affected, and outline how to prepare.
What is changing in detail
As part of the retirement of Microsoft-provided SMS and voice authentication method, the following changes will be introduced until the final retirement date:
- The Microsoft-provided SMS and voice authentication methods in Microsoft Entra ID will be retired and will no longer be available as native second-factor authentication methods for all users.
- Users who are enabled for SMS or voice authentication method will be enforced to register a Passkey and will be guided through the registration of a Microsoft Passkey during sign-in.
Important: Users who already sign in with any other options like Microsoft Authenticator, Passkeys, Windows Hello for Business or another method can continue using those with no impact. - If the organisation still requires SMS or voice authentication after retirement (for some specific use cases), a customer-managed third-party telecom provider must be integrated through the Microsoft Security Store (coming September 18th, 2026).
Microsoft has announced the following timeline for the above-mentioned changes. The important dates are 1 September 2026 and 1 February 2027
The timeline is subject to change by Microsoft.
Opt-out of the changes
A temporary opt-out will be available from 1 August 2026 until 1 February 2027 for all changes made in September. This allows you to delay the enablement of passkeys and the Registration Campaign while you complete transition activities, such as configuring customer-managed telecom providers or migrating to other authentication methods.
Important: There is no opt-out for the 1 February 2027 enforcement date. This requirement applies to all tenants.
How to check if you are affected
To identify affected users within your organisation, review all users who are currently enabled to register or use SMS and voice authentication methods. This can be checked in the Microsoft Entra admin center under the Authentication methods policy:
All users in this group (or ‘All Users’, if configured) will be affected by Microsoft’s retirement of the SMS and voice authentication methods. These users will then be prompted to register a Microsoft passkey and transition to using a passkey. Microsoft has also published a PowerShell script that can be used to identify all users which are affected by the change instead of using the Microsoft Entra ID Portal.
It is important to understand that users who are already actively using another authentication method, such as Microsoft Authenticator, may still be affected by this change if they are also in scope for the SMS or voice authentication methods. This applies even if they do not use SMS or voice authentication for their day-to-day sign-ins and instead authenticate using Microsoft Authenticator.
The following table should provide you with some scenarios to help you determine who is and isn’t affected:
| Authentication Methods Enabled for the User | Authentication Methods Registered by the User | Expected User Experience |
|---|---|---|
| – SMS – Voice – Microsoft Authenticator | – SMS – Voice – Microsoft Authenticator | User will be prompted to register a Microsoft passkey because the user is in scope for the SMS and voice authentication methods. |
| – SMS – Voice – Microsoft Authenticator | – Microsoft Authenticator | User will be prompted to register a Microsoft passkey because the user is in scope for the SMS and voice authentication methods, even though SMS and voice are not currently registered or used for authentication. |
| – Microsoft Authenticator – Passkey (FIDO2) | – Microsoft Authenticator – SMS – Passkey | User will not be prompted to register a passkey because the user is not in scope for the SMS or voice authentication methods. |
Get current usage of SMS or Voice authentication Method
To get an overview of the current usage it is possible to run the following KQL query to generate a list of users who have actively used the SMS or voice authentication method within the last 90 days. These users will notice an change and require targeted attestation. The list suggests that these users either do not have any other registered authentication method or are not being forced to use a ‘safer’ method, such as Microsoft Authenticator or a passkey.
*To run this query, the Microsoft Entra sign-in logs must be ingested into a Log Analytics workspace.
Users included in the SMS or voice authentication policy who are not listed in the KQL results may still be allowed to use these legacy authentication methods, even if they have not used them recently. These users should be reviewed and, where appropriate, removed from the scope of the SMS or voice authentication method. Doing so can reduce the impact of the retirement, as these users already authenticate using alternative methods and are not actively relying on SMS or voice authentication.
KQL Query:
SigninLogs
| where TimeGenerated > ago(90d)
| mv-expand parse_json(AuthenticationDetails)
| extend AuthenticationMethod = tostring(AuthenticationDetails.authenticationMethod)
| where AuthenticationMethod !in(“Previously satisfied”, “Password”)
| where CrossTenantAccessType == “none”
| where ResultType == 0
| where AuthenticationMethod has_any(“Text message”, “Phone call approval (Authentication phone)”, “Phone call approval (Alternate phone)”)
| distinct UserPrincipalName, AuthenticationMethod
Note: When copying the query into Advanced Hunting, make sure that the quotation marks are formatted correctly. If not, the query will not work and you will need to adapt the quotation marks.
Environement preparation
To prepare for the change, we recommend that you check and prepare the following configurations within your tenant:
- Configuration of the Microsoft passkey authentication method
- Configuration of Self-Service Password Reset
Configuration of Passkey Authentication Method
The passkey authentication method can be enabled and configured in Microsoft Entra ID. It is important to understand the different passkey types and how they should be scoped to different user personas, because this configuration is not just a simple on/off setting.
When using passkeys as an authentication method in Microsoft Entra ID, there are two main types: synced passkeys and device-bound passkeys. Each passkey type has different operational and security characteristics and should be assigned based on the user persona. The following graphic illustrates the two types and their differences:
| Synced Passkeys | Device-Bound Passkeys |
|---|---|
| Properties • Passkeys saved to a platform credential manager (e.g. Password Manger) • Synced across the user’s devices • Synced passkeys offer a seamless and convenient user experience Personas • Non-Admins aka Standard Employees Example Passkeys • Google Password Manager • iCloud Keychain • Other Password Manager | Properties • The Passkeys is created and stored on a single physical device and never leaves it Personas • IT Admins • Privileged Users • Users which have no capable device to store the passkey on a Smartphone Example Passkeys • Passkey on Microsoft Authenticator • FIDO 2 Key (e.g. Yubikey) • Windows Hello for Business |
It is recommended not to simply enable the authentication method for all users. Instead, the passkey configuration should be scoped to the relevant personas. An example the following passkey configuration could be configured as follows:
| Persona | Passkey Type |
|---|---|
| Non-Admins / Standard Employees | Synced Passkeys or Device Bound Passkey on Microsoft Authenticator |
| IT Admins / Privileged Users | Device Bound Passkey stored on a physical FIDO 2 Key (e.g. Yubikey). |
Passkey Registration Pitfalls
We have helped various customers migrate to a passkey environment and identified several common challenges during the rollout process. We would therefore like to share these and recommend that you consider the following points when rolling out the passkey authentication method:
- End users require an up-to-date smartphone to register a Passkey on their device.
- Depending on the Android manufacturer and device model, not all smartphones may support the required APIs to store passkeys on the device.
- During our passkey rollout projects, we observed compatibility issues with certain Android devices running Android 14 from manufacturers such as Sony, Motorola, Oppo, and OnePlus, as the required system component was not included into the Android build of those OEM’s. While this is based on our own experience and not an exhaustive list. Devices running Android 15 and later are guaranteed to support passkeys.
- Android work profiles can create additional challenges during passkey registration and should be tested before broad rollout.
- The simplest onboarding experience is to register the passkey directly through Microsoft Authenticator.
- Review Conditional Access policies to ensure that passkey registration and authentication are not unintentionally blocked. Attention should be given to scenarios where smartphones are unmanaged, and Conditional Access policies require compliant or managed devices. In addition, verify that any policies targeting the Register Security Information user action do not introduce requirements that could prevent users from successfully registering a passkey.
- For broad deployment, consider having a ‘Plan B’ for users who do not have an up-to-date smartphone or who experience issues with Passkey registration on their smartphone. Example Plan B:
- Use/store the passkey on the company device with Windows Hello for Business.
- Hand out a physical FIDO2 key as an alternative.
Configuration of Self-Service Password Reset
Because Microsoft-provided voice and SMS authentication will no longer be available, the change can also impact the self-service password reset flow for end users. It is recommended to review how many authentication methods are required to reset a password and whether users still have enough supported methods registered after the retirement.
This can be checked as follows:
If the number of authentication methods required for password reset is set to one, users must provide one valid authentication method to reset their password. If the requirement is set to two methods, two valid authentication methods must be available and used during the reset process.
As many organisations have historically relied on SMS as part of their password reset process, users should be reviewed to ensure they still have sufficient supported authentication methods registered. The following authentication methods remain available for SSPR after the change:
- Microsoft Authenticator push notifications
- Hardware OATH tokens
- Software OATH tokens
- Email OTP
If you are interested in how SSPR is used in your environment, you can view SSPR activity on the following dashboard::
If your organisation is affected by this, there are two possible approaches. The first option is to reduce the number of authentication methods required for Self-Service Password Reset (SSPR) to a single method, such as Microsoft Authenticator push notifications. The second option is to ensure that users register additional authentication methods that remain supported for SSPR, allowing the existing SSPR policy configuration to remain unchanged.
Sources
Passkeys by default and retirement of Microsoft-provided SMS and voice authentication – Microsoft Entra ID | Microsoft Learn
microsoft/entra-sms-voice-usage-analyzer: PowerShell script to check Entra ID SMS/Voice authentication method policy usage.
Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID | Microsoft Security Blog