• United States




Security Myths: Users hate multifactor authentication

Oct 27, 20176 mins
AuthenticationIdentity Management SolutionsSecurity

Just stop bludgeoning them with the multifactor authentication (MFA).

In my last post, I talked about how I have a chance to spend time with a ton of different companies every year. This gives me a great opportunity to get an incredible education on the state of security across various industries. Many of my customers however, seem stuck in their own ways. I refer to this as being technologically inbred, or suffering from group-think. This group think often enforces bad habits or closes an organization off to making change in a positive direction. It’s with this in mind that I decided to kick off this blog with a series focused on the myths of security.

In the tradition of the Mythbusters we all know and love, I must say that not all of these myths are busted; today’s myth might just be one of those.

It should be obvious to all of us by now that leveraging muti-factor authentication (MFA) is a foregone conclusion. Expert analysis of nearly every recent breach shows consensus that if there had been an additional authentication factor, these breaches might have been stopped. So, as a security advisor, I always ask the folks I’m consulting with about their current or future plans for multi-factor authentication. I only seem to get something along the lines of:

  • We have it, but it’s limited in use. Only for admins connecting to the VPN.
  • We had it for a while, but the VP asked us to disable it. He was frustrated with it.
  • It’s such a nuisance, we don’t want to bother our users with it.

To be honest, these replies don’t really surprise me. There are so many poorly designed MFA solutions on the market that if you approach your project without being aware of the pitfalls, you might find yourself in the same position. To put it simply, the myth that users hate MFA is confirmed, but there are some simple solutions to this problem that we’ll cover here.

Stop harassing your users!

Imagine this scenario; you connect to a secure company application from home and are presented with an MFA challenge. After pulling out your phone and typing in the code you are granted access. Once on the network your child enters the room and says they need to check their school portal for a homework assignment. After closing your work browser your kid says, “on second thought, never mind,” and then walks away. Now you are forced to reopen your work browser and enter in the MFA once again. Yes, this would drive me crazy too. This is what I lovingly call “bludgeoning your users with MFA.”

The days of mindlessly harassing users with MFA should be a long memory. It simply doesn’t have to be this way. If you are not already using or planning to use risk-based adaptive authentication to make your MFA decisions, then you should be. Risk-based MFA uses what the industry refers to as ‘behavioral analytics’ or BA. To put it simply, BA is a process by which a security engine can establish a forensic profile about every one of your users, which includes items like the following:

  • 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.


Joe Campbell is Principal Security Advisor at One Identity. He is an accomplished software developer with an extremely diverse background that includes driving innovations for some of the world’s biggest companies, and pioneering new, award-winning technologies in wireless, RFID, visualization, communications and telephony. As a trusted security advisor, his experience in security and software architecture makes him a highly respected visionary and leader in the technology industry.

Before joining One Identity, Joe held the role of Principal Solutions Architect at Quest Software.

The opinions expressed in this blog are those of Joe Campbell and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.