Stop Using Phone-Based Responses for Multifactor Authentication

Phone-based MFA Responses Might be Less Secure, But…

It is no secret that some multifactor authentication (MFA) methods are more secure than others. Microsoft has made the case to remove phone-based MFA and would like everyone to use the most secure methods (the authenticator app, Windows Hello, and FIDO2 keys), but I have always been a bit skeptical.

While I agree that some methods for MFA responses have security issues, people often overlook their practical advantages. Not everyone is ready to dump a valid authentication method. In this article, I want to take you on a journey to remove phone-based responses from your tenant while considering some practical implications. This is an important topic because Microsoft will soon introduce a system-preferred authentication policy that will make Azure AD accounts use the most secure method available to an account.

The Case for Change

Before describing how to remove phone-based multifactor authentication, let’s cover why you should care. Phone-based multifactor authentication consists of two methods:

1. Using SMS messages, where a 6-digit code is sent to the end-user’s mobile phone. The user then needs to fill in those digits to complete the log-in.
2. Call-based authentication, which consists of receiving a call from Microsoft and pressing the #-key to confirm the login.

My main gripe is with the second method, as this is still vulnerable to an MFA spam attack (this is an attack where an attacker prompts the user with authentication requests until the user accepts). In addition, phone-based authentication is prone to social engineering attacks. For instance, an attacker can call the cell provider and trick them into sending a legitimate SIM card linked to your number. Finally, text messages are sent in clear text, and anything sent in clear text is liable to interception and compromise.

Organizations Struggle

Now that we have talked about the security risks of using phone-based MFA, let’s focus on the practical side of things. Many Microsoft 365 users still use phone-based authentication. If you want to view current usage within a tenant, go to the User registration details page and use filters to reveal details about specific authentication methods.

Multiple valid reasons might exist to justify the continued use of phone-based authentication:

• Users don’t want to use the Authenticator app

Some of my customers have users who don’t want to install the Authenticator app on their private mobile phones to ensure their IT department cannot monitor them. While we, as IT, know there are no tracking capabilities within the Authenticator app, this is often an uphill battle.

• Backup method

I always recommend that organizations require two authentication methods. This allows end-users to reset their MFA methods if they lose access to the Authenticator App. If you remove SMS-based authentication as a backup, you will increase the load on your helpdesk as end-users now need to request a manual reset of their MFA methods.

• Self-service password reset

Self-Service Password Reset (SSPR) can be configured with one or two methods. Two methods are recommended as it is harder to crack. If you remove phone-based authentication, users are left with email-address or security questions as a backup.

Microsoft’s Answers

There are currently two different methods that allow you to alleviate the issues mentioned above:

• Temporary Access Password (TAP)

An administrator can generate a Temporary Access Password to provide temporary access to an account. This method overwrites the password and the required MFA method. It is ideal for a scenario where an end-user has lost their authenticator app. The helpdesk team can generate a TAP, which the user can use to log in and register a new method.

• FIDO2

FIDO2 authentication uses hardware tokens to provide secure logins into Microsoft Cloud resources. These hardware tokens must be purchased and registered by end-users before they can be used. While the maintenance and implementation costs are higher, it is a great, secure form of authentication. Combining FIDO2 with the authenticator app means the users can log in securely and still have a valid backup method.

Using Authentication Methods and Authentication Strength Policies

Eliminating phone-based authentication has become easier. Microsoft has announced authentication method policies, which allow an administrator to control the methods available to users. Authentication strength is supported for conditional access policies. This allows you to require a stronger form of authentication in specific scenarios.

By using these two controls, we can get rid of phone-based authentication in a granular matter. For me, an ideal scenario looks like this:

• Voice Calls as an MFA method are not allowed as it is prone to MFA fatigue.
• SMS can be used as a backup method for SSPR.
• FIDO2, or the authenticator app, is used for multifactor authentication.

To achieve this setup, we need to configure the following:

• Disable voice calls for all users using authentication method policies.
• Allow both the Authenticator app and SMS-based MFA.
• Create an authentication strength policy that requires FIDO2 or the Authenticator app.
• Create a new Conditional Access policy targeting your critical apps (Office 365, admin centers, ERP systems, password managers…) referencing the authentication strength policy.

Creating Temporary Allowlists

While eliminating phone-based authentication, you must keep some exclusions if other methods are unavailable to end-users. While a few alternatives (FIDO2 and Temporary Access Pass) exist, they don’t work for every user in every scenario. That is why it is always helpful to exclude a group from the authentication method policies, therefore can still use phone-based authentication. If an end-user is in a pickle, you can add them to the group to ensure they can keep working.

Oversight for allowlists should be integrated into a monitoring tool so you know when a new exclusion is added to the group. This can be done using the following KQL query in Microsoft Sentinel (after connecting Azure AD to Sentinel).

let MonitoredGroup = "MFA Exclusion Group";
AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName in ('Add member to group', 'Add owner to group')
| extend GroupForAlert = tostring(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[1].newValue)))
| where GroupForAlert == MonitoredGroup

Getting it Done

While Microsoft 365 tenants should move away from phone-based authentication, the road ahead is not as simple as I would like. Use cases for productivity and redundancy (having backup methods) still exist for phone-based authentication.

It is important to start by monitoring usage first and finding out why people use different forms of MFA. Afterward, you can slowly push users to other forms of authentication by combining authentication methods and strength policies.