Add a rule for password recovery and account unlock

Add this rule to require phishing-resistant authenticators when users reset their passwords or unlock their accounts.

Traditionally, the password policy controls the authentication requirements for these self-service processes. If you're not ready to switch to phishing resistance for either of these processes, you can continue using the password policy.

Prerequisites

If your org uses the third-generation Sign-In Widget, upgrade to version 7.20 or later for all brands.

All users in your org must be eligible to use the phishing-resistant authenticators. See Create an authenticator enrollment policy.

Before you begin

Change the access control settings in your password policy.

1. In the Admin Console, go to SecurityAuthenticators.
2. In the Password row, click Actions Edit.
3. In the Rules section, click the edit icon for the default rule.
4. In the Recovery authenticators section, set the Access control condition to Authentication policy.
5. Click Update rule.
6. Repeat steps 3 through 5 for any other password policy rules.
7. Review the Users can perform self-service condition in each rule. If the unlock and recovery processes aren't covered by the existing rules (together or combined), add a rule that specifically allows them. New rules that you add default to the Authentication policy setting.

Configure your account management policy

1. In the Admin Console, go to SecurityAuthentication Policies.
2. Select Okta Account Management Policy.
3. Click Add Rule.
4. Enter a descriptive rule name, like Phishing-resistant password and account recovery.
5. Set the following IF conditions.
   • User type: Any user type
   • User group membership includes: Any
   • User is: Any
   • Device platform is: Any platform
   • User's IP is: Any
   • Risk is: Any
   • The following custom expression is true: accessRequest.operation == 'recover'|| accessRequest.operation == 'unlockAccount'
6. Set the following THEN conditions.
   • Access is: Allowed after successful authentication
   • User must authenticate with: Possession factor
   • Possession factor constraints are: Phishing resistant
   • Authentication methods: Allow any method that can be used to meet the requirement
   • Prompt for authentication: Every time a user signs in to a resource
7. Click Save.

Exceptions

The following password reset flows don't enforce the Okta account management policy:

• Admin-initiated password resets: The user must enter the temporary password or click the link in the email, but they don't require more factors.
• Expired passwords: When a user's password expires, they can change it by providing only their expired password. No additional factors are required.

Okta recommends securing all of your apps by requiring MFA in your authentication policies.

User experience

There are no changes to the user experience when you move password recovery and account unlock to the account management policy.

• When a user resets their password, it doesn't count as a factor if you require password + another factor. Ensure that there are at least two more authenticators, besides password, that the user can authenticate with.
• Keep me signed in works with the account management policy if you configure the authentication frequency correctly. The Prompt for authentication setting must be more frequent than the equivalent setting in the authentication policy for the End-User Dashboard. Setting Prompt for authentication in your Okta account management policy to every time ensures that users don't have to wait to reset a password.
• User enumeration prevention isn't supported in recovery scenarios with the Okta account management policy.

User settings

If a user doesn't satisfy the requirements of this rule, the Reset and Remove options for password are hidden. Authenticators that they haven't enrolled are also hidden.

Related topics

Okta account management policy

Add a rule for authenticator enrollment

Edit the Okta account management policy