I'm reviewing Microsoft's guidance on the retirement of SMS and voice authentication, which begins September 1, 2026, and I'm trying to understand how it will affect users with different authentication methods registered.
My current interpretation is:
- Users 1 and 3 should be unaffected because Microsoft Authenticator is their default method.
- Users 2, 4, and 5 have mobile phone as their default, but also have other methods such as Windows Hello for Business, Authenticator, or a software one-time passcode registered. I assumed they would automatically use one of those alternatives instead.
- User 6 only has a mobile phone method registered, so I expect that user to be prompted to configure another method.
Is this interpretation correct, or will anyone with SMS or voice enabled—even as a non-default method—be prompted to set up a passkey or another authentication method? I'm trying to estimate the amount of cleanup and user communication that may be required before the change takes effect.
4 Answers
A practical approach is to audit the registered methods now. Where a user already has Authenticator, Windows Hello for Business, or another modern method, remove the SMS enrollment and change the default method if necessary. That reduces reliance on the retiring methods and has generally avoided user disruption in our testing.
The current guidance appears broader than just checking the user’s default method. If SMS or voice is enabled as an available authentication method, users may be prompted to set up a passkey, even when Authenticator or another stronger method is already registered. An early test tenant reportedly showed this behavior for users who had SMS or voice enabled but were not actively using it as their default.
The important distinction seems to be between a method being registered and SMS or voice being enabled by policy. Based on observed early testing, simply having a stronger method registered may not prevent the passkey prompt if SMS or voice remains allowed for that user. I’d verify the behavior in a test group and review the mitigation setting before assuming only users with SMS as their default will be affected.
I’d include administrator accounts in the review as well. They should have at least one reliable non-SMS backup method, especially because changing or losing a phone can otherwise create a lockout scenario. Make sure the recovery plan is tested before removing the old method.
That’s the assumption we’re using too: plan for users to see the passkey setup prompt unless the organization applies the available mitigation or removes SMS and voice from their allowed methods.