About authenticator enrollment policies and rules

Authenticator enrollment policies control how users enroll themselves in an authenticator. You can create and enforce policies and rules for specific authenticators and situations and require specific groups of users to use them.

Global Session Policies determine the types of authentication challenges that end users experience when they sign into their account. Policies allow you to configure various criteria that you can use to allow or block sign-ins:

  • Determining the user's location
  • Identifying the groups the user is assigned to
  • Identifying the authenticator type the user is using

Policies can also specify actions to take, such as allowing access or prompting for a challenge.

Changes to behavior

  • If an authenticator that appears in a password policy for self-serve password reset (SSPR) isn't enabled for single sign-on, it doesn't appear in authenticator enrollment policies.
  • When the Email, Security Question, or Phone authenticators are required for SSPR, the enrollment requirement differs:
    • Email or Security Question: Users must enroll in these authenticators.
    • Phone: Users may choose whether to enroll in this authenticator.
  • The actions to Enroll on first challenge and Enroll for sign-on are no longer differentiated actions. If a user is missing a required authenticator, they're prompted to enroll in the required authenticators when they sign in to any app.
  • If a user hasn't enrolled in an authenticator that their admin has set as required, they are prompted to enroll in it when they sign in.
  • If a user hasn't enrolled in an authenticator that is required by an app's authentication policy, they are prompted to enroll in it when they attempt to access the app.
  • If Phone and FIDO2 (WebAuthn) (Security Key or Biometric) are configured as optional authenticators in an authenticator enrollment policy, then the user has only enrolled in the Password authenticator. If they try to access an app that requires MFA with a possession factor type, then they're prompted to enroll in authenticators that satisfy the possession factor type.
  • For account recovery: If admins created a password policy that allows users to perform self-service recovery with Email, Phone, or Security Question authenticators, Okta prompts users to enroll in these additional authenticators when they first sign in, even if these authenticators are disabled in the authenticator enrollment policy.
    • Email and Security Question authenticators are required if they're configured in the password policy rules for recovery
    • Email is auto-enrolled, so end users don't need to enroll manually
    • Phone is optional
  • For first-time account setup: If an admin creates an authenticator enrollment policy that allows users to authenticate themselves during subsequent sign-ons using one group of authenticators, and creates a self-service recovery policy that uses a different group of authenticators, then, when the end user enrolls in Okta for the first time, the end user must enroll themselves in all of the authenticators from both the authenticator enrollment policy and the self-service recovery policy. All authenticators from both of these policies are available to the end user. During first-time account setup, Okta evaluates both of these policies at the same time. During subsequent sign-ons by the end user, regular processing rules are applied. The policies are evaluated separately and authenticators are no longer 'pooled' between the authenticator enrollment policy and the self-service recovery policy.

Current limitations

  • SMS and Voice methods are shown separately in the policy. Configuring either SMS OR Voice requires the user to enroll in the Phone authenticator.
    • For example, if SMS is required and Voice is disabled, the Phone authenticator is required and the user can still use the Voice method to enroll and verify the Phone authenticator.
  • Password: Unless passwordless sign-in experience is enabled, password shows up as a configurable factor. If passwordless sign-in experience is disabled, password is always required unless the user is using Social Authentication or Inbound Federation to authenticate.
  • Email: If set to optional or required, Email is treated as required and auto-enrolls when a user signs in to their account.