Add a rule for enrollment of your first phishing-resistant authenticator
Add this rule to your Okta account management policy if your org doesn't already use a phishing-resistant authenticator. After your users enroll their first phishing-resistant authenticator, you can require it for the other use cases.
If your org already uses phishing-resistant authenticators, see Add a rule for authenticator enrollment.
Prerequisites
-
If your org uses the third-generation Sign-In Widget, upgrade to version 7.20 or later for all brands.
- This rule is applied to users based on their IP zone. See Network zones.
Add the rule
-
In the Admin Console, go to .
- Select Okta account management.
- Click Add Rule.
- Enter a descriptive rule name, like Authenticator enrollment.
- Set the following IF conditions.
- User's user type is: Any user type
- User's group membership includes: Any
- User is: Any
- Device platform is: Any platform
- User's IP is: In any of the following zones (specify your allowed network zones)
- Risk is: Low
- The following custom expression is true:
accessRequest.operation == 'enroll' && ( accessRequest.authenticator.key == 'okta_verify' || accessRequest.authenticator.key == 'webauthn' || accessRequest.authenticator.key == 'smart_card_idp' || accessRequest.authenticator.key == 'yubikey_token' )
- Set the following THEN conditions.
- Access is: Allowed after successful authentication
- User must authenticate with: Any 2 factor types
If you select Any 2 factor types, your users must already be enrolled in two authenticators. Otherwise they're blocked from authenticating. Require your users to enroll in at least two authenticators before they enroll in a phishing-resistant authenticator.
- Possession factor constraints are: Require user interaction
- 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.
- Move this rule to priority 1.
User experience
Users must be inside a trusted network zone and demonstrate low risk behavior before they enroll the designated phishing-resistant authenticator. If they don't meet these requirements, the phishing-resistant authenticators that they haven't enrolled are hidden from the user profile. This means that they can't access any apps with phishing-resistant app sign-in policies.
This rule also applies to authenticator unenrollment, and users can lock themselves out if they unenroll too many authenticators. Encourage users to always maintain at least one phishing-resistant authenticator.