If something is being described as “ok,” the speaker probably has some reservations about it. It’s not ideal, but it will do for now.

While “ok” can work for low-consequence items, it misses the mark when it comes to choosing the multifactor authentication component of a company’s data security strategy. Protecting user identities and data is far too important to leave to technology that is just “ok.” However, many organizations are unaware of key differentiators and choose an approach that doesn’t meet their needs. It’s critical to understand these differentiators, because they can determine whether a security strategy is successful.

One of the differentiators is the level of security that the authentication technology offers. Pre-issued passcodes are no longer a best practice and should be avoided. Many authentication platforms operate similar to token-based technologies with pre-issued one-time-passcodes that are based on a seed file. If codes are pre-issued then they are vulnerable to simple hacking like phishing, or through unauthorized usage or theft of seed files. This is not just a theoretical risk. It’s happened before, and has required replacing millions of hardware tokens. If the authentication code is pre-defined before the login, then it can be stolen and used for another login since the code is not linked to any specific login. As the code can be exploited by phishing, the system’s security can be significantly compromised.

Another point to consider is whether the technology bakes in challenge- and session-based security. Being challenge-based creates the foundation for organizations to set up highly secure remote login systems. With this approach, a code can be generated after the login session is created.  By waiting to generate the code until after the session is created – instead of relying on a pre-set bank of existing codes – the authentication system can see which computer workstation the login request is coming from. A code is then created and linked to the computer so the code can only be used from the same machine from which the request was originally initiated. If for any reason the code is intercepted, it cannot be used on any other device. This helps protect against even more sophisticated attacks.

Mobile authentication apps are widely used, but as an authentication mechanism, the “coolness” of the mobile app will quickly fade once an organization starts deploying it in the real world. Making sure an app is successfully deployed to everyone in an organization will not be hassle-free. Likewise, maintaining compliance so that everyone is using the most up-to-date version won’t be either. If an organization opts for an approach that requires user-deployed software, then it drastically increases user dependency since the success of the implementation relies on all users having the software deployed and up-to-date. In addition, the technology assumes that all users have a smartphone, which is not always the case. Some mobile apps also require a data connection to work, which can be impractical for employees to use while traveling. 

Another consideration surrounds the timeliness of the approach. When launching security technology that uses SMS as the delivery mechanism for the one-time-passcode (OTP), the SMS arriving on time becomes mission-critical. There is a significant difference between the code arriving within 10 seconds or two minutes. Some authentication providers claim that SMS delivery is not reliable enough and, as a result, they encourage the usage of pre-issued codes. However, this lowers the level of security significantly because the OTP cannot be generated in real-time. This is a dangerous trade-off to make.  

Last but not least, organizations should consider the level of flexibility and adaptation available. A best practice is using contextual information – such as login behavior patterns, geo-location and i.e. the type of login system being accessed – to help authenticate users logging in remotely. For example, if the user is logging in from a trusted location—such as the comfort of the user’s home—that they have logged in from before, they will not be prompted for an OTP. On the other hand, if the user is attempting to log in while traveling (i.e. from an airport lounge or hotel with public Wi-Fi), then an OTP is mandatory to gain access.

An “ok” bicycle helmet may conform to regulations, but parents still must make sure the helmet fits their child for it to work properly. A perfectly good authentication approach may safeguard critical user data, but it may very well not. Who is willing to take that risk without knowing for certain? Organizations should ensure that the multi-factor authentication approach they select does not make them vulnerable to the most common pitfalls in the market.