Eight things to consider before enabling multi-factor authentication (MFA)
There are numerous paths cybercriminals will take to try and infiltrate systems, files, and devices. While threats seem to grow in complexity every day, there are measures businesses can take to prevent unauthorized access on the front end. While strong passwords, employee phishing training, and email filtering are all important security measures, none of these measures are as effective as multi-factor authentication (MFA).
Anne Neuberger, U.S. Deputy National Security Advisor for Cyber and Emerging Technology, believes—based on evidence presented by key tech industry executives—that 80–90% of cyberattacks could be prevented by utilizing MFA. “Because it is such a helpful way to address cyber vulnerabilities, it’s one of the five things President Biden mandated be rolled out across the federal government quickly as part of his executive order in May [of 2021],” she explained.
The slow adoption rate of MFA in U.S. companies contributed largely to the uptick in successful ransomware attacks in the past two years. Despite its efficacy in preventing these types of attacks, businesses have been reluctant to add another step in their user workflow out of fear that it could cause confusion or create inefficiencies in their workflow. Thankfully, organizations are starting to not just understand, but also support the concept that while access should be hard for hackers, it can be easy for legitimate users.
The best way to make that happen is with MFA, which can eventually be even easier for users than keeping up with password management. It is a great way to secure your users’ apps and services from unauthorized access. Here are some points to consider as you plan your deployment.
1. Conduct 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. While entering a one-time password or accepting a push notification can add time to the login process, statistics show that it can stop over 90% of password-based cyberattacks. It’s critical to ensure everyone—from management to IT teams, security teams, and end-users—is aligned with the shift to MFA.
It is important to achieve buy-in from the entire organization to ensure everyone keeps the company secure. Doing this through education will ensure that each user can appreciate the security benefits they contribute. For example, a common approach is sending 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 so employees can reach out for assistance.
2. Consider your MFA policies.
A good MFA deployment will balance security with usability to avoid becoming too strenuous, so you will want to consider how you define MFA policies to govern how and when a second factor is required. It may seem counterintuitive, but sometimes the key is to prompt for step-up authentication less often than 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 second factor is required every 8 hours when logging in from a known network, or only required when logging in from a new device or new geolocation. Or, you have a specific group of user accounts with broad access to sensitive data, and you need a stricter policy for them. For example, developers in your organization with access to source code, or executives with access to sensitive data may need to provide a stronger factor type or require additional MFA prompts when logging into sensitive apps.
MFA allows you to require a second factor when these types of user groups attempt to access the sensitive resource, but not when they access the company events calendar. The basic idea is that additional verification should be as transparent as possible to the user to foster a good user experience without compromising on security.
3. Plan and provide for a variety of access needs.
There will be scenarios where a user has internet access but has little or no service from their cell phone carrier at the time. This could be on a Wi-Fi-enabled airplane, at a back-country home, or simply in the basement of a large concrete building. In these cases, where voice and Short Message Service (SMS) may not be workable, mobile app push authentication or one-time passwords (OTP) are better choices, as the communication is encrypted over the phone’s internet connection. Hardware devices that generate event-based or time-based one-time passwords (TOTP) don’t require a communication channel. They are also more difficult to tamper with or copy.
Along with the cost to deploy, a physical device becomes one more thing for employees to carry around, forget at home, or lose. Thus, these factor types may not be the go-to choice for short-term contractors. When it comes to MFA factors, there are many options to solve for various scenarios. Choose what works best for each scenario in your organization, keeping in mind that multiple policies and factors can be used when there isn’t a one-size-fits-all solution to accommodate all situations.
Generally speaking, these deployment tips ensure both enhanced security and a great user experience:
For hardware that supports it, allow users to use biometrics as their second factor (Windows Hello, Touch ID, etc.). This simplifies user experience and addresses scenarios where users may not have internet access.
Make at least two types of factors available for users, so they have one as a backup.
Allow users to self-service reset their factor (e.g., resetting an authenticator app on a lost phone).
Start your deployment by only enabling strong factor types (mobile app authenticators, push notifications, biometrics, etc.).
4. Think twice about using SMS for OTP
SMS, or Short Message Service—better known as texting—is familiar and easy to roll out. With the prevalence of cell phones and tablets, it has become one of the most common communication channels for OTP delivery. SMS has generally been assumed to be secure enough for this purpose, but that is because the infrastructure is primarily proprietary. Research shows that SMS security is lacking, and not only when it comes to documented vulnerabilities. With SMS, you trust the telecom companies, and even if you trust that they have security best practices in place, there is always a risk of compromise through spoofing and social engineering. In many cases, it’s not technically challenging for an attacker to port your number to a device they control and access to your SMS messages and OTPs.
Common issues with using SMS OTP as an MFA factor:
a. SIM swapping/SIM hacking
The SIM card (subscriber identity module card) in your phone delegates which wireless carrier your phone should connect to and what phone number to communicate with. In a SIM swap/SIM hack attack, a threat actor impersonates you and convinces the carrier that they are, in fact, you. Ultimately, your phone number is assigned to a new SIM card on a different phone.
While SIM swapping/SIM hacking has been an issue for years, this attack type became publicized in 2019 when Twitter CEO Jack Dorsey’s own Twitter account was victim to a group of hackers that convinced the wireless carrier tied to his phone number to switch that number to a new phone in their possession. In a SIM swap/SIM hack, threat actors do not need access to any of your physical devices to gain access to your accounts—once your number has been switched to a device in their possession, they can receive all SMS OTP messages tied to your online accounts.
b. Lost and synced devices
You’ve lost your phone—it's annoying but happens occasionally. What happens when your phone number is connected to your banking apps, social media, and more? In general, multi-factor authentication is considered a combination of two pieces of evidence that prove you are who you say you are—a knowledge factor (something you know), an inherent factor (something you are), or a possession factor (something you have). Using a password and an SMS OTP as a factor is a combination of knowledge and possession factors. But if you’ve lost your phone, in theory, you should no longer be able to receive messages to validate your identity. However, because we can now sync messages across multiple devices, you still have access to your accounts, even if you have lost the device considered your second factor. It is insecure when you can forward text messages to your email—which may have an insecure password, or if you’re using a VoIP (Voice over Internet Protocol) number that can be accessed on any device which may or may not have a PIN code.
c. Taking over your online wireless account
Keep in mind that most standard wireless providers allow you to view text messages via your online account within their web portal. If your account for the web portal isn’t protected with a second factor, and if you are using an easily guessed password used with many online accounts, a threat actor could monitor your account for an SMS OTP message that you initiated for a banking app, Facebook, etc., giving them access to those accounts.
d. Social engineering and phishing
Unfortunately, SMS OTP is not the only form of authentication susceptible to social engineering phishing attacks. Less secure factors such as passwords and security questions are equally susceptible. In a social engineering attack, a threat actor posing as an employee from a service you trust convinces you to hand over your account credentials, and in many cases, the SMS OTP is sent to your device as well. For example, if you get a call from your “bank” telling you that they need immediate access to your account for security purposes, you may inadvertently give a threat actor your username/password combination, as well as the SMS OTP code which gets sent to your phone during the login process. Phishing attacks aren’t just specific to email. You can receive a phishing text message as well. If you type a username/password combination into a malicious website, even by accident, the threat actor could use a few of the actions mentioned above to take over your account.
While the National Institute of Standards and Technology (NIST) recommends against using SMS for these reasons, ultimately, you need to perform a risk assessment based on your users, use cases, and the data being secured. MFA with SMS is still better than no MFA at all.
5. Check compliance requirements carefully.
Most IT compliance standards such as the Payment Card Industry Data Security Standard (PCI DSS), Sarbanes-Oxley (SOX) Act of 2002, and the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule mandate strong user authentication controls, making them likely motivators for an MFA deployment. It seems obvious, but if your goal is to meet such standards, make sure to have a detailed understanding of the requirements so you can tailor configuration and policies to them. For example, PCI and HIPAA compliance require substantial authentication, at least two strong methods of these three: something you know, something you have, and something you are. And while SOX focuses less on technology, to pass an audit, you’ll still need to prove that your organization’s finance and accounting data is secure. IT compliance requires implementing relevant standards, but it also requires an ability to prove that you’ve met them. Make documentation part of your configuration and implementation so you’ll be able to quickly and confidently prove in an audit that they’ve been completed. Your future self and organization will thank you.
6. Have a plan for lost devices.
In a typical MFA deployment, the second authentication factor is “something you have”. In the case of SMS, voice, or an authentication app, such as Okta Verify, Google Authenticator, or similar services, the user has their phone. In the case of a hardware token from YubiKey, RSA, or similar services, the user has their token. However, anything a user has can be lost. A procedure for handling lost devices should already be part of your comprehensive IT helpdesk playbook. Extend it to include devices used for MFA, and ensure that reporting a lost device results in:
Expiring any current sessions and requesting the user re-authenticate
Disassociating the device from the user’s account and access rights
Remote wiping of corporate information on mobile devices (if necessary; usually done on company-owned devices)
It’s also important to audit the user’s account activity before the point in time when the device was lost, to document any unusual activity. If there is anything suspicious, consider the possibility of a breach and escalate accordingly. Once the immediate security concerns are handled, the focus should shift to getting the employee back to work with a replacement device or login method. For example, an alternative process, like calling the IT helpdesk to verify identity requirements, can allow the employee to be productive while replacement factors are implemented.
7. Have a plan to deploy MFA to remote workers.
Remote and hybrid work has become the new norm, so your organization must bolster security as more employees work virtually. Remote work brings a new challenge for both deployment and troubleshooting. To address deployment-related issues, it’s best to enable factors that allow users to quickly get up and running (e.g., built-in device biometrics or mobile app authenticators).
This way, your users do not need to wait for an additional hard token to be shipped to them. This is also where end-user communication becomes critical to ensure they have the resources they need to get set up and troubleshoot. In the case of new employee onboarding, some organizations will host virtual onboarding sessions and send setup instructions to the employee’s personal email address before they have access to their corporate email.
8. Phase your deployment and be prepared to review and revise.
Complex deployments and policies are rarely a perfect fit the first time. With a process change that will affect all employees, it’s always a promising idea to track the effectiveness of an MFA solution as it is being deployed and used in order to analyze and refine policies accordingly. Ideally, you will be able to phase your deployment in a manner where IT/security will start using MFA first. From there, you can expand to other user groups. Get comfortable with the auditing functionality early in the process, and it will be invaluable for troubleshooting and adjusting policy configuration. Once you’ve deployed MFA to users, use auditing tools to spot-check adoption and use. A mechanism that allows user feedback to be reported could also be good. And while users may not always take the time to provide written feedback, an audit trail gives you some visibility into what they experienced. Did it take them three tries to enter their OTP? Did they give up? Problems like this could indicate a misconfiguration, a gap in user education, or a scenario that wasn’t considered in the initial rollout plan. Using audit tools and encouraging employee feedback assures all stakeholders that the system is working as intended and new security policies are being successfully adopted.
Reach out to your local MMA representative to learn more about multi-factor authentication and available resources.
This document is not intended to be taken as advice regarding any individual situation and should not be relied upon as such. Marsh & McLennan Agency LLC shall have no obligation to update this publication and shall have no liability to you or any other party arising out of this publication or any matter contained herein. Any statements concerning actuarial, tax, accounting or legal matters are based solely on our experience as consultants and are not to be relied upon as actuarial, accounting, tax or legal advice, for which you should consult your own professional advisors. Any modeling analytics or projections are subject to inherent uncertainty and the analysis could be materially affected if any underlying assumptions, conditions, information or factors are inaccurate or incomplete or should change.
