Multifactor Authentication

Multifactor Authentication (MFA) is an added layer of security used to verify an end user's identity when they sign in to an application.

An Okta admin can configure MFA at the organization or application level. If both levels are enabled, end users are prompted to confirm their credentials with factors both when signing in to Okta and when accessing an application.

 

Info

Only some admins have permissions to add or remove factors and configure factor enrollment settings. For information about admin roles and permissions, see Administrators.

 

MFA Factor Type Comparison


Factor Type Security Deployability Usability

Phishing

Resistance

Real-Time

MITM Resistance

Passwords Weak Strong Strong Weak Weak
Security Questions Weak Strong Moderate Weak Weak
SMS / Voice / Email Moderate Strong Strong Moderate Weak
Software OTP Moderate Strong Moderate Moderate Weak
Physical OTP Moderate Weak Weak Moderate Weak
Push Verification Strong Strong Strong Strong Moderate
YubiKey OTP Strong Strong Strong Moderate Weak
U2F and WebAuthn Strong Moderate Strong Strong Strong
Windows Hello Strong Weak Strong Strong Strong

Note about Phishing Resistance

Push verification such as Okta Verify Push is more effective than OTP against traditional phishing. However, for stronger resistance, use FIDO-based factors such as U2F, Windows Hello, or WebAuthn.

Note about YubiKeys

YubiKeys can be deployed in OTP mode and/or as a U2F or WebAuthn factor based on FIDO1 and FIDO2 standards.

 

Enable Factor Types

  1. Navigate to Security > Multifactor > Factor Types.
  2. For each factor type, select Active or Inactive to change its status. This setting determines whether the factor can be enabled for end users, depending on Factor Enrollment policies.
  3. For each factor type, configure the available options displayed based on your security requirements.

 

MFA Factor Configuration


  • Okta Verify

    To sign in, end users must start the Okta Verify app on their mobile device to generate a six-digit code they use to sign into your org. The numbers are generated using the industry standard Time-Based One-Time Password Algorithm. For more information, including configuration and usage, see Okta Verify.

  •  

  • SMS Authentication

    End users sign in to their org and authenticate by entering a security token that is sent to their mobile device.

    Info

    Note

    The sender ID or phone number that appears for end users may change from one sign-in to another. This allows Okta to maintain service reliability and delivery.

    If your org uses a single phone number to authenticate multiple end users:

    • All users will enroll in this factor with the same phone number.
    • Due to a high level of user activity, the number may be blacklisted. If this occurs, contact Okta Support immediately to confirm that the number is trusted by your org.
  •  

  • Voice Call Authentication

    To sign in, you must enter a security token that is generated, then sent to you via phone call from a mobile device or land line phone.

    Info

    Note

    The sender ID or phone number that appears for end users may change from one sign-in to another. This allows Okta to maintain service reliability and delivery.

    If your org uses a single phone number to authenticate multiple end users:

    • All users will enroll in this factor with the same phone number.
    • Due to a high level of user activity, the number may be blacklisted. If this occurs, contact Okta Support immediately to confirm that the number is trusted by your org.
  •  

  • Google Authenticator

    To sign in, end users must start the Google Authenticator app on their mobile device to generate a six-digit code they use to sign into your org. The numbers are generated using the industry standard Time-Based One-Time Password Algorithm. The allowable clock skew is two minutes. After five unsuccessful attempts, regardless of the time between the attempts, the user account is locked and must be reset by an administrator.

  •  

  • U2F Security Key (FIDO 1.0)

    End users use a U2F compliant security key to sign into Okta. Examples of supported U2F security keys include a YubiKey or Titan Security Key.

    U2F is supported only for Chrome and Firefox browsers.

    If your policy allows for optional factors, end users can change to a different factor through the Okta Settings page, under Extra Verification.

    Info

    Note

    The U2F security key is not compatible with RADIUS-enabled implementations.

  •  

  • Web Authentication (FIDO2) 

    FIDO2 Web Authentication (WebAuthn) is a standard web API that is incorporated into web browsers and related web platform infrastructure. This standard provides users with new methods to securely authenticate on the web across various sites and devices using factors that are enabled and configured for WebAuthn.

    Once this factor is configured, additional verification will be required when users sign in to Okta. End users can enroll in up to ten instances of the same WebAuthn factor, which can be set up either from the sign-in widget or from settings on the end user dashboard.

    If the user selects Security key or built-in authenticator at sign in, they will be prompted to register an authenticator via Web Authentication in order to sign in to Okta successfully. Users can follow the on-screen prompts for browser or OS instructions in order to gain access. For more information about the FIDO2 WebAuthn standard, see FIDO2 Project.

    Web Authentication supports two methods of authentication:

    • Security keys such as YubiKeys or Google Titan
    • Built-in authenticators such as Windows Hello or Apple Touch ID

     

    WebAuthn and Web Browser Support

    WebAuthn is supported in Chrome, Firefox, and Edge browsers to different degrees. Support for credential creation and assertion using a U2F Token (such as Yubico-provided tokens) is supported by all three browsers. For a full list of desktop and mobile browser compatibility refer to Browser Compatibility.

    Info

    Note

    Embedded web browsers may not support WebAuthn.

    WebAuthn and Windows 10 Support

    Official FIDO2 certification for Windows Hello is supported as of Windows 10 build 1903 for web browser support on Microsoft Edge, Google Chrome, and Mozilla Firefox. Previous versions of Windows 10 use a deprecated implementation of WebAuthn, which is not supported by Okta.

     

    WebAuthn Security Key Enrollment

    An admin may enroll a WebAuthn security key on behalf of an end user. To enroll a security key:

    1. Navigate to Directories > People.
    2. Click on a user's name to view their profile.
    3. Click Profile to view the user attributes page.
    4. Under More Actions, click Enroll WebAuthn Security Key. The Enroll Web Authentication Security Key prompt appears.
    5. Click Enroll to enroll the key. Your browser or device will prompt you to enroll the key.
    6. Follow the on-screen instructions. A confirmation message is displayed once enrollment is successful.

  •  

  • Windows Hello

    Windows Hello is no longer available as an Early Access feature. It will soon be deprecated to support the new FIDO2 WebAuthn standard, which is compatible with Windows Hello authenticators.

    To learn more about factors supported by WebAuthn, please refer to Web Authentication.

  •  

  • YubiKey

    Using their USB connector, end users press on the YubiKey hard token to emit a new, one-time password to securely log into their accounts. Security is assured, as all YubiKey validation occurs within the Okta Cloud.

 

  • Duo Security

    When signing in, end users are prompted for additional verification. End users can then select the authentication type that is supported by their device to verify their identity. For details about this option, see Configuring Duo Security.

     

  • Symantec VIP

    Available for free in the United States and Canada in both enterprise and SSO editions, this factor enables you to use the VIP Manager tool to obtain a certificate that you use to sign in.

  •  

  • On-Prem MFA

    To sign in, end users must use an RSA hardware dongle device or soft token to generate an authentication code to sign into your org. The numbers are generated using a built-in clock and the card's factory-encoded random key. The Okta On-Prem MFA agent (formerly named the RSA SecurID agent) acts as a RADIUS client and will communicate with your RADIUS enabled on-prem MFA server, including RSA Authentication manager for RSA SecurIDs. For details about this option, see Configuring the On-Prem MFA Agent (including RSA SecurID).

     

  • Security Question

    To sign in, users must enter the correct response to a security question that they select from a list of possible questions.

 

  • Email

    End users receive a one-time password (OTP) code in an email message to enter during Okta sign in.

  •  

  • IdP Authentication

    This is an Early Access feature. To enable it, please contact Okta Support.

    Identity Provider (IdP) authentication allows admins to create a custom SAML MFA factor based on a configured Identity Provider. For more information, see Custom IdP Factor Authentication.

 

  • Custom TOTP Authentication

    Custom TOTP Factor allows admins to enroll users in a custom TOTP factor by importing a seed into Okta and authenticating users with the imported hardware token. For more information, see Custom TOTP Factor.


Multifactor Policies

Use the Factor Enrollment tab to create and enforce policies for your chosen MFA factors and the groups that are subject to them. Sign-on policies determine the types of authentication challenges these users receive. An MFA policy can be based on a variety of factors, such as location, group definitions, and authentication type. It can also specify actions to take, such as allowing access or prompting for a challenge.

  • Add a new policy by navigating to Factor Enrollment and clicking Add Multifactor Policy.
  • Change the order of policies, except the Default Policy, by dragging the bar on the blue policy name, thereby rearranging the list.
  • The Default Policy: The default policy applies when no other policy has been set. It also immediately reflects the factors you chose under the Factor Type tab.

Creating a Policy


Policies can be applied to specific groups within your org and automatically enforced for only those users.

Info

Note

If your org does not require group-based factors, it is not necessary to create additional policies. Simply retain the Default Policy.

Click Add Multifactor Policy to open the Add Policy screen.

  • Policy name: Enter a descriptive policy name.
  • Policy description: Describe the elements of the policy.
  • Assign to groups: Enter a predefined group. When text is entered, it will auto-complete the group name.
  • Effective factors: The factors you set up under the Factor Type tab appear here. Use the drop-down menu to define whether the option is required, optional, or disabled for that group.

Click Create Policy to complete the process.

The following actions affect only a selected policy. Select the policy name in the list to select and display options.

  • Active button: Use to activate or deactivate the selected policy. If you deactivate a policy, it will not be applied to any user, but you can reactivate it later.
  • Edit button: Use to change elements of the policy.
  • Delete button: Use to delete the select policy. The default policy cannot be deleted. A deleted policy cannot be recovered.

Adding a Rule


Rules allow you to add conditions to your policy choices. To add a new rule, click the Add Rule button and complete the following fields as needed.

  • Rule Name: Add a descriptive name for the rule you want to create.
  • Exclude Users: If needed, you can exclude individual users of a group from the rule.
  • Enroll Multifactor: Use the drop-down menu to enforce the following two options:
    • The user must enroll in the multifactor option during their initial sign-in to Okta.
    • The user can enroll when first challenged for an MFA option.
  • When a User is located... Use the drop-down menu to enforce where the user will be challenged for authentication:
    • Anywhere: The user is challenged within the network or outside of it.
    • On Network: The user is only challenged when they are off of the network.
  • Manage configuration for Network: Click the Manage Configurations for Network link to access your gateway settings that enable your choice of access. For details on using this option, see Public Gateway IPs.

Once created, you can expand a rule to view the details by clicking on the rule name listed beneath the Add Rule button. Once expanded, this view shows all the details of the rule such as excluded users and when an authentication factor will be prompted. You can also prioritize the rule by dragging the rule name above or below the other rules in the list.

The following actions only affect the selected rule.

  • Active button: Use to activate or deactivate the selected rule. If you deactivate a rule, it will not be applied to any user, but you can reactivate it later.
  • Expand rule: Use to view details of the rule. You can also simply click on the rule name.
  • Edit button: Use to change established elements of the rule.
  • Delete button: Use to delete the select rule. A deleted rule cannot be recovered.

 

Enable and Reset MFA



Additional MFA resources