Okta Prompts Users to Re-enroll Okta Verify When Administrators Enable a Phishing-Resistant Policy
Last Updated:
Overview
When an administrator enables a phishing-resistant authentication policy for an application, Okta prompts users who already have Okta Verify configured to re-add the authenticator. This action creates a second Okta Verify profile on the user device. This occurs because the existing Okta Verify enrollment lacks the strict phishing-resistant requirements, such as Okta FastPass or hardware-bound keys. To resolve this, users must complete the prompt to register a phishing-resistant authenticator, or administrators must adjust the authentication policy if the organization does not strictly require phishing resistance.
Applies To
- Okta Identity Engine (OIE)
- Okta Verify
- Authentication Policies
Cause
The new authentication policy requires a phishing-resistant authenticator. If the user previously set up the Okta Verify enrollment using a non-phishing-resistant method, such as a standard push notification or a time-based one-time password (TOTP), Okta prompts the user to enroll in a method that satisfies the new policy. This action adds a new, hardware-bound Okta Verify profile to the device.
Solution
Why does the phishing-resistant policy prompt for a new Okta Verify enrollment?
Okta expects this behavior when an administrator enforces a phishing-resistant authentication policy. Phishing resistance requires specific authenticator characteristics, such as hardware binding and Okta FastPass. If a user previously enrolled in Okta Verify using standard push notifications or TOTP, that enrollment fails to satisfy the phishing-resistant requirement. Consequently, Okta prompts the user to register a new authenticator that meets the policy criteria.
Administrators can manage this transition for a production rollout by communicating the change, pre-enrolling users, or adjusting the authentication policy.
- Communicate the change: Inform users that Okta will prompt them to set up Okta Verify again to enable enhanced security features.
- Pre-enroll users: Encourage users to set up Okta FastPass before enforcing the policy on the application.
- Adjust the policy: Modify the authentication policy rule to allow standard Okta Verify push or TOTP by removing the phishing-resistant constraint if the organization does not strictly require phishing resistance.
Therefore, Users must re-enroll Okta Verify when an administrator enables a phishing-resistant policy because standard enrollments lack the new security requirements.
