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 factors may be enabled and configured for end user enrollment and verification:

Okta Verify SMS Authentication
Voice Call Authentication Google Authenticator
U2F Security Key (FIDO) Web Authentication (FIDO2)
Windows Hello YubiKey
Duo Symantec VIP
On-Prem MFA Security Question
Email Authentication  

 

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

 

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.

 

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 Okta Verify.

  •  

  • SMS Authentication

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

  •  

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

  •  

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

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

  •  

  • Web Authentication (FIDO2) 

    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, please contact Okta Support.

    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.

    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:

    1. Security keys such as YubiKeys or Google Titan

    2. Built-in authenticators such as Windows Hello or Apple Touch ID

     

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

  •  

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

     

  • Email

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


Enabling and resetting MFA


Additional MFA resources

Top