Security Myths: Users hate multifactor authentication

• Does this user belong to a risky group, like an admin group or DBA team?
• Have I seen this user/browser combination before?
• Is the user connecting during a typical time window
• Is the user violating any geographical rules, like a blocked nation or geo-velocity rules?

Of course there are many more indicators of whether or not a user is exhibiting strange behavior. Although, when combined with other factors like blacklists, whitelists, network rules and more, an adaptive risk-engine will do one of three things:

1. Prompt suspicious behavior for MFA, or
2. Allow users with low risk on the network, or
3. Block those that are an obvious threat.

When these rules are applied correctly, even the user in question will agree that the prompt they just saw actually makes sense. I often draw the analogy of when you are travelling out of the country and your credit card calls you asking if the purchase in Dubai was actually you, the customer is grateful for the diligence of the credit card company and happily confirms. You can have this relationship with MFA and your users too, as long as you aren’t bludgeoning them with MFA.

There’s more to token types than the type of phone you have!

Another huge roadblock for MFA is the lack of token generation choices. In order for most MFA systems to know this is you, you need to have some device or application that you can use to generate a one-time-password (OTP) that the system can validate.  This can be done in a ton of different ways, from SMS text messages, desktop applications, and key fobs, to name a few. 

It is important to keep in mind that whatever token might be the best for you, might not be the best for your users. For example, how do you expect someone with impaired vision to read a key-fob or SMS message? How would you expect users mid-flight over the Atlantic to be able to connect to a cloud service to unlock their laptops? This is typically the situation where the VP calls up and says, “Turn this MFA off now!”

To put it simply, the MFA solution you decide on should have a collection of token types that are flexible to handle any use case and with any user’s culture. As soon as you force your all users to fit one token model, you are fighting a losing battle.

Do it right

While I’ve seen many other reasons why MFA projects fail (like incompatibility with the RADIUS protocol or lack of integration accelerators), these two reasons always seem to be at the top. MFA has either been implemented in a way where users feel harassed, or has been levied onto users in a way which doesn’t match their culture.

The solutions are simple:

1. Implement an intelligent, risk-based, multifactor layer that is smart enough to only show users an MFA challenge when necessary.
2. Provide a large selection of token choices and use-cases; security simply cannot interfere with workflow.

Put these two features at the top of your requirement list and you are already on the right track to success.