Multi-Factor Authentication (MFA) is a basic yet very strong security measure used by many organizations to create a layered defense and make gaining access more difficult for unauthorized persons. MFA requires users to provide two or more forms of authentication: the first usually being “something you know” (e.g., password, pass-phrase, PIN) and the second being “something you have” (e.g., phone app, hardware token, YubiKey) or “something you are” (e.g., biometric data such as fingerprints or a face or retina scan).

With MFA deployed org-wide, the organization has a second layer of security to protect against common password-based attacks, such as Brute Force attacks, Dictionary attacks, Keylogging, Rainbow Table, and others. Basically, with MFA enabled, an attacker cannot gain access to a user’s account even if they know the password. This way, MFA serves as a critical defense against unauthorized access by requiring users to provide multiple forms of verification.

Scenarios that need MFA bypassing:

While MFA should always be enforced, there will be cases where it’s necessary to temporarily bypass MFA for specific users without compromising the overall security of the company.

Situations in which you may need to access applications without MFA are:

• Incidents with outages from service providers and maintenance windows for bug fixes
• Technical limitations for users who lost their phones without a spare phone around or software/hardware compatibility issues
• VIP Access for C-level Executives and System Administrators that may need a faster and more seamless experience for time-sensitive tasks

‍Implementation of a temporary MFA bypass in Okta

Now that we understand the need for bypassing MFA, let’s go over the steps to set up the policies and configurations in Okta. This setup will allow a specific user to access Okta SSO applications without Okta Verify or MFA, whenever that user exists in a “Bypass MFA” Okta group. This way, the MFA bypass can easily be reversed by simply removing the user from the Bypass MFA group.

1. Start by creating an Okta group and name it as per your company conventions with a hint as to what the group is about. For example: Temp Bypass MFA
   ‍

‍

‍

2. Add a new policy from Security > Global Session Policy. The new policy should be on top with Priority 1, so that it kicks in and does not go to check other policies with lower priority. When you add a new policy, it will be on top with Priority set to 1 by default.

‍

‍

‍

‍

3. Add a rule inside the Bypass MFA policy. When you create a new policy, it will automatically show a pop-up to add a rule. Give the rule a name such as “Bypass MFA”. This rule will allow for granular control when a user authenticates to start an Okta session. Here, the most important fields to modify are the time limits for “global session lifetime” and “global session idle time”, and to set “MFA is not required”. The screenshot below shows what each field should look like after making the changes. Click on Create Rule to save the new rule.
   ‍

‍

‍

4. The Final step is to add a user to the Temp Bypass MFA group, this will allow users to access Okta and Okta apps without going through the MFA process. It is always a good idea to test with a test Okta account to confirm the setup works as expected.

‍

Note: If Okta still asks for MFA after going through all the configuration steps, then Authentication Policies will need to be adjusted per application to allow access via password only. The authentication policy should look like the screenshot below, where the Password is the only requirement

‍

Define a time duration to end the temporary MFA bypass and restore regular authentication

As this is a temporary MFA bypass concept, a part of this process is to define how long you want to allow your users to bypass MFA. For example, a user who lost their phone may need this freedom for a day, whereas a System Administrator may need to bypass MFA only for a few hours. It is simple to reverse the MFA bypass; the user will once again require MFA when removed from the Temp MFA Bypass group. Based on this use case, it is recommended to remove the user from the bypass group as soon as possible. This will ensure that the security of MFA once again applies to the user’s Okta account.

Automating MFA bypass requests

If you have a small team and are receiving a lot of requests to bypass MFA, you can go a step further and use the fancy automations.

You would start with creating a Jira Request type with approvals in the workflow. Once the Jira ticket is approved, it can trigger a workflow in Okta. Then, you would set up the Okta workflow to trigger if the Jira ticket is approved, and then add an action to add the user to the Temp MFA Bypass group. To revert the MFA requirement, you can create the workflow for time-based group membership, which will do the job of removing the user from a group after a specified amount of time. In the event that you have multiple Temp MFA Bypass groups, with each group allowing different durations of MFA bypass, the Okta workflow can have conditions to scan each of these groups and remove the user from the group once they reach the set time limit.

‍

‍Security should never create a blocker for your teams, so it’s always a good idea to proactively configure and roll out a temporary MFA bypass setup for users who may need it. Having a temporary bypass for specific users ensures that your employees stay productive and that your company’s overall security is not compromised.