Mitigating the risks of deploying MFA
Things that can go wrong when deploying MFA typically fall into three buckets:
user experience - in other words, does it annoy people
emergency preparedness - what happens when something goes wrong
system integrations - systems are often given user credentials to interact with other systems, and MFA might disrupt these
We address each of these, and how you can make sure they aren’t a problem, below:
Users will resist changes that don't naturally make their life easier. Done poorly, MFA can definitely be seen as a nuisance. Here are some things to make sure that doesn't happen:
There is very little benefit in asking users to complete MFA when they login using the same browser on the same device they use every day. The big SaaS platforms like Google and Microsoft already do a pretty good job of this out of the box, but might need a few tweaks on other platforms.
Modern authentication mechanisms like mobile app notifications or built-in security keys are very convenient and easy to use, where old mechanisms like SMS are slow and typically disliked by users. You can find more details in our blog post about MFA methods.
Now that you are no longer dependent on passwords alone, password policies are less important. You might choose to reduce password complexity requirements and remove password expiry. As a side note, password expiry is no longer considered best-practice because it cases users to choose poor passwords, see NCSC guidance on this.
As with forgotten passwords, users might lose their MFA device from time to time. In these cases IT support should be well rehearsed in supporting them through the re-enrollment process. This is normally very straight-forward, but is often a sticking point near the start of the roll-out.
Everyone makes mistakes, especially before that first coffee on a Monday. MFA greatly reduces the potential impact of falling for a phish, or choosing bad passwords.Users might find it hard to adjust to suddenly requiring MFA on multiple platforms. Give them a few weeks to get used to one platform before enabling on the rest.
Users might find it hard to adjust to suddenly requiring MFA on multiple platforms. Give them a few weeks to get used to one platform before enabling on the rest.
In the same vein as the previous point, it often eases the transition if you ask users to opt-into MFA first, and only later switch to enforcing for everyone. In addition to easing the initial load on support teams, it also helps if there are people that have been using MFA for a while around new users.
Prepare for emergencies
The point of MFA is to prevent people without MFA codes or devices from logging in. This means that it’s almost inevitable that a legitimate user will get locked out at some point because their device is lost or broken. What matters in these cases is that you’re able to get these users back to work as soon as possible. You should cover the following:
Have an emergency process to temporarily disable MFA for a user - Depending on the platform and configuration, this might be as simple as removing the user’s MFA device giving them a week to enroll a new one, or something that requires a bit of preparation like setting up an MFA exclusion group.
Have spare devices in all locations if you use dedicated hardware - If you intend to roll-out hardware security keys, you should make sure that you are able to get users a replacement device in a day or two. Alternatively, you might be comfortable asking users to use software tokens while they wait for new hardware.
MFA is a process that tests a user’s identity, and this can cause problems when systems (often legacy) pretend to be users when integrating with other systems. Typically this situation is relatively easy to deal with, for example, by excluding those accounts from MFA enforcement by using an MFA exclusion list and setting long randomly generated passwords (which makes sense as no humans will need to use this password).
In other cases, especially where the target platform does not allow exclusion lists in some configurations this can be a significant roadblock. Fortunately, in these cases there are ways to search for accounts that may be affected, and this should be done before deciding on an implementation plan.