Implementing Okta MFA: 4 Things to Consider

It’s now common knowledge that implementing multi-factor authentication (MFA) is a no-brainer. Not enabling multi-factor authentication is like leaving the door to your home wide open, with all the lights on, with signs pointing to where your precious belongings are stored. But with that said, implementing MFA is easier said than done. 

In our whitepaper, Multi-factor Authentication Deployment Guide, we outline 8 things to consider before enabling MFA:

1. User Education
2. Consider your MFA policies 
3. Plan and provide for a variety of access needs
4. Think twice about using SMS OTP authentication
5. Check compliance requirements carefully 
6. Have a plan for lost devices
7. Have a plan to deploy MFA to remote workers
8. Phase your deployment, be prepared to review and revise. 

We don’t have time to go over every one of these items here, so in this post, I’ll focus on only the bolded items above. I’ll outline how features in Okta and the resources available to customers map to the considerations described in the Multi-factor Authentication Deployment Guide.

Consider your MFA policies

To avoid making your MFA deployment onerous with users being constantly prompted for a second factor, it’s important to define MFA policies that are tied to the risk associated with a login event. This is, of course, going to vary by organization — some of our customers will prompt users for MFA every couple of hours regardless of where they are located, some customers will prompt for MFA only when a user accesses apps outside the office, while others may only prompt for MFA on critical applications. The choice is yours, but here are some general guidelines:

1. Prompt users for MFA every 8-12 hours. To ensure high assurance sessions, consider setting the session time in Okta anywhere from 8-12 hours, and prompt users for MFA when the session expires. While this may seem aggressive, because the purpose of multi-factor authentication is to validate users are who they say they are when logging in, it’s important to continuously verify this. 

Here’s how you can create session-based MFA policies in Okta - In the admin console, go to Security > Authentication > Sign-On. When editing individual rules, you’ll see an option for Session Lifetime. 

2. Combine Risk-based Authentication with your factor choice. While you should consider enforcing MFA on every login, in some cases, you may be comfortable with less secure factors for low risk logins. For example, for low risk logins you could require a password and SMS OTP, but for medium risk logins, requiring a stronger factor like Okta Verify Push or WebAuthn is preferred. Ultimately, using strong factors like Okta Verify Push and WebAuthn are also a great foundation to go passwordless. 

Here’s how you can combine Risk-Based Authentication with a specific factor type:

In the Okta admin console, go to Security > Authentication > Sign-On.

If risk is low, allow just SMS OTP, or Password + Okta Verify Push.

If risk is high, only allow WebAuthn.

Bonus deployment tip for Risk-Based Authentication 

If you’d like to test Risk-based Authentication and track entries in Syslog using a phased approach, but do not want to impact the end user experience when modifying policies, try the following: 

• Choose the “high”, “medium”, or “low” options in the drop down, but do not modify any other policy settings 
• You can do this for each rule within your sign-on policies, or add new rules with the risk level settings that mock the existing end user experience

You can choose to do this for a subset of users initially to track the “high”, “medium”, “low” Syslog entries, without modifying end user experience based on the risk level. When ready, you can modify the policy rules to also change the access response based on risk level. 

Plan and provide for a variety of access needs 

It’s important to plan your MFA deployment to support a range of factor needs. Different user populations may require different factor options. Here are some examples - 

Most FTEs 

• Daily login using password + Okta Verify Push or WebAuthn
• When they do not have internet access - use WebAuthn 

Executives with access to sensitive data 

• Only allow WebAuthn 

Partners accessing resources in your Okta tenant

• Enable Okta Verify OTP for partner logins 

Call center works that cannot bring their phones

• Email OTP (when their email is not federated to Okta)
• Security key (ie Yubikey)
• WebAuthn using on-device authenticators like Mac Touch ID or Windows Hello (in scenarios where users are assigned to a single machine)

Temporary Interns

• Daily login using password + Okta Verify Push 
• Allow SMS OTP as a backup 

Thankfully, there are a variety of factor options available in Okta, and using MFA you can enable specific factor types for different groups. Here are some MFA deployment tips - 

1. WebAuthn allows you to enroll multiple devices. When you have WebAuthn enabled in Okta, users can enroll up to 5 devices on their account. If the user misplaces a device, they can use another WebAuthn device as a backup. For example, here’s what my account looks like:

You’ll also notice we don’t allow SMS OTP as a factor!

2. Enable Okta Verify OTP for partners. Okta Verify OTP is a free factor available to all customers and increases the fidelity of partner logins - enable it for partners today! 
3. Utilize Okta HealthInsight to help you identify where weak factors are enabled. If you are already a long-time user of Okta’s MFA/AMFA products, you may have many factor enrollment policies out there that are hard to keep track of. Okta HealthInsight (available to all customers) helps you to easily identify which policies allow for weak factor types. You can find Okta HealthInsight in your admin console under Security > HealthInsight.

4. Ensure users have a backup factor available. When your users are able to easily reset their factors and use an alternate factor in case their primary becomes unavailable, your IT Helpdesk will thank you. And, your users will appreciate they can get quickly up and running on their own. You can choose the factors available to different user groups using Okta’s factor enrollment policies in the admin console, under Security > Multi-factor > Factor Enrollment. 

Bonus deployment tip for managing MFA and sign on policies: 

Okta allows you to exclude individual users from factor enrollment and authentication rules. While testing policies, if you accidentally lock a user out of their account, or need to exclude a user from a policy for any other reason, that can easily be done via the admin console on a per-rule basis. 

Factor enrollment rule

Sign-on rule

Have a plan to deploy MFA to remote workers 

Optimizing IT processes to support remote employees is now more critical than ever. Traditionally, employees go through a full in-person onboarding process where they set up their device and account (including MFA) with the help of IT. However, as more employees work from home, it’s important to have a streamlined process for getting users onboarded. Here are a few tips to help with onboarding and managing MFA for remote employees - 

1. Utilize the secondary email attribute in Okta during the pre-hire process. You may have noticed a field called “secondary email address” in Universal Directory. It’s a good idea to create users before their official start date (could be done manually, via directory integrations or HR-as-a-Master integrations) so that anyone on your IT/onboarding team can communicate with the user before day one. 
2. Use productivity tools to help with remote onboarding (including MFA). We all need to get creative when it comes to remotely onboarding employees. While you could just ship your new employees a laptop and send them an email with setup steps, you may also want to consider a more interactive onboarding experience to get them up and running. For example, you could use Zoom (which, according to our Businesses @ Work from Home report, has seen 110% percent growth just from Feb to March of 2020!) to guide users through the process of setting up their device, account, and multi-factor authentication. 
3. Deploy intelligent access policies using Adaptive MFA. Attackers are trying to take advantage of the chaos around the COVID-19 pandemic by launching a flood of phishing and identity attacks. Barracuda researchers have observed a 667% increase in spear-phishing attacks since the end of February, 2020. Even the FBI has issued a warning about an increase in fraud schemes due to the pandemic. 

This means we all need to stay ahead of threats, and creating policies using Okta’s Adaptive MFA is a great way to do that. Here are some more specific tips: 

• Enable Okta ThreatInsight on your org to proactively prevent account lockout and account takeover from suspicious IP addresses
• If there are specific locations/regions you know that no employees should be accessing apps from, use Okta’s country-based dynamic zones to deny access from those locations. 

• Create policies for behavior detection — especially new device logins. Okta can detect when a user logs into their account from a new device. Set your authentication policy to always prompt for MFA on new device logins. 

Have a plan for lost devices

Anything a user has, a user can lose. Remember to have a plan in the case where a device or security key is lost and/or stolen. Ideally, users will be able to get into their account via a backup factor, and disassociate a lost/stolen device or key from their account to minimize the probability of account compromise. Here are a few ideas to address lost/stolen devices and keys:

1. Ensure users have a backup factor type available. When your users are able to easily reset their factors and use an alternate factor type in case their primary becomes unavailable, your IT Helpdesk will thank you. And, your users will appreciate they can get quickly up and running on their own. You can choose the factors available to different user groups using Okta’s factor enrollment policies in the admin console, under Security > Multi-factor > Factor Enrollment. 

2. If you are using WebAuthn, ensure users know that multiple devices can be enrolled. As mentioned previously, Okta allows you to register up to 5 WebAuthn factors to an account. 
3. Disassociate lost/stolen factors from an account. This can be either admin-initiated or user-initiated, but in a scenario where a user can no longer recover a factor, make sure that factor type is disassociated from their account. In case that device gets in the hands of an attacker, you don’t want them to use the device to compromise the user’s account. 

Admin-initiated factor reset via a user’s Universal Directory profile 

User-initiated factor reset via the end user Settings page

Bonus deployment tip for factor reset: 

Keep in mind that these reset actions are also available via our Factors API. Some organizations create lightweight apps that call these APIs so that users do not need to login to the Okta dashboard to reset their factor. 

Learn more

If you made it through this whole post, it means you really care about protecting your users with multi-factor authentication! We covered a lot in this post, but you can still learn more about MFA best practices in our Multi-factor Authentication Deployment Guide.