Mitigating the risks of deploying MFA

Note: everything discussed on this page is already covered in the improve section, it is summarised here to help communicate it to others, should you need to.

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:

User experience

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:

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.

System integrations

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.