Microsoft Entra SMS and Voice Retirement - What Does It Mean for SSPR?
Microsoft is retiring SMS and voice authentication service in Entra ID on 1 February 2027. Also, from 1 September 2026 onwards, users enabled for SMS or Voice will be automatically migrated to passkeys and brought into the Passkey Registration Campaign. This means that when they next sign in and complete MFA, they will be prompted to register a passkey. Understandably, this has caused a lot of chatter in the technical community and I wanted to both understand this change and the possible impacts.
Before strong authentication requirements as part of passwordless came into picture, organizations relied on SMS or Voice as authentication methods, that have now become legacy. There is no question are these authentication methods being less secure and why there is a need to move to stronger authentication methods, however, the migration needs to be carefully planned and also prepare for any surprised that may arise.
One such area organisations need to consider is Self-Service Password Reset (SSPR). Microsoft has confirmed that the retirement of native SMS and Voice applies across Entra, including SSPR.
Historically, Microsoft Entra ID allowed SSPR to pull data directly from Active Directory profile attributes. If an HR system populated a user’s profile with an alternative email (otherMails) or a cell phone number (mobilePhone), Entra ID trusted it blindly. This meant that if a user forgot their password, Entra ID would happily send a code to that unverified phone number. Well now Microsoft wants to close this security gap.
So what does this mean for organisations that currently use SMS or Voice as part of their SSPR configuration? I decided to look at this in my own Microsoft 365 Business Premium tenant and document things to check for and consider before the retirement date hits.
Understanding your current configuration
Before changing anything, it is important to establish what authentication methods are currently configured.
My test tenant originally had Security Defaults enabled, which I subsequently replaced with Conditional Access. This is worth mentioning because Security Defaults can enable a number of authentication experiences automatically. Once Security Defaults is disabled, authentication methods can be managed through the Authentication Methods policy.
Before making any changes, I wanted to establish exactly what was configured.
As you can see from the screenshot, both SMS and Voice authentication methods are already disabled. As per Microsoft, Security defaults users are required to register for and use multifactor authentication using the Microsoft Authenticator app using notifications, thus eliminating the need for registering SMS and Voice. In tenants, where these methods are enabled, organizations should still investigate whether users are relying on phone-based verification when resetting their passwords or not.
Review SSPR
Microsoft's retirement isn't limited to MFA. Native SMS and Voice authentication used by SSPR will also be affected.
Therefore, an organisation that has removed SMS from its MFA strategy may still need to investigate whether users are relying on phone-based verification when resetting their passwords.
For demonstration purposes, I enabled SSPR for all users.
Identifying Affected Users
The next step is to determine which users are actually dependent on SMS or Voice. Microsoft provides PowerShell guidance for identifying users using these authentication methods.
Note- I have not created the script and taken directly from GitHub (link provided as reference at the end of the blog)
This is what the script is supposed to do -
- Shows the registration campaign state
- Reports SMS and Voice policy state and enabled scope
- Exports policy targets to CSV, including exclusions
- Shows authentication methods migration state and warns when legacy MFA/SSPR coverage is unverified
- Displays an impact summary based on the SMS & Voice retirement timeline.
Note - For demonstration purposes, I enabled SMS & Voice scope in my tenant.
Only policyMigrationState = migrationComplete establishes that legacy MFA/SSPR policies are ignored. For incomplete, missing, or unknown migration states, the scanner warns that its assessment is incomplete, like it was in my case due to tenant being newly provisioned with security defaults enabled.
Enable the replacement authentication method
Microsoft's preferred direction is towards phishing-resistant authentication. Depending on your environment, this could include:
- Passkeys
- Windows Hello for Business
- FIDO2 security keys
- Microsoft Authenticator as an interim step
For this exercise, I'm going to use passkeys as the target authentication method. (Note - Before configuring the registration campaign, Microsoft requires Passkey (FIDO2) to be enabled and the affected users to be included in a passkey-enabled authentication method policy.)
Configure the Passkey Registration Campaign
Microsoft provides an important migration mechanism in form of the Passkey Registration Campaign that can prompt users to register a passkey during their normal sign-in experience.
Note: I'll suggest to enable Authenticator registration first and then Passkey. This will give users a strong MFA method that can also be used in SSPR. Especially when SMS & Voice retire. This will become evident in the testing below.
Testing
Take a test user who is in the migration group and sign in normally. After completing MFA, the user should receive the passkey registration prompt. Note - The user can choose to skip the prompt as Microsoft currently allows unlimited snoozes by default, unless you decide to control this behaviour.
Now we will use the same test account and move on to reset the password using aka.ms\sspr. As demonstrated below, there is no Passkey option available for SSPR. I went ahead and used Authenticator to reset the password. This is why it is important to register for Authenticator first.
Final thoughts..
The retirement of SMS and Voice authentication methods is more than a simple replacement of one authentication method with another. The practical impact becomes clearer when MFA and SSPR are considered separately.
In my testing, an account using SMS or Voice can be successfully moved towards a phishing-resistant sign-in experience by registering a passkey through the Microsoft managed Registration Campaign. Once registered, the passkey becomes the user's preferred authentication experience for sign-in and MFA. However, registering a passkey does not remove the need for an SSPR capable authentication method. When the same user was tested through SSPR, the passkey was not presented as a verification method. Microsoft currently documents Microsoft Authenticator, SMS, Voice, OATH and email OTP among the methods available for SSPR.
As I see it, organisations should treat the migration as two related but distinct activities:
Phase 1 – SSPR readiness - Move users away from SMS or Voice as an SSPR dependency by registering Microsoft Authenticator, or another supported SSPR method, and validate the experience through SSPR.
Phase 2 – phishing-resistant MFA - Move the user's normal authentication experience from SMS or Voice to passkeys, Windows Hello for Business or another supported phishing-resistant method.
This distinction is important because simply registering a passkey does not complete an organisation's SSPR migration.
For organisations preparing for the February 1, 2027 retirement date, the practical lesson is to identify users who still depend on SMS or Voice, establish an alternative SSPR method, validate password-reset scenarios, and then migrate their primary authentication experience to phishing-resistant methods. Microsoft has confirmed that users who remain dependent on Microsoft provided SMS or Voice after retirement will be required to register a passkey during sign-in, with the registration prompt becoming a mandate. I'll say, don't wait until February 1, 2027 retirement date and start preparing for this upcoming and important security change.
References:
Comments
Post a Comment