Add an authentication policy rule

Authentication policies are built on rules. When you create an authentication policy, it starts with a single catch-all rule that allows access to all requests with any two factor types. Configure your authenticator requirements by adding rules and prioritizing them over the catch-all. For example, you can add one rule that prompts all users for a password, and then add a second rule that prompts users in a specific group for email and password authenticators.

Before you begin

Set up authenticators

Create an authentication policy

Add a rule to a policy

  1. In the Admin Console, go to Security > Authentication Policies.

  2. Select the policy where you want to add a rule.
  3. On the Rules tab, click Add Rule.
  4. Enter a Rule Name.
  1. Configure IF conditions. These conditions specify when the rule is applied.
    IFDescription
    IF User's user type isAccept the default or specify user types to include and exclude.
    AND User's group membership includesAccept the default or specify user groups to include and exclude.
    AND User isAccept the default or specify users to include and exclude.
    AND Device state isAccept the default or select Registered to apply this rule only to devices enrolled in Okta Verify. See Device registration.
    AND Device management isIf you selected a Registered device state, indicate whether the rule is applied to only devices managed by a third-party device management solution.
    AND Device platform isAccept the default or select specific platforms.
    AND User's IP isAccept the default or specify network zones that you want to include or exclude. You can sort by zones defined or not defined in Okta, or by dynamic zones.

     

    AND Risk isBy default, this rule applies to authentication attempts of any risk level. Selecting a level limits the rule to only the specified risk level. See Risk scoring.
    AND The following custom expression is trueOptional. Specify additional conditions with Expression Language (EL). See About behavior and sign-on policies and Okta Expression Language.
  1. Configure THEN conditions. These conditions specify how authentication is enforced.

    THEN Description
    THEN Access is Deny the user’s access or allow it after successful authentication. If you deny access, skip to the last step to save your rule.
    AND User must authenticate with

    Choose the authentication requirements that you want to enforce for app access. For a description of factor types, see About MFA authenticators.

    Note: If IdP appears next to these authentication options, your Global Session Policy has specified an Identity Provider that can satisfy the password requirement. Users who authenticate through the specified IdP don’t need to also provide a password.

    1 factor type: To enable one-factor authentication, choose one of these options.

    • Password or Password / IdP requires users to enter their password every time the rule requires re-authentication.
    • Possession factor requires users to provide a possession factor such as Okta Verify or email to access the app.
    • Any 1 factor type or Any 1 factor type / IdP allows users to provide any single factor to access the app.

    For one-factor passwordless authentication options, seeSet up passwordless sign-in experience.

    2 factor types: To require users to provide two distinct factor types, choose one of these options.

    • Password + Another factor or Password / IdP + Another factor
    • Any 2 factor types

    For two-factor passwordless authentication options, see Configure Okta FastPass.

    AND Factor restraints are These options aren't available if you selected Password in User must authenticate with. Use these settings to specify possession factor characteristics.
    • Phishing-resistant: Requires users to provide possession factors that cryptographically verify the sign-in server (the origin). Only FIDO2/WebAuthn satisfies this requirement. Because phishing resistance implies Device bound, that constraint is selected automatically when Phishing-resistant is selected.
    • Hardware protection: Requires that keys used to authenticate are stored in secure hardware (TPM, Secure Enclave) on the device. Currently, only Okta Verify meets this constraint. Because hardware protection implies Device bound, that constraint is selected automatically when Hardware protection is selected.

      Note: By default, Okta Verify attempts to store the Okta Verify keys on the secure hardware of the device (TPM for Windows and Android devices, or secure enclave for macOS and iOS devices). If secure hardware isn't available, software storage is used. When software storage is used, Okta Verify won't satisfy the authentication policy if Hardware protection is selected as an AND Possession factor restraints are THEN condition.

      To identify how Okta Verify keys are stored for a device, view the secureHardwarePresent device attribute in the Admin Console, or use an Okta Expression Language (EL) expression to determine the value of device.profile.secureHardwarePresentview. If this value is true, secure hardware is used.

      See Custom Expressions, and View device state.

    • Exclude phone and email authenticators: Requires that factor's keys are stored securely on the device and aren't transferable to another device without re-enrolling the factor. Email and SMS are the only possession factors that aren't device bound. This constraint is selected automatically if you select either of the other constraints.
    AND Access with Okta FastPass is granted These options allow you to choose whether to require end users to prove that they're physically present when using Okta FastPass to authenticate.
    • If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements)
    This option requires users to prove that they’re physically present.
    • Without the user approving a prompt in Okta Verify or providing biometrics
    If you select this option and the authentication policy requires a possession factor, Okta Verify may perform certificate-based authentication, which allows users to access the resource without proving that they're physically present. This option doesn’t meet NIST AAL2 requirements. Also, if you select this option, you can't use a security question as an additional factor.
    Re-authentication frequency is This setting allows you to specify how often end users are required to re-authenticate.
    • Every sign-in attempt: Users must re-authenticate every time they try to access the app.
    • Never re-authenticate if the session is active: After users authenticate from their device, they aren’t prompted to authenticate again until either the maximum session lifetime is reached or they sign out of Okta.
    • Re-authenticate after: Specify how often end users are required to re-authenticate. Users are prompted to re-authenticate only if they try to access the app and haven’t re-authenticated within the time interval you specified and their session hasn't expired.

    Note: A 10-second grace period applies after a user authenticates with their password. During this grace period, users aren't prompted for their password again if you selected Every sign-in attempt.

    Password re-authentication frequency is These two options appear only when you select Password + Another Factor or Password / IdP + Another factor. They allow you to specify a different re-authentication interval for the password and the other factor. For example, you might want to require users to re-authenticate with a possession factor every time they access the app, but require a password if more than eight hours have passed since they last authenticated. 
    Re-authentication frequency for all other factors is
  2. Click Save.

The next step after you add rules to a policy is to apply that policy to one or more apps. There's no limit to the number of apps that can share a policy.

Security questions in an authentication policy

The Security Question authenticator prompts end users to enter a correct response to a question that they've selected from a list of possible questions.

The Security Question authenticator:

  • Supports authentication (MFA/SSO) and user password recovery scenarios. If disabled for MFA/SSO, it will not be included as part of authentication policy or global session policy evaluation.
  • Can be used as step-up or additional verification when password is used as the primary factor, specifically, if the primary factor in the user's global session policy is A password. Okta recommends against using security questions in any authentication flow.

You can configure Okta to use this authenticator for just account recovery, or for both authentication and account recovery. If you choose only the recovery option, Okta doesn't request authentication during the evaluation of your Global Session Policy.

For example, if you want to enable Okta FastPass for your users, that is, allow users to access the resource without proving that they're physically present, you can't use a security question as an additional factor. If you want end users to use security questions, you must use the A password option in the Global Session Policy.

Next steps

Add apps to an authentication policy

Update an authentication policy