There are a number of general recommendations that SMS (text messages) as an MFA method is not a good idea (mainly to do with the ease of porting or moving devices the number is associated with). You should always be looking at MFA with an app (Microsoft Authenticator or other) or hardware device. But the default in Azure AD is to include SMS as an option – so if we turn off text messaging as a second factor what is the impact to our user base who might have already registered their phone number.
My previous article on MFA end user experiences covered the different options available for the different registration wizards (legacy and the new combined MFA/SSPR wizard), what happens if you have SSPR enabled (and what happens if you do not). Each of the scenarios in that article allowed the user to register a phone number and then to have a text message sent at login.
If the user registered with the legacy authentication wizard (which is the default setting as of the time of writing) then there are three options by default – authentication phone, office number (set by the admin and not by the user) and mobile app (and phone is the selected option). Using SMS for second factor is therefore automatically set up unless the user chooses “office number” or “mobile app” whilst registering. The registration page looks as follows:
So in scenarios where the user followed the defaults they get an MFA prompt at login that looks like this:
Notice that they have an option to “sign in another way” for scenarios where the user maybe cannot receive a phone call but would be able to receive a text message (if you are in a location where you can receive neither, then you need to register the app as well in advance). If the user clicks “sign in another way” then they see the following where they can choose to receive a text message as the second factor proof:
To disable SMS/text as an MFA method you need to be in the Azure AD portal > MFA > Additional cloud-based MFA settings (or click Multi-Factor Authentication in the Users page of the same portal). You will see the below once you click the Service Settings tab:
This dialog includes the “skip multi-factor authentication…” box which you only have if you have Azure AD P1 or P2 licence. The four options at the bottom include the “Text message to phone” – uncheck that to stop SMS as a second factor.
So if SMS/text is removed as an option – what changes for the users who has already got a phone number stored as a MFA method? First change is that “sign in another way” message is now missing. A user who previously got a phone call with the option to change to another option will find that they cannot change options anymore (unless they have also registered a different method such as office number or mobile app:
Therefore if there is not enough mobile signal to manage a call (and there might be for a text message) then the user cannot authenticate.
What about users who when they registered for MFA set SMS as their default? Setting text message as a default is not a obvious setting – but the default is whatever you initially choose to register with – so in the registration wizard if you select “send me a code by text message” then your default is SMS:
Once the admin disables SMS as a valid second factor, those users with phone as their default (or app) are not impacted – but users who set text message as their default are required to re-register. In the registration they are told their organization needs further information, that “call me” is the only available option, but their previously registered telephone number is shown in the registration wizard. This is shown in the following series of images:
Once the users settings are saved, the user clicks Finish and their registration for phone authentication is updated to remove text message as a valid option. Enabling texts again in the admin portal does not allow this user to use texts again unless they register again or they update their additional security verification settings (Office 365 browser app > click photo > My account > Manage security & privacy > Additional security verification > Update your phone numbers used for account security (go to https://aka.ms/mfasetup as a shortcut to avoid all these steps)
If you remove both phone and text as a registration option as shown then users who previously only had phone and/or text registered will be required to register again.
This time registration will default to “mobile app” – where the user can select “code” or “notification” as their new default:
In scenarios where you have enabled the new registration wizard (see my previous article on MFA end user experiences for more on this) then the default registration option is to use the app and not phone or text, though phone numbers are collected if you also turn on two or more options for requiring a password reset with SSPR. So in these scenarios you will probably find that the user has lots of registered options and so turning off SMS is not an issue.
So to disable SMS is only a problem in Azure AD for the user – as it means that at the next login they need to register again (so not a real problem). I had previously seen in 2018 that if the admin disabled text messages then users could not login if this was their only method! So that issue is clearly fixed now.
So as a call to action from this article – consider turning off text messages as a second factor and noting that the only impact is some users will either need to register again or you can ask them to go to https://aka.ms/mfasetup beforehand to change their default setting.
It’s a pity “Insights – Authentication methods registration details” doesn’t give you a report on the users that are using SMS as their default. It only says: “Mobile phone, App notification, App code” for example for a user that is using SMS, then Authenticator app on his phone. So the Mobile phone option could be used for SMS and/or Call but the default is not reflected in the Insights report.
It does now. I saw it the other week. I think you need to click things that don’t look like links to see it!
Without doubt SMS is the weakest yet most popular second factor out there and any option to replace it should be considered.
Hardware tokens, fido keys and mobile apps are probably the best alternatives, but if it’s a choice of 2FA via SMS vs no 2FA then clearly 2FA with SMS is still a better option and I guess currently the cost factor is the main driving force.
I have also disabled SMS for my tenant, but using the enhanced registration portal and Identity Protection.
SMS is still an option for my users….
Can you explain this?
Do you have SMS enabled for self service password reset?
No, we are not using this feature yet….
@John: Same here. Even though SMS is not an activated in our global MFA options I can still register it from the combined registration. SSPR is deactivated as well.
OK – so I took a further look at this. You need to register the number of methods in the combined wizard that match the number you have set in the SSPR configuration. This will include registering (optionally, as you can skip this) a phone even though phone or SMS is disabled in the legacy MFA settings.
You cannot use a phone call or SMS to perform MFA if it is disabled though – so when you login your default method is active (push to authentication most likely) and if you ignore that push (or its not working) you can choose the option to use another method. Though phone/text where registered you cannot use them here.
Administrators are always enabled for password reset, and always for two methods which includes app and phone regardless of your settings. If you test with a non-admin user you will not be asked for phone/text if that is disabled.
Thanks so much for your blog, its a wealth of useful information.
I had a query around removal of auth methods (phone/sms) and the user impact in the Outlook thick client?
As the user doesnt auth via the web at all, what would be the immediate impact (if any) and what would be the long term impact, once tokens expire?
If you remove a users only auth method but they remain logged in then there is no impact, as the token is refreshed ongoing. If the user changes device or browser (and so a new login) or leaves the login for 14 days and so it expires then the next login will prompt for MFA (assuming your rules require MFA at that location/device which they should). If the use now has no valid auth methods then they will be prompted to register a new method. This will happen in the authentication window that Outlook pops up. The newer versions of Outlook show a popup that is the right size for this registration wizard, but if you are running an older Outlook then you might find the registration process starts but its hard to see what is going on. In this case, get the user to login to a browser and trigger the MFA registration before it appears in Outlook.