This article addresses the scenario in which an Account Okta Account Management Policy rule is created that challenges a specific authenticator during enrollment of new factors or during Self-Service Password Reset (SSPR).
- Okta Account Management Policy
- Okta Identity Engine (OIE)
When creating the Okta Account Management Policy rule that requires specific authenticators or when the password is not part of the allowed authenticators, the scenario is created where the user cannot satisfy the Okta Account Management Policy rule condition without enrolling the required authenticators, resulting in a deny outcome.
To prevent users from being unable to enroll in new authenticators when setting up the initial authenticator, a new Okta Account Management Policy rule is required to allow users to set up the first authenticator with a password.
Creating a new Okta Account Management Policy rule with priority 1 that will use a custom expression to only apply to the enrollment of a specific authenticator.
The custom expression used is the following:
accessRequest.operation == 'enroll' && accessRequest.authenticator.key == 'factorType'
OR
accessRequest.operation == 'enroll' && ( accessRequest.authenticator.key == 'factorType' || accessRequest.authenticator.key == 'factorType' )
FactorType:
- okta_verify
- webauthn
- smart_card_idp
- yubikey_token
- google_otp
- security_question
- okta_email
- phone_number
Below is the Okta Account Management Policy rule that allows enrollment in the Okta Verify factor with a password.
