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 relies on managed devices and IP zones.

Add the rule

  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 Authenticator enrollment.

  5. Set the following IF conditions.

    • User type: Any user type

    • User group membership includes: Any

    • User is: Any

    • Device state is: Registered

    • Device management is: Managed

    • Device assurance policy is: No policy

    • 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' )

  6. 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

  7. Click Save.

  8. Move this rule to priority 1.

User experience

Users must be on a managed device, 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, all fields in their profile settings are read-only, including the Reset, Update, and Remove options for their existing security methods. The phishing-resistant authenticators that they haven't enrolled are hidden, which 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.

Related topics

Okta account management policy

Add a rule for password recovery and account unlock