I'm reviewing Microsoft's guidance about retiring SMS and voice authentication starting September 1, 2026, and I'm trying to determine which users will be affected. For example, some users have Microsoft Authenticator Push as their default method but still have mobile phone, alternate phone, or one-time passcode methods registered. Others have mobile phone as their default but also have Windows Hello for Business, Authenticator, or one-time passcode configured. One user has only mobile phone registered.
My initial assumption was that users whose default method is Authenticator would not be affected, and that users with a more secure method already registered would automatically use that method instead of SMS or voice. I expected only users who have a retiring method as their sole option to require intervention.
Can anyone confirm whether the change is based on the user's default authentication method, the methods they are allowed to use, or simply whether SMS or voice is enabled for the user? I'd also appreciate clarification about whether administrators need a non-SMS backup method before the change takes effect.
4 Answers
The guidance indicates that passkeys become the default authentication experience and are automatically enabled for users who are enabled for SMS or voice. Based on that wording, simply having SMS or voice available may be enough to trigger the new experience, regardless of whether Authenticator, Windows Hello, or another stronger method is also registered.
A practical way to reduce the impact is to audit enrollment now. Where a user already has Authenticator or another modern method, remove SMS enrollment and change the default away from SMS. This avoids relying on the retirement behavior to choose a stronger method automatically, and users may not notice any change if the migration is handled ahead of time.
The initial interpretation seems reasonable, but the available evidence suggests the change may apply more broadly than the default method. In at least one early test tenant, users were prompted to set up a passkey when SMS or voice was enabled as an allowed method, even when it was not their default and they already had stronger methods registered.
That’s useful to know. It sounds safer to plan for users with SMS or voice enabled to see a passkey prompt, rather than assuming their current default method will exempt them.
It’s worth treating administrator accounts the same way, or more strictly. Make sure every administrator has at least one supported primary method and a separate recovery option that does not depend on SMS or voice. Otherwise, a lost phone or an unplanned device change could leave the account without a reliable way to complete MFA.
That matches our reading too. We’re planning for everyone with SMS or voice enabled to encounter the passkey setup prompt, even if they already have another MFA method.