Add a rule for authenticator enrollment

Add this rule to build phishing resistance into your authenticator enrollment process. When this rule is active, users must provide a phishing-resistant authenticator when they enroll other authenticators and when they unenroll one. If your org doesn't use phishing-resistant authenticators yet, start with Add a rule for enrollment of your first phishing-resistant authenticator.

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.

Add the rule

In the Admin Console, go to Security > Authentication Policies .
Select Okta account management.
Click Add Rule.
Enter a descriptive rule name, like Phishing-resistant authenticator enrollment.
Set the following IF conditions. The device conditions are an Early Access feature.
- User's user type: Any user type
- User's group membership includes: Any
- User is: Any
- Device state is: Registered
- Device management is: Managed
- Device assurance policy is: Any policy
- Device platform is: Any platform
- User's IP is: Any
- Risk is: Any
- The following custom expression is true: accessRequest.operation == 'enroll' || accessRequest.operation == 'unenroll'
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 user signs in to resource
Click Save.

Note:

Set this rule's priority above the catch-all but below the first phishing-resistant authenticator (if you added that one). Be sure that the first phishing-resistant authenticator rule stays at priority 1.

User experience

If a user meets the requirements of this rule, their experience for this process doesn't change. However, their authenticator choices are limited to the phishing-resistant options. Consider these two scenarios:

Users who are currently activated with a single factor can't enroll new authenticators or sign in to apps that require MFA. Refer to this task's prerequisite.
Users can lock themselves out if they unenroll too many authenticators. Inform your users that they must keep at least one phishing-resistant authenticator enrolled always.