Hopefully not you, but that is not the point of this blog post. The point of this one is to query the sign-in logs in Microsoft Entra ID and report on other users in your tenant, and guest users from outside your tenant, who are still using SMS (text messages). Note that the user might have been upgraded to WhatsApp messages if the user has a WhatsApp account for their SMS number if you are in a country where Microsoft is using WhatsApp to remediate the clear-text nature of SMS. In this WhatsApp case, we will still be reporting these users as using text messages.
Once you have a list of users in a given time period who have used SMS as their MFA method you can work at remediating this. In this blog post we will move users from SMS to a more secure authentication method by first grouping those who used SMS in the last (say) 30 days and then only allowing these users to use SMS ongoing. Therefore, if you have not used SMS as a multi-factor method in the past month, you can no longer use it.
Once we have blocked all non-SMS users from using SMS ongoing, we can work with the users who have used it recently. For example, they might have a phone number and Microsoft Authenticator registered on their account, but that was an old phone and the Authenticator app was not migrated to the new phone or not set up on the new phone, so they just dropped back to using SMS and it works for them (and they are not aware it is insecure, and so have not complained about this to any helpdesk!).
So how do we get this data, how do we block some users from using SMS and then how do we go about moving users to more secure MFA methods? Lets begin…
Our first step is to ensure that the Authentication Methods migration is completed. Microsoft will do this for your tenant by end of September 2025, but you can go to my 2022 blog post on this topic now if you have not done this yet, and then return here.
As you have users using text messaging for MFA, when you migrated your Authentication Methods to the new policy, you would most likely have allowed SMS for all users. Our next step is to find who is actually using SMS for MFA in the last 30 days and add these users to a new group, and allow this group to use SMS for MFA. If you are not in this group, SMS for MFA is no longer available to you, even if you have a phone number registered on your accounts authentication methods.
For this blog post I am going to create a group called “EntraID-AllowSMSForMFA“, and optionally set the Microsoft Entra roles can be assigned to this group – not because I am going to set any roles, but because it raises the bar in terms of admin account that can modify this group.
Next we need to find the users who are using text messaging for MFA. For this we will use the sign-in logs diagnostic reports in Azure Log Analytics. This is a free use of Azure Log Analytics as long as you do not modify the storage duration, and you can ship your sign-in (and other, some of which will cost) logs from Entra ID to Log Analytics. We are not going to cover this here, but check the Diagnostic Settings page in the Entra ID Admin Portal to see if this is set up and to which Log Analytics resource these logs are going.
Open the Azure Portal (https://portal.azure.com) and type “Log Analytics” in the search box. It will list all the Log Analytics instances you have access to – select the one that is configured in the Entra ID Diagnostic logs settings.
On the main menu on the left of the screen click “Logs”:
“Queries Hub” might be displayed, and if so close it, and then to the right it might say “Simple Mode” in the drop-down. Change this to KQL Mode as we are going to paste in some queries that I list below.
Our first query will be to see how many logins used each of the different MFA methods in the last 30 days. You can enter your own number if you want a longer time period:
// Get count of all MFA methods
SigninLogs
| where TimeGenerated > ago(30d)
| where UserType == "Member"
| mv-expand todynamic(AuthenticationDetails)
| extend ['Authentication Method'] = tostring(AuthenticationDetails.authenticationMethod)
| where ['Authentication Method'] !in ("Previously satisfied", "Password", "Other")
| where isnotempty(['Authentication Method'])
| summarize MethodsUsed = count() by ['Authentication Method']
| sort by MethodsUsed
This KQL query will return a list of about 8 or so items, one for each different authentication method used. Ensure that you are not restricted to the first 1000 answers from the selector above the query as shown:
This KQL query ignores guest users (UserType == “Member”), we will come to them later, and ignores all logins that are using MFA already in the token or no MFA.
I can see from the above that most MFA is via “Mobile app notification”, so push notifications, so Microsoft Authenticator app. A few (though not enough) usage of Passkeys is seen in the tenant and 118 separate authentications via SMS for MFA in the previous 30 days.
So our next KQL query is going to see who did these 118 text message authentications, but this time only showing successful authentications:
// Get all SMS for MFA Users
SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationRequirement == "multiFactorAuthentication"
| mv-expand todynamic(AuthenticationDetails)
| where tostring(AuthenticationDetails.authenticationMethod) == "Text message" and ResultSignature == "SUCCESS"
| project
TimeGenerated,
UserPrincipalName,
AppDisplayName,
UserType
| sort by UserPrincipalName asc
This query includes guest users, as we might need them later, but will be mostly internal member users from our tenant. For your info, we return the application they were using when they got the MFA prompt. Each user might turn up more than one.
Add these users, and optionally the guests, to the group you created above. In the above tenant I had 64 successful MFA logins that were satisfied with SMS over 30 days, from a total of 33 users and guests.
A slight aside for a moment: Guest Users will require MFA to access your resources if you have a Conditional Access rule that does not exempt guests. That is, a Conditional Access rule that requires MFA for All Users will include guest accounts in the “All Users” condition. It is therefore possible to create one rule for members (exempt all guests) and another rule for guests that can require different Authentication Strengths. But it is also possible to outsource MFA for your guests back to their home tenant (if they are Entra ID guest users) via External Identities in Entra ID. This is a win-win for you and the guest user. It allows them to use their existing MFA methods/app to authenticate to your tenant rather than setting up a new one, and it means you are not managing MFA methods for guest users via your helpdesk. Authentication Strengths are then used to block text messages etc in your tenant, and guests who use text messages in their tenant are required to set up an additional method in their tenant before returning to your tenant to access your resources. And in all this, remember that since 2020 Microsoft has been prompting SMS MFA users to “upgrade” to Microsoft Authenticator and so the number of SMS for MFA users is lower than you might otherwise expect, so meaning that the impact of this change is usually slight.
The External Identities > Cross-Tenant Access Settings page is where you outsource guest user MFA back to their tenant, either for selected tenants and partners or for all tenants. For guest users in all tenants to use their own MFA (BYOMfa!) you select the “Trust multifactor authentication from Microsoft Entra tenants” under “Inbound Access Settings – Default Settings > Trust Settings”. For specific tenants, find or add the tenant under Inbound Access for tenants listed under Organizational Settings.
If you do not allow guest users to bring their own MFA to your tenant, then you need to manage their authentication methods just like your own users and restrict them via the groups and policies in this blog post.
So back to the subject at hand – once you have a list of all users (and guests if not trusting their own MFA) added to your exception group, you can update the Authentication Methods policy so that only your group members can do SMS. The Authentication Methods policy is found under the Protection menu in the Entra Admin Portal, or the Security menu in the Azure Portal/Entra ID.
From here, select SMS and change it from “All Users” to your group. The next three pictures show the “before” setting and then the change and the final setting:
Once you have restricted SMS for MFA to your group, take a look at any user who is NOT in the group, but who has a phone number listed as one of their Authentication Methods. For this user, and all others not in the group, “phone” as an MFA method (so text and voice) will be shown as “disabled by policy”:
For standard modern authentication login popups (in browser and most applications) the user will be prompted to complete MFA by their “default sign-in method”, shown at the top of the settings in the picture above. But for MFA based apps that do not support the default sign-in method, the system preferred MFA method will be used instead – this is likely when using the MFA Connector for RADIUS apps such as VPN or WiFi. In these cases SMS/voice by phone is still blocked, but as you can see above the user will need to use the OATH code from their phone authenticator app.
Look at a user who is in the exemption group – they will not have phone number disabled by policy, and hence they can still use SMS for MFA:
The user’s “default sign-in method” is the first one shown to the user when they are required to authenticate with a second factor – the user always can choose another registered, enabled authentication method to authenticate with, and so in our second example, they can choose SMS and they have been exempted from the restriction because they used this method in the past 30 days.
Some final thoughts. Once you have exempted the group, run the KQL query again as see if any new users have been doing SMS whilst you have been making changes. This time, run the query without the final “sort” option, so that the results are sorted by date/time. If you have any recent new SMS MFA users add them to the exception group as well.
Secondly, now you can work with these users to ensure that they have a working MFA method that is not SMS (ideally passkeys), either by removing them from the exemption group and then requiring them to reregister MFA again (so now they cannot register SMS), or being more hands on and working with them.
Finally, in say 30 or 45 days time, run the KQL query again and see who is still in your exemption group but who has not done any SMS MFA in that time and just remove them from the exemption group as they are likely only using it as an alternative secondary method.
You are likely to end up with a few select users in this group at the end of this process, maybe some external consultants or guests from a partner that you know only do SMS and you might consider that acceptable (or not, and now is the time to move them to passkeys). If you have an empty group at the end of this project, set the policy to disabled for SMS and delete the group.
Well done in removing a significant security risk from your tenant. Now you can take a look at other MFA methods you might want to remove from your tenant such as 3rd party authentication apps such as Google Authenticator or any number of risky apps that claim to do MFA codes in the app stores and use the same process described here to determine these users and remove this MFA method from your tenant.
Photo by Matias Mango: https://www.pexels.com/photo/numbers-projected-on-face-5952651/
Leave a Reply