In my last post,\u00a0I 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\u2019s 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\u2019s 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\u2019m 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\u2019s 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\u2019s such a nuisance, we don\u2019t want to bother our users with it.To be honest, these replies don\u2019t 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\u2019ll 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, \u201con second thought, never mind,\u201d 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 \u201cbludgeoning your users with MFA.\u201dThe days of mindlessly harassing users with MFA should be a long memory. It simply doesn\u2019t 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 \u2018behavioral analytics\u2019 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 windowIs 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:Prompt suspicious behavior for MFA, orAllow users with low risk on the network, orBlock 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\u2019t bludgeoning them with MFA.There\u2019s 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.\u00a0 This can be done in a ton of different ways, from SMS text messages, desktop applications, and key fobs, to name a few.\u00a0It 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, \u201cTurn this MFA off now!\u201dTo 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\u2019s culture. As soon as you force your all users to fit one token model, you are fighting a losing battle.Do it rightWhile I\u2019ve 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\u2019t match their culture.The solutions are simple:Implement an intelligent, risk-based, multifactor layer that is smart enough to only show users an MFA challenge when necessary.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.