About authentication enrollment policies and rules

Authentication 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 end users experience when they sign into their account. Policies allow you to configure a variety of criteria that you can use to allow or block sign-ins, such as determining the user's location, groups the user is assigned to, and the authenticator type they're using. Policies can also specify actions to take, such as allowing access or prompting for a challenge.

Changes to behavior

  • Authenticators required in group password policy for self-service password reset (SSPR) that aren't enabled for SSO will not show up in authentication enrollment policies. If the user is required to use Email or Security Question for SSPR, these authenticators are required for user enrollment. If Phone is required in an SSPR policy, then Phone is treated as optional.
  • 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 will be prompted to enroll in the required authenticators when they sign in to any app.
  • Users will be prompted for authenticator enrollment if they are missing required authenticator enrollments or if the app's authentication policy requires the user to use an authenticator that they have not enrolled.
    • If Phone and Security Key or Biometric (WebAuthn) are optional authenticators in the MFA Enrollment Policy, the user only has Password enrolled. If the user tries to access an app that requires 2FA with a possession factor type, then they will be prompted to enroll for optional authenticators that satisfy possession factor type.
  • For account recovery: If admins have 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 authentication enrollment policy.
    • Email and Security Question authenticators are required if they are 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 authentication 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 authentication enrollment policy and the self-service recovery policy; all of the authenticators from both of these policies are made available to the end user. During first-time account setup, both of these policies are evaluated by Okta 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 authentication 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 will have the user 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 will auto-enroll when a user signs in to their account.
  • App conditions for authentication enrollment policies aren't supported: Admins can’t target authentication enrollment policies to specific applications. The authentication enrollment policy is evaluated on every sign-in to Okta, and users are prompted to enroll in required factors if they don’t already have those factors enrolled.

Topics