MFA Removal: Juggling Security And User Experience
Heya,
Multi-factor Authentication (MFA) is a crucial security measure in Customer Identity and Access Management (CIAM) systems, providing an additional layer of protection against unauthorized access for users that register themselves.
However, there are situations where users may need to remove or temporarily bypass MFA. There is a balance between maintaining robust security and accommodating legitimate user needs when it comes to MFA removal in CIAM systems.
Why MFA Matters
Before diving into the specifics of MFA removal, let’s look at why MFA is critical for protecting user accounts in CIAM systems:
Enhanced Security: MFA significantly reduces the risk of unauthorized access, even if passwords are compromised. In 2019, Microsoft found that MFA blocked “over 99.9 percent of account compromise attacks”. The attacker may have the login id and password, but they won’t have access the additional factor.
Compliance: Many regulatory frameworks require or strongly recommend MFA for sensitive data protection. An example is NIST AAL2 or higher.
User Trust: Implementing strong security measures like MFA helps build and maintain user confidence in the safety of their data in your system.
There are valid reasons why a user might need to remove or bypass MFA, such as lost devices or technical issues.
The challenge lies in verifying the legitimacy of these requests in an automated fashion. You need to implement secure processes for MFA removal or bypass.
Reasons For MFA Removal
There are a number of reasons why a user might want to remove MFA from their account. The goal of letting someone remove MFA is to allow them to continue to access your application. Don’t forget to encourage them to re-add a different MFA method, because, as mentioned above, MFA increases account security.
Consider a lost or inaccessible MFA device. MFA methods like SMS code delivery or TOTP are often tied to a device such as a phone. Other devices such as yubikeys can also offer an additional factor. Users may lose their smartphone or hardware token, making it impossible to generate MFA codes.
MFA is affected by software bugs, compatibility problems, or service outages just like any other piece of software. These might prevent users from succeeding with MFA.
Often MFA methods send a message to an email address or phone number. Users change these phone numbers or email addresses associated with their MFA method, especially if your application is seldom accessed. In this case, they have no way to access the code.
Multiple MFA Methods
Multiple MFA methods can side-step some of the reasons to remove MFA methods. After all, if the user has set up MFA with two phone numbers and two email addresses, the likelihood that they’ve lost access to all those is lower than if they only have it set to go to one email address.
Your CIAM system should support multiple MFA methods and types for each user account, and you should encourage your users to set up multiple methods.
Automated Removal
If you want to support automated removal of MFA, build a plan for allowing MFA removal without human intervention. It won’t be a one-and-done process, so plan to revise it regularly.
First, start with risk assessment. Build a way to evaluate the risk level of the account or accounts, associated data and available functionality. Consider the user's recent activity and login patterns. If, for example, there are a number of requests from new devices, disallow MFA removal. You’ll want to make sure you assess the potential impact of a compromised account. An admin account that is compromised has greater impact than a normal user account, and thus removal of MFA on the former type of account may be entirely disallowed.
If a user starts the MFA removal process, clearly explain the security implications of removing MFA. This might include the threats of account takeover or limited functionality. You want your users to perform this action only if they intend to do so, not by accident and not without knowing the ramifications. Provide detailed instructions for the removal process so the user knows what to expect, and offer alternatives to complete removal such as changing MFA method.
Set up logging and monitoring so you are aware of any issues. Log all attempts to remove MFA, whether successful or not. This should go into a centralized SIEM system, not a CIAM report that will be siloed and seldom examined. Implement additional monitoring for accounts that have recently removed MFA and set up alerts or other systems to check for suspicious activities post-MFA removal.
What a suspicious activity is depends on the application at hand. Some examples include:
A financial application should monitor for unexpected large transactions.
An ecommerce application should check for new delivery addresses being added.
An ERP application should watch out for data exports or unrestricted queries.
Notify the user in multiple ways when MFA removal is requested and completed. Consider a cooling-off period, which we’ll examine further below. In any case, provide clear instructions on how to cancel the removal if it was not initiated by the user.
As mentioned above, this is not a static process. Make sure you periodically review and update your automated MFA removal processes. Regularly train your support team on the latest MFA removal protocols, such as what should happen when suspicious activity is found.
The whole point is to enable a user to maintain secure access, so you want to encourage the user to re-enable MFA after they’ve removed it because of accidental circumstances. Provide resources to help users understand the importance of MFA, offer guidance on what to do if they lose access to their MFA method, and make it easy for users to set up a new MFA method or methods after they have removed it.
Non-Automated Removal
After the analysis above, you may decide that there should be no automated way to remove MFA access. The protection that MFA offers could be so important that human interaction must be required to remove it.
In this case, document exactly how a user can request that MFA be removed. Prepare your customer support team to handle these requests, verify the user, and protect against social engineering. Don’t stint on the training, because your team will be getting these calls.
If you decide automated MFA removal will work for you, you’ll likewise want to build in verification. Let’s examine some of those options.
Verification Methods
When a user requests MFA removal, it's crucial to verify their identity thoroughly to prevent unauthorized access. Here are some effective verification methods that don’t rely on the aforementioned customer service team:
Correct Authentication, Including MFA
Before allowing removal of an MFA method, require the user to log in with their existing credentials, including MFA. This ensures that the person requesting the removal has access to the account and the MFA device.
This is a good option if your end user knows they will lose their MFA access and they remember to remove it from their account. This option does not handle unexpected loss of a device or other MFA method access.
Additional Authentication
You can find other authentication factors. These are not used in the usual login process, but can offer assurances that the user is not an attacker trying to remove MFA from a victim’s account.
Examples include:
Knowledge-based questions (e.g., account-specific details, recent transactions)
Possession-based factors (e.g., a backup code provided during MFA setup, email to a previously set up alternate email address)
Biometric factors (if captured on registration and use is compliant with privacy laws)
Phone call to a previously set up phone number.
You’ll need to build software to:
Gather the information needed to check these authentication methods. You can do this at registration or when adding MFA methods.
Prompt a user to offer these additional methods to disable their MFA.
Personal Information Verification
You can use personal information verification as another authentication mechanism. This is a common varient of knowledge-based questions, but should be used carefully. You want personal information that is well-known to the user, but not discoverable by the attacker.
Examples include:
Account-specific information (date of account creation, last password change)
Transaction history details (for financial or e-commerce accounts) such as the last item that was ordered.
Service-specific information (subscription details, usage)
Partial personal identifiers (last 4 digits of the credit card on file)
When using personal information for verification, it's crucial to balance security with privacy concerns. Avoid using easily guessable or publicly available information, and always handle this data in compliance with relevant privacy laws and regulations. Require more than one piece of information.
Cooling-Off Periods
A cooling-off period introduces a delay between the request to remove MFA and the actual removal. It is essentially a rate limit for MFA removal. This inconveniences the end user legitimately removing MFA, but alerts them if an attacker is trying to do to same.
Here's how a cooling-off period typically works:
Initial Request: The user logs in and requests MFA removal. The system acknowledges the request but doesn't process it immediately.
Notification Phase: The user is informed about the cooling-off duration, which could range from 24 hours to 7 days. The more damaging unauthorized access, the logner the period should be.
Cooling-off Phase: During this period, the account remains protected by MFA. If the user has their MFA method, they can access their account normally. Of course, in this situation, if the user has lost their device, they have no access.
Secondary Verification Request: Near the end of the cooling-off period, the user is required to verify their identity again.
Confirmation: After their identity is verified, the user must again confirm their desire to remove MFA.
Remove the MFA method.
Monitoring Phase: You should apply extra scrutiny to account activity for a period after MFA removal, as mentioned above. This can include blocking behavior that would normally be allowed.
The system sends periodic notifications about the pending MFA removal during the cooling-off phase through available channels, including messaging like email and in-app notifications. All messages should include an option to cancel the removal request.
This cooling-off process gives legitimate users time to notice if someone else has requested MFA removal on their account, while still giving an opportunity to remove MFA without any human interaction. It also delays the process for attackers, which means they operate less efficiently.
In some cases, users don’t want to remove MFA entirely, but rather disable it for a certain period of time. Let’s look at that next.
Temporary MFA Bypass
A temporary MFA bypass might be more appropriate than a complete removal. Here are two such scenarios.
International Travel
A user traveling to a country where they may not have reliable access to their usual MFA method (no cellular service for SMS codes or no access to their authenticator application) might want a temporary bypass.
Build out this flow to support this use case:
Allow the user to request a temporary bypass before their trip.
Rigorously verify their identity before granting the bypass. Make sure they are using correct credentials and MFA before allowing this request.
Set a specific time limit for the bypass, such as the duration of their trip.
Implement additional monitoring on the account during the period where MFA is temporarily disabled. Watch for abnormal behavior and prohibit or delay it if needed.
At the end of the time limit, automatically require MFA for the next log in.
Disaster or Emergency
During a natural disaster or widespread emergency that affects a significant number of users in a particular region, a temporary MFA bypass might be necessary. In contrast to the above travel scenario, there are large numbers of people affected and they are unlikely to have planned for the situation.
A bypass is helpful here because:
Users may have lost access to their MFA devices or methods.
Quick access to accounts might be crucial for emergency services, financial transactions, or communication.
To implement a controlled MFA bypass for affected users, you’ll need to:
Verify users through alternative means, such as those mentioned in the Possible Verification Methods section above.
Do your best to limit the bypass to users in the affected geographic area. You can use a location to IP address mapping database to do so.
Set a short time frame for the bypass, reassessing the situation regularly.
Implement additional monitoring and fraud detection measures.
Require users to re-enable MFA once the emergency situation has stabilized
While neither of these scenarios are common occurances, they are both real-life situations where a temporary removal of MFA can help your users.
Summing Up
Allowing users to remove or bypass MFA in a CIAM system is a delicate balance between security and user experience. By implementing robust verification processes, cooling-off periods, and temporary bypass options, organizations can accommodate legitimate user needs while maintaining data and application security. Don’t forget to encourage your users to re-enable MFA after they’ve removed it.
Regular review and updates of your MFA removal processes will help ensure that you're providing the best possible security for your users while still offering flexibility when needed.
Remember, the goal is to create a secure environment that users can trust, while also providing the flexibility to handle real-world scenarios that may require MFA removal or bypass. By following these guidelines and best practices, you can achieve this balance and provide a secure, user-friendly CIAM system.
Dan