Multi-factor Authentication Deployment Guide
Introduction
As threats to password security have increased in recent years, multi-factor authentication (MFA) has rapidly gained adoption as a method for increasing the assurance of authentication for consumer and enterprise web and mobile applications.
Authentication is generally accomplished by validating one of three types of factors: something you know (e.g. a password), something you have (e.g. an ID card), and something you are (e.g. a fingerprint). Multi-factor authentication employs two or more types of factors.
Web and mobile products most commonly employ the use of multi-factor authentication with a password used in conjunction with a time-based token that the user possesses, a push notification to a mobile app, or biometrics. However, the various approaches to MFA vary widely and present different tradeoffs.
In this guide, we compiled information on why an MFA solution is a no-brainer, and the best practices for deploying MFA. We review the results of a survey completed in partnership with IDG that shows where the priorities of your peers lie and how Identity and Access Management (IAM) play a part in strong authentication and security. Next, we explore things to consider before deploying your MFA solution, like policies and access needs. Finally, we provide further practical advice for people building multi-factor authentication for their applications, based on our observations working with engineering and product teams.
Using IAM with MFA in the Age of Megabreaches
There's no shortage of threats, including: malware, hacking, phishing, and social engineering and these tactics often lead to account compromise and credential theft.
8 Things to Consider Before Enabling Multi-factor Authentication (MFA)
Passwords are hard. The (what feels like constantly) growing list of security requirements are intended to make passwords secure, but, in many cases, they have had the opposite effect. Complex passwords that meet all the security requirements are often difficult to remember, so they are reused across many sites. Users scribble them on sticky notes. They weave in easily discoverable pet’s names, birthdays, and phone numbers. It’s no way to keep data secure.
Thankfully, organisations are starting to not just understand, but also support the concept that while access should be hard for hackers, it needs to be easy for legitimate users. And, the best way to make that happen is with multi-factor authentication, or MFA. MFA is a great way to secure your users’ apps and services from unauthorised access. Here are some points to consider as you plan your deployment.
1. User education
You’re deploying multi-factor authentication to reduce security risks from password-only access, but some users may see this as an inconvenience. They may be worried that this process change will take up time they feel could be better spent elsewhere - after all, entering an OTP or accepting a push notification does add time to the login process. Nonetheless, it’s critical to ensure everyone — from management to IT teams to security teams to end users — are aligned on why you’re making the shift to MFA. It is important to achieve buy-in from the entire organisation to ensure everyone plays a role in keeping the company secure. Do this through education, so each user can appreciate the security benefits they contribute to by taking this additional step.
For example, a common approach is to send out emails coming from IT on upcoming changes - well in advance of when these changes will happen. Be sure to include screenshots, FAQs, and contact information for employees to reach out for assistance.
2. Consider your MFA policies
A good MFA deployment will balance security with usability to avoid becoming too onerous, so you will want to consider how you define MFA policies to govern how and when a second factor is required. It may seem a bit counterintuitive, but sometimes the key is to prompt for step-up authentication less often instead of more. A well-considered risk-based policy configuration should trigger step-up authentication challenges only when necessary.
For example, a policy could ensure that a s