Both Microsoft and Google recently said that enabling Multi-Factor Authentication (MFA) will eliminate 99.9% of account breaches and highly recommend this security feature be enabled. With MFA being available on most Office 365 tenants and so many options available for MFA, there really is no excuse why MFA is not yet enabled on all user accounts. This blog and embedded video highlights several blockers I have heard from organizations and options to work around them.
Although the recommendation has been stated for many years, there is still a surprisingly low number of accounts enabled for MFA. In the same article cited above, Microsoft stated that less than 10% of their global administrator accounts in Office 365 are enabled with MFA. We can assume the number of general user accounts enabled for MFA is far less. There are deployment and communications guides available from Microsoft about best practices to deploy MFA, so I will not rehash those here. What I will highlight are several blockers, suggestions for mitigations, and then provide video examples of each MFA option.
As each item is highlighted below, remember that MFA is not required for every logon. If it were, it would cause frustration and a poor user experience. There are advanced settings available in Azure Active Directory such as Conditional Access Policies that will trigger MFA logons only under specific circumstances. For example, MFA is not typically needed when a user logs on from a trusted network such as an office environment protected by a firewall. But when a user is logging in from an untrusted and unprotected network such as a home office, you will want MFA to be used for extra security. You also may want to allow a user to logon using MFA from an untrusted network and not be prompted again for a period of time such as 14 days (default setting). Settings such as these enable us to secure an environment with MFA without being intrusive and causing user frustration.
Examples Used in Embedded Video
Example One: Call to Phone
First, I’ll demonstrate on an iPhone what happens when I try to logon to my demonstration Office 365 account using a PIN that is sent in a text message sent to my phone.
Example Two: Text Message to Phone
Second, I’ll demonstrate on an iPhone what happens when I try to logon to my demonstration Office 365 account using the phone call verification option to my phone.
Example Three: Notification Through Mobile App
What I like even better than a phone call or text message for MFA is using the Microsoft Authenticator App with a push notification. Watch how this works in an Android Pixel XL phone.
Example Four: Verification Code From Mobile App or Hardware Token
Here, I will use the Microsoft Authenticator App on an Android Pixel XL phone to get a constantly changing PIN (every 30 seconds) that I will use to enter in the MFA Field.
Common User Blockers to Enable MFA and Mitigation Suggestions:
1. Users do not like receiving a text message when MFA is triggered
Mitigation: There are many options available for MFA in addition to text messages. Users may choose any of the options the administrator has made available. See above for a list of options.
2. Users do not have company issued cell phones and do not want to use their personal cell phones.
Mitigation: One of the MFA options available is to receive a phone call with a dynamic code to logon with. This can be predefined as a desk phone telephone number so a personal cell phone does not need to be used.
3. Text messages are sometimes slow to be received with dynamic access codes
Mitigation: I have personally used Azure AD MFA with text messaging and other methods for years and have never had this issue. I have also switched cellular carriers between Verizon, T-Mobile, and Xfinity Mobile and again, have never had an issue with MFA related text messages being received longer than just a few seconds. But, do not take just my word for it. Rather, pilot MFA using text messages and the other authentication methods highlighted above with a team of users. Document the user feedback and include it in your company communications when ready to enforce MFA across the entire environment.
4. Users reject the additional security logon step
Mitigation: Enabling MFA is not just a technical implementation, but something that requires executive leadership support to enforce the policy for everyone. Even just one exception to this policy is a security breach just waiting to happen. In your communications plan to users about the new logon process, explain the onslaught of attacks organizations such as yours experience each day. Review logs for attacks on your own organization and use them as an example. Then highlight recommendations such as those from Microsoft and Google who have studied MFA results and determined that 99.9% of all account breaches can be eliminated when MFA is enforced.
