Add a rule for your enrolling your first phishing-resistant authenticator
Early Access release. See Enable self-service features.
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
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 Policy.
-
Click Add Rule.
-
Enter a descriptive rule name, like Authenticator enrollment.
-
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: 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
-
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 authentication 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.