Multifactor Authentication

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 usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. are prompted to confirm their credentials with factors both when signing in to Okta and when accessing an application.

 

 

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

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

  

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

  

  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.
  Using 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 illustrated in the sample image under Sign-In Experience.

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

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

 

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

  Using 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 (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.

  

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

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

  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.

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

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

  View a list of assigned and unassigned 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 a lost, stolen, or invalid YubiKey

  • A user can be unauthorized from a YubiKey hard token if the token is lost or stolen.
  • A token is non-transferable and may be replaced. If an end user reports a lost or stolen YubiKey, unassign the token based on its unique serial number by using the same method to remove an unassigned YubiKey.
  • For auditing purposes, a YubiKey cannot be deleted once assigned to a user. Even if it has been revoked or reassigned, it will remain in the report when generated.

  • A YubiKey must be deleted and re-uploaded to be reassigned to a user.

  • A YubiKey that has not been assigned to a user may be deleted.
  • A YubiKey serial cannot 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 its user, consider revoking the token from your system and reissuing the end user another unassigned YubiKey for enrollment.

  Supported Protocols and Communication Channels

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

  • TOTP
  • U2F (Requires Chrome or Firefox web browsers)
  • FIDO2

  

  Note

  Some YubiKey models may support protocols such as NFC. Okta Mobile and web browsers running on iOS do not currently support NFC. Please refer to the YubiKey device specifications to confirm the level of support.

 

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

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

  Using Symantec 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

  Users may install the VIP access app on their mobile devices. 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.

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

  Using Email

  To use email as an MFA factor, select Email Authentication in the Factor Types tab and then select Activate.

  

  After activating email as a factor, configure its usage and authentication details in one or more policies under the Factor Enrollment tab. Factor policy configuration is described generally under Multifactor Policies. When email is set to Required, rather than Optional, as an Effective factor, end users specified in the policy are automatically enrolled in MFA using the primary email addresses in their user profiles.

  

  Notes

  • Okta Mobile Android currently does not support email as an MFA factor.

  • The one-time verification code that is sent to an email for an MFA challenge is valid for 5 minutes. This time frame cannot be adjusted.

  • Using email as a factor is not always a best practice for several reasons, including the following:
    • 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.
    • Email can land in spam folders or be delayed by networking issues.

   

  

  Tip

  You can also use email as a means of account recovery and set the expiration time for the security token. See Security Policies

 

• IdPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta. Authentication

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

  Identity Provider (IdP) authentication allows admins to create a custom SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. MFA factor based on a configured Identity Provider. For more information, see Custom IdP Factor Authentication.

 

• Custom TOTP Authentication

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

  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 groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with 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.

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

---

Top