Configure a password policy

Password policies enable admins to define password policies and associated rules that enforce password settings at the group and authentication-provider level. Okta provides a default policy to enforce the use of strong passwords to better protect your organization's assets. Admins can also create additional policies that are less or more restrictive and apply them to users based on group membership.

To create a new Group Password Policy, configure the following information:

Add policy information

Configure information about the policy.

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

  2. Click Add New Password Policy and configure the following information:
    • Policy Name: Enter a unique name.
    • Policy description: Enter a description.
    • Add group: Enter the name of the group(s) to which this policy will apply.
    • Authentication Providers: An authentication provider is the primary source of user-specific data. Use the Applies to: drop-down menu to specify the appropriate source.
      • Default policy: the authentication provider cannot be changed.
      • Legacy policy: the authentication provider should be set to Okta.
      • Active Directory policy: the authentication provider should be set to Active Directory. For more information about using AD as an authentication provider, see Manage your Active Directory integration.
  3. Next, continue to Configure Password Settings.

Configure Password Settings

Password settings enable you to specify the strength of end-user password creation.

  1. In Minimum length, specify a minimum password length of 4 to 30 characters (the default minimum is eight characters). For AD and LDAP mastered users, these requirements are set and enforced by AD and LDAP. Ensure that the settings here duplicate the minimum settings of AD and LDAP.

    The maximum number of characters that Okta will store is 72.

  2. In the Complexity requirements: section, select any or all of the options in the list to define the level of complexity that is required for your users' passwords section (see Configure a password policy).
  3. Configure the settings in the Common password check section:
    • Restrict use of common passwords: Check this option to ensure that passwords are not too weak.
  4. Configure the settings in the Password age section:
    • Enforce password history for last . . .: Specify the number of distinct passwords that a user must create before they can reuse a previous password. This prevents users from reusing a previous password for a specified period of time. You can configure this setting from 1–30 passwords.
    • Minimum password age is. . .: Specify the minimum time interval required between password changes. This setting prevents users from bypassing the enforce password history requirement. You can configure this setting for up to 9,999 minutes.
    • Password expires after . . .: Specify how long a password remains valid before it must be changed. When a user's password expires, they must change it in order to sign in to Okta. You can configure this setting for up to 999 days. Note that users will not receive an expiration warning if this field is set to fewer than six days.

      For AD and LDAP mastered users: The Password expires after setting does not appear. The expiry date can vary and is imported from AD or LDAP

    • Prompt user. . .: Specify the number of days prior to password expiration that users are prompted to change their password. Users can change their password when prompted, or wait until the expiration date. You can configure this setting for up to 999 days. Users do not receive an expiration warning if this field is set to less than six days.

  5. Configure the Lockout Settings:
    • Lock out user after . . .: Specify the number of times users can attempt to log in to their accounts with an invalid password before their accounts are locked. The maximum is 100 invalid log in attempts.
    • Preventing Active Directory account lockouts: Okta provides a feature to help prevent AD-mastered users from getting locked out of their Windows account and hardware device due to too many failed sign-in attempts to Okta. This feature also helps prevent a malicious third party from using Okta to lock up an end user via the web.
    • To prevent AD lock outs, make sure that the number entered for Lock out user after <#> unsuccessful attempts is lower than the failed sign-in attempt limit configured in AD. For example, if the maximum number of failed Windows sign-in is set to 10 in AD, you might set your maximum Okta failed sign-in limit to. If an end-user exceeds the sign-in limit set in Okta, additional failed attempts are not sent to AD, thereby preventing users from locking themselves out of their Windows account. Locked out Okta users can either unlock themselves or seek help from an Okta Admin.

    • Account is automatically unlocked after . . .: Specify how long a locked account remains locked before it is unlocked automatically. Auto unlock requires no additional user action, and the minimum setting is one minute. You can configure this setting for up to 9,999 minutes. It is not enabled by default.
    • Show lock out failures: Select to show a message on the sign-in page to alert end-users when they have been locked out of their account due to too many failed login attempts.

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

    • Send a lockout email – Select to send locked-out users an email if their account is locked due to too many failed sign-in attempts. You can customize the Account Locked email in Settings > Email & SMS. You can also insert a link in the email to let users unlock their account. To enable the link, open the appropriate Configure Password Policy Rules and select The user can perform self-service account unlock.

  6. Next, continue to Configure Account Recovery.

Configure Account Recovery

Account Recovery enforces the parameters by which end users can unlock their own accounts.

Password reset requests made by LDAP sourced users can fail when a password policy on an LDAP server doesn’t allow users to change their password. If a password reset fails, the Okta LDAP agent log provides the LDAP error code. To create password policies that allow users to change their password, consult the LDAP server manual provided by the vendor.

When an admin creates a temporary password for LDAP sourced users, users must change their password when they next sign in if the LDAP server password policy requires or allows it. To create password policies that support temporary passwords, consult the LDAP server manual provided by the vendor.

Configure the following settings:

  1. Self-service operations (Allow SMS or Voice Call): Select if you want to allow end users who have forgotten their password to be able to reset passwords using SMS or voice call. If end users forget their passwords, Okta sends them a text message with a password reset code or a voice call with an audible password reset code. The first time end users log on after this feature is enabled, they have the option to either enter a phone number, or click Remind me later to receive a reminder when signing in on or after the 1st of the upcoming month.
    • If the self-service unlock feature is enabled, users can SMS to unlock your account.
    • The password security question is required to perform a password reset with SMS. With an Early Access feature, you can omit a security question from the password recovery flow, if desired. This applies to Okta and AD-mastered users only. To enable it, contact Okta Support.

      • Reset/Unlock recovery emails are valid for: Specify how long the recovery link remains valid before it expires. The maximum period is 180 days.
      • Security answer complexity: Specify the minimum number of characters that security answers must contain.
  2. Click Save / Update Policy.

Configure Password Policy Rules

  1. To create a password rule, click Add Rule. In the screen that opens, enter any desired policy name and description.
  2. Configure the following items.
    • Rule Name: Enter or modify the rule name.
    • Exclude Users: Specify which users (if any) that you want to exclude from the effects of the rule.
    • When a User is located: Apply the rule to users with any of the following connection statuses:
      • Anywhere: Applies the rule to all users regardless of whether or not their IP address is listed in the Public Gateway IPs list.
      • On Network: Applies the rule to users whose IP address is listed in the Public Gateway IPs list.
      • Off Network: Applies the rule to users whose IP address is not listed in the Public Gateway IPs list.


For information on the Public Gateway IPs list and the IP Zones features, see Network Zones.

The user can: Specify whether users can change or reset their password, or unlock their account. Note the following:

    • Change password: This option must be selected in order for the option Perform self-service password reset to be available.
    • Perform self-service password reset: Select to allow users who are locked out to perform self-service password resets (That is, Forgot password? appears on the end-user sign-in page).
    • Perform self-service account unlock: The self-service unlock option allows users to unlock their account by clicking the Unlock account? link on the sign in page. If you do not allow self-service unlock, see Reset an individual user password.
  1. When done, click Update Rule / Create Rule.

Related topics

About password policies

About MFA enrollment policies

About Okta sign-on policies

About app sign-on policies

Configure an Okta sign-on policy

Configure an MFA enrollment policy

Configure an app sign-on policy