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 adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. can configure MFA at the organization level or application level. If both levels are enabled, end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. are prompted to confirm their credentials with factors both when signing in to Okta and when accessing an application.

Okta admin UI for factor type configuration and enrollment:

Okta admin UI for Factor Type Configuration and Enrollment

Factor Types

The following list of factors are available for admins to enable and configure for their end usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control.:

 

The following chart compares various factor types based on security, deployability, usability, phishing resistance, and real-time MITM resistance:

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 Strong Strong Strong Moderate Weak
U2F Strong Moderate Strong Strong Strong
Windows Hello Strong Weak Strong Strong Strong

 

Enabling Factor Types

  1. Navigate to Security > Multifactor > Factor Types.
  2. For each factor type, select Active or Inactive to change its status. This setting affects if the factor is enabled for end users.
  3. For each factor type, configure the available options displayed based on your security requirements.

 

Factor Type Overview and Configuration

  • Okta Verify

    To sign in, end-users must start the Okta Verify appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. on their mobile device to generate a six-digit code they use to sign into your orgThe Okta container that represents a real-world organization.. The numbers are generated using the industry standard Time-Based One-Time Password Algorithm. For more information, including configuration and usage, see Using Okta Verify.

    •  

  • SMS Authentication

    To sign in, you must enter a security token that is sent to your mobile device.

    ClosedUsing SMS Authentication

    The first time users sign into their orgs after you configure this factor, they see the Extra verification is required for your account page and must perform the following steps:

    1. Click the Setup button beside Text Message Code.
    2. Enter the mobile phone number where you want your security tokens sent.
    3. Enter the security token that was sent to your phone.

    To reset and configure your settings if you lose your phone or get a new phone number, select the Account tab on your homepage and then click the Setup button in the Extra Verification section.

    If you are configuring a user who already has a mobile telephone number verified in Okta, the following message appears.

     

    Note about SMS Messaging

    By design, enabling SMS factor authentication requires that end users receive an SMS text message on their mobile devices. When this factor is enabled by an admin, end users will receive an SMS text message with an authentication code when they sign in to Okta, even if they have sent an SMS opt out request on their device. If SMS messaging is of concern to your users, you may enable another factor of your choice as an alternative.

    •  

  • 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.

    ClosedUsing Voice Call Authentication

    The first time users sign into their orgs after you configure this factor, they see the Extra verification is required for your account page and must perform the following steps:

    1. Click the Setup button beside Voice Call.

    2. Enter the number for the mobile or landline phone on which you want to receive the call. An extension number can be entered for landline business phones, as shown below.

    3. Click the Call button.
    4. The number is verified with a call and a Call is in progress... message appears. Enter the provided code into the Enter code box.
    5. Click the Verify button, then Done, if needed.

    Sign In Experience

    When signing in for an Okta session, your end user is presented with the Enter your voice call verification code page.

    To authenticate, end users do the following:

    Click the Call button.

    Receive the call message from their mobile device or land line phone. This voice call provides the required code.

    Enter the code into the Enter code box and click the Verify button. They are immediately authenticated into Okta.

    Resetting Voice Call

    End users can reset and configure their settings if their phone is lost or they get a new phone number by doing the following:

    1. Select Settings from the drop-down menu under your name on your Okta Home page.
    2. Click the Edit Profile button.
    3. Scroll down to the Extra Verification section.

    4. Click the Reset button beside Voice Call, as shown below.

    5. On the following page, add the new phone number, then click the Update button to change and reconfigure it.

    •  

  • 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.

    ClosedUsing Google Authenticator

    The first time users sign into their orgs after you configure this factor, they see the Extra verification is required for your account page and must perform the following steps:

    1. Click the Setup button.
    2. Select your mobile device, follow the instructions to download and install Google Authenticator, and then click Next.

    Configure Google Authenticator to link it to your Okta account. You can scan a QR code or manually enter the code.

    If you scan a QR code, click Next. The pass code generator screen appears and generates pass codes to use when prompted for extra verification. You have 30 seconds to enter the pass code before it generates a new one.

    To configure an account manually, perform the following steps:

    1. On your phone, start Google Authenticator and tap the + icon.
    2. In the username field, enter your Okta username (for example, ted@mycompany.com).
    3. On your computer, click the Can’t scan link so that you can access the secret key and enter it in the Key field.
    4. Click Done.

    The pass code generator screen appears and generates pass codes to use when prompted for extra verification. You have 30 seconds to enter the pass code before it generates a new one.

    Using the Google Authenticator App

    After you install and configure Google Authenticator, click on the app and use the six-digit number to authenticate when prompted.

    Revoking or Reconfiguring the Google Authenticator App

    You can remove Google Authenticator as a factor by unchecking it in the factors list. To reconfigure it, remove it, and then add it back in.

    •  

  • Windows Hello (Web Authentication)

    End-users use Windows Hello to sign into Okta. Users must be running the Microsoft Edge browser to use this option.

    Note: Windows Hello is not compatible with RADIUS-enabled implementations.

    This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it use the Early Access Feature Manager as described in Manage Early Access Features .

    ClosedUsing Windows Hello

    The first time users sign into their org after you configure this factor, they see the Set up multifactor authentication page and must perform the following steps:

    1. Click the Setup button.
    2. The Making sure it's you appears and authenticates you.
    3. Once authenticated, click the OK button.

    The next time your users sign in, they are shown a Windows Hello challenge.

    •  

  • 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. Firefox users must download an extension.

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

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

    ClosedUsing a U2F Security Key

    The first time users sign into their org after you configure this factor, they see the Set up multifactor authentication page and must perform the following steps:

    1. Click the Setup button.
    2. Go through the prompts to register the security key and set it up.
    3. Once completed, click the Done button.

    The next time your users sign in, they are shown a panel with instructions for signing in via their security key.

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

    •  

  • Web Authentication for U2F 

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

    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.

    With this feature enabled, U2F keys are authenticated using the Web Authn standard.

    Note: This Early Access feature is mutually exclusive to native Windows Hello and does not currently support platform authenticators.

     

  • 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.

    ClosedAbout YubiKey

    Produced by Yubico, a YubiKey is a multifactor authentication device that delivers a unique password every time it's activated by an end-user. Using their USB connector, end-users simply press on the YubiKey hard token to emit a new, one-time password (OTP) to securely log into their accounts. Security is assured, as all YubiKey validation occurs within the Okta Cloud. As such, Okta guarantees Okta-level quality of service and uptime for YubiKey authentication.

    Note: The steps in this section pertain to YubiKey in OTP mode. YubiKey also supports U2F and depending on the key series, WebAuthn. For Web Authn, refer to the Web Authentication section in this document.

    To specify YubiKey for authentication, the only task is to upload the YubiKey seed file, also known as the Configuration Secrets file. To create this file, follow the instructions below. Once uploaded, the screen verifies the number of successfully uploaded YubiKeys, and lists any errors that occurred in the process.

    ClosedCreate a YubiKey Configuration File

    Before you can enable the YubiKey integration as a multifactor authentication option, you need to obtain and upload a Configuration Secrets file generated through the Yubikey Personalization Tool. Find details on generating this file (which might also be called a Yubikey or Okta secrets file), in the Programming YubiKeys for Okta document. The Configuration Secrets file is a .csv that allows you to provide authorized YubiKeys to your org's end users. Yubico sends the requested number of "clean" hard tokens which, once setup is complete, you can distribute to your end-users.

    Be sure to read and follow the instructions found in Programming YubiKeys for Okta document very carefully. Once completed, follow the steps under Uploading into the Okta Platform found in Using YubiKey Authentication in Okta.

    With purchase of the YubiKeys, Yubico offers an additional premium service to create a secrets file on your behalf. Contact Yubico for details on this option.

    Troubleshooting

    If you encounter problems with generating your Configuration Secrets file or in configuring your Yubikeys, verify that you've satisfied the following questions and steps below.

    Did you select Configuration Slot 1?

    Each YubiKey is configured for the YubiCloud in Configuration Slot 1 by default. If you plan to use your Yubikeys for services other than Okta, you can use Slot 2 for Okta configuration. However, if you’re experiencing errors, it’s a best practice to use Configuration Slot 1 exclusively for Okta.

    Did you click the three Generate buttons?

    When going through the steps for configuring your Yubikeys, verify that you have clicked all three of the Generate buttons.

    Did you check your Generated OTP?

    An important step in checking your work is noting that the Public Identity value exists in your generated OTP. If it is not present, your Yubikey is not correctly configured.

    To check the file, do the following:

    1. Open the .csv file generated by the YubiKey Personalization Tool.
    2. Note the Public Identity value, listed as the second value item in the file.
    3. Open a text editor, then tap on the YubiKey that was configured for use with Okta. Allow YubiKey to generate the OTP within the text editor.
    4. Search for the aforementioned Public Identity value in the generated OTP. If it is not present in the line of text, the YubiKey has not been successfully configured.

    ClosedUsing a YubiKey

    Managing Tokens

    Now, with a successfully uploaded Configuration Secrets file, you can view all the unassigned YubiKeys available within your org. Your end-users should begin to enroll their individual tokens on their devices, and the assigned tokens should begin to appear in your reports.

    Viewing Your YubiKeys

    Click the View Report button to view a list containing the serial values of all your assigned and unassigned YubiKeys. Alternatively, you can find the same information from the Reports page, under the MFA Usage link.

    A report can be run at any time to view:

    • Active tokens (YubiKeys which are associated with users.)
    • Blocked tokens (YubiKeys which were once active, but are now either reset by the end user or the Okta admin.)
    • Unassigned tokens (An unassigned YubiKey has secret values uploaded and is ready to be self enrolled by an end-user.)
    • Names of assigned end-users

    Removing Lost, Stolen, or Invalid YubiKeys

    Another benefit of the YubiKey hard token is the ability to easily unauthorize users if it is ever lost or stolen—it is non-transferable and easily replaced. If an end-user reports their YubiKey as lost or stolen, you can remove these individual tokens using its unique serial number. This method is also the way to remove unassigned YubiKeys. Ensure the YubiKey has already been reset by following the Resetting MFA instructions. A YubiKey serial can not be removed if it is currently active for a user.

    From the Yubikey tab,

    1. Enter the serial number into the Revoke Yubikey Seed field.
    2. Click the Find Yubikey button.
    3. A Delete Yubikey modal appears to verify that you wish to permanently delete the YubiKey.
    4. A confirmation page appears. Click the Done button.

    Best Practice: If a lost YubiKey is found, it's a best practice to simply discard the old token. An admin can also reprogram the YubiKey by following the steps within the Programming Yubikeys for Okta file, which can be found in Configuring Yubikey Tokens. This generates a new Configuration Secrets file for upload, and allows the token to be re-enrolled by any end user within the Okta framework.

    The End-User Experience

    What happens for your end user? Enrollment is simple. When a user signs into Okta for the first time or after a reset, they will be prompted to choose an MFA option for their account. At this point, they can choose the Yubikey option.

    Once they click the Setup button, step-by-step instructions follow for successful registration.

    Enrollment Failure

    If an end user is unable to enroll their YubiKey successfully, ensure that the token was successfully uploaded into the Okta platform. Navigate to the Yubikey Report found on the Reports page. Search (by serial number) for the end user who is attempting to enroll.

    • If the YubiKey is present in the YubiKey report, and the status is unassigned, the end user has potentially reprogrammed their Yubikey and overwritten the secrets associated with the Yubikey. This requires the admin to follow the instructions found in the Programming Yubikeys for Okta file, which can be found in Configuring Yubikey Tokens, and upload again into the Okta platform.
    • If the Yubikey is not present in YubiKey report, then the Yubikey secrets value has not been properly uploaded and must be uploaded again into the Okta platform.

     

    Best Practice: If a Yubikey is decoupled from it's user, consider revoking the token from your system and reissuing the end user another unassigned Yubikey for enrollment.

    ClosedSupported Protocols and Communication Channels

    For successful YubiKey authentication, the following token modes are supported:

    • TOTP
    • U2F (Requires Google Chrome. Refer to the previous section for more information on U2F)

    In addition, the following communication protocols are supported:

    • USB
    • NFC
    • Bluetooth

    •  

  • 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 SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. editions, this factor enables you to use the VIP Manager tool to obtain a certificate that you use to sign in.

    ClosedEnabling Symantec VIP

    Symantec Validation and ID Protection Service (VIP) is a cloud-based authentication service that enables secure access to networks and applications. To enable Symantec VIP for multifactor authentication, you must upload a certificate. You should obtain your certificate from the Symantec VIP Manager before you can configure this option.

    On the Symantec VIP tab, use Browse to upload your VIP certificate. It must be in .p12 (PKCS#12) file format, and enter the VIP Manager password.

    ClosedUsing Symantic VIP

    Certificate

    1. Go to Symantec VIP Manager to obtain a certificate. Your certificate must be in .p12(PKCS#12) file format.
    2. Upload your Symantec VIP certificate and enter your VIP Manager password.

    Using the VIP Access App

    Your users must install the VIP access app on their mobile phones (currently VIP Access is available for all iPhone models and for most Android, Windows, and BlackBerry phones). The first time users sign into their org after you configure this factor, they see the Extra verification is required for your account page and must perform the following steps:

    1. When you sign into Okta, you are prompted to set up VIP. Click Setup.
    2. Enter your credential ID and security codes, and then click Register.

    After the initial setup, your users must enter the security code generated by the VIP access app (based on the frequency you set for Ask for additional factor.

    •  

  • 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 agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. (formerly named the RSA SecurID agent) acts as a RADIUS clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. 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.

    ClosedUsing a Security Question

    The first time users sign into their orgs after you configure this factor, they see the Extra verification is required for your account page and must perform the following steps:

    1. Select Setup.
    2. Choose a security question, enter an answer, and then click Save.

    The next time your users sign in, they are prompted to answer their security question.

    Security Questions Guidelines

    All the following guidelines are required for security questions:

    • The answer to a security question must be at least four characters long; however, a longer length can be specified for recovery flows in a Group Password Policy.
    • The answer to a security question cannot be the user's password or user name.
    • The answer to the security question cannot be included in the question.

     

  • Email

    End-users receive a code in an email message to enter during Okta sign in.

    ClosedUsing Email

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

    To select email as a factor, click the checkbox.

    Important notes:

    • Okta Mobile Android currently does not support email as an MFA factor.
    • Using email as a factor is not a best practice. When you add it as a factor, you must accept the risk of using it. The following message appears:

      We do not recommend that you use email as a second factor experience for Okta. This experience is a very insecure method of additional verification as:

      • Email can be compromised by third parties
      • Email is not always transmitted over secure protocols
      • Email can also be used, depending on the recovery flow, for primary credential recovery

      Although we do offer email as a factor experience for convenience and to help our customers migrate off of legacy identity platforms, we do not consider it to be a secure, modern method for secondary authentication. To continue enabling this feature, please click "I accept the risk" below.”

    After enabling email as a factor here, you must set the usage details and restrictions in a policy. Policies are described in the section below.

    ClosedSpecifications available in policies for email factors

    If you have authorized email as an authentication factor, it appears in the factor list for a policy. By default it is disabled. There are two options for the email factor, as follows:

    • Disabled – End users specified in this rule cannot use email for multifactor authentication.
    • Auto Enroll – End users specified by this rule are automatically enrolled in email factors based on their primary email addresses in their user profiles.

    Note: You can limit the use of email as a factor during password recovery.

    You can specify whether to allow email as an authentication factor in account recovery. Additionally, you can specify how long the code sent in an email is valid.


Enabling and resetting MFA

ClosedEnable MFA for admins

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

Super Admins can enable mandatory multi-factor authentication for all administrators signing into Okta Administration.

  • After this feature is enabled, the MFA policy for the Admin Dashboard will be enabled by default. The next time an admin logs in, they will be prompted to set up MFA for admins.

  • Administrators that have NOT enrolled into an existing MFA factor will be prompted to enroll for the first time.
  • At least ONE factor must be turned on for your organization to enable this setting. If the org does not have any MFA factors enabled, Okta Verify with one time passwords (OTP) will be enabled as the default factor. If factors have already been configured, then no changes will be made.
  • MFA for admins can only be set to enabled or disabled. It cannot be configured like other MFA policies.

  • It is recommended to never disable multifactor authentication for administrators. This decreases your overall security posture and increases risk for administrator accounts to be compromised.

To enable the setting, follow these steps:

  1. Navigate to Security > General.
  2. Scroll to Multifactor for Administrators.
  3. Click Edit.
  4. Select Enable Multifactor for Administrators.
  5. Click Save.
ClosedReset MFA for end users

In the event that you need to reset multifactor authentication for your end users, you can choose to reset configured factors for one or multiple users.

 

Reset all factors for one or multiple users

  • This action resets all configured factors for any user you select. End users will be required to set up their factors again. Note that this action applies to all factors configured for an end user. You cannot select specific factors to reset.
    1. Navigate to Directory > People.
    2. Click Reset Multifactor.
    3. Select the users that will be affected by the factor reset.
    4. Click Reset Multifactor Authentication. A confirmation prompt appears. Click Reset to proceed. This action cannot be undone.

    Reset one or multiple factors for a single user

  • This action resets any configured factor you select for an individual user. The user will be required to set up their factors again.
    1. Navigate to Directory > People.
    2. Click on the name of the user that will be affected by the factor reset.
    3. Click More Actions > Reset Multifactor.
    4. Select the factors to reset and click Reset Multifactor Authentication. A confirmation prompt appears. Click Reset to proceed. This action cannot be undone.


    Additional MFA resources

    ClosedSoftlock

    Our Softlock feature, available for password policies, are also available for delegated authentication. Active Directory (AD) and LDAP-mastered users will have a five attempts for MFA, after which the Okta account will be locked. The number of unsuccessful attempts before locking cannot be changed. It is fixed at five. AD-Mastered users can take advantage of the Okta Self Service feature, however, LDAP-mastered users require admin action to unlock their Okta account.

    ClosedThird-Party MFA Providers with Okta

    Okta's native Multifactor Authentication (MFA) method, Okta Verify, balances ease of use with security. However, sometimes circumstances dictate your choices. Feedback from hundreds of Okta customers currently using Okta for MFA, exposed a number of scenarios where a third-party MFA provider was needed. Some customers had a pre-existing investment in a legacy MFA provider and were wary of the cost and effort in changing their user experience. Others required the high-level assurance that hardware tokens can deliver for a subset of privileged users. Still others were in a state of transition—eager to adopt Okta Verify, but reluctant to migrate from their old provider too abruptly.

    While authentication methods do matter, they are only a part of the story with Okta. Our flexible policy framework, catalog of thousands of app integrations, and contextual access control allow our customers to broadly deploy MFA across their organizations. You are not restricted to Okta Verify—various third-party authentication methods are compatible and seamless with the Okta identity platform. Okta can even support multiple factors simultaneously, allowing organizations to migrate between factors or support heterogeneous user environments.

    This is why Okta expertly supports several third-party MFA providers. Click to view a table listing supported providers and details about their integration.

    Vendor Integration Type Note Supported Authentication Method(s) Documentation
    RSA On-Prem MFA agent This type of integration relies on the Okta agent to facilitate communication between the Okta service and an On-Prem RADIUS server. OATH-OTP Configuring the On-Prem MFA Agent (including RSA SecurID)
    Entrust
    Symantec Native These integrations are built upon the providers’ APIs or WebSDKs. They vary in feature support because not all features are similarly accessible. OTP Configuring Multifactor Authentication
    Duo Security Native   OTP, Push, Voice Configuring Duo Security
    Google Authenticator Native   OTP Configuring the Okta RADIUS Agent
    Yubikey Native   OTP, Push OTP Using YubiKey Authentication in Okta
    ClosedMFA with Windows Remote Desktop (RDP)

    The Okta Windows Credential Provider prompts users for MFA when signing in to supported Windows servers with an RDP client. To use it, you must configure an agent on the Windows server. For instructions, see Okta Windows Credential Provider.

    Note: After clicking the Privacy Policy link, users cannot return to the factor screen. Users must close the remote desktop session and reopen it to continue.

     
    Top

    © Copyright 2019 Okta, Inc