<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D5WR00001VdhFF0AZOkta Classic EngineMulti-Factor AuthenticationAnswered2026-04-06T17:33:39.000Z2026-04-05T21:22:05.000Z2026-04-06T17:33:39.000Z

IsaacB.81593 (Customer) asked a question.

Account management policy defaults and self-serve password changes in OIE with no factors enrolled

In OIE, if a user only has password enrolled, and it's not expired, and they want to change it, will Account Management policy require enrollment in another authenticator before the user can proceed?

 

I've been trying this in test environments and am getting the following outcomes. Do I understand the functionality correctly?

 

  • Password is required and all authenticators are optional.
  • Account Management policy rules set to their defaults (Okta-provided "Expiry" and "Catch-all" rules.)
  • Global session policy requires password only.
  • If a user tries to sign in to Okta, they are prompted for password thanks to the global session policy.
  • If a user tries to access an app, they are prompted for the factors required by that app's auth policy.
  • If their password expires, they can update it with no other factor prompt, thanks to the "Expiry" rule in the account management policy.
  • If a user wants to enroll an additional available factor, they can do so, thanks to the "Catch-all" rule in the account management policy.
  • But, If they only have password enrolled, and it's not expired, and they want to change it, Account Management policy appears to require enrollment in another authenticator before the user can proceed.

 

Thanks,

 

 


  • paul.stiniguta (Okta, Inc.)

    Hello @IsaacB.81593 (Customer)​ Thank you for posting on our Community page!

     

    The behaviour you see if expected and it works as intended. Because a proactive password change is considered an account modification rather than a recovery or expiry event, it hits the stricter 2-factor Catch-all rule.

    If you wanted users to be able to change unexpired passwords with only one factor, you would have to lower the requirement on the Catch-all rule to Any 1 factor type—though Okta generally advises against this, as it lowers the security posture for all self-service profile edits.

     

    Thank you for reaching out to our Community and have a great day!

    --

    Help others in the community by liking or hitting Select as Best if this response helped you.

    Expand Post
    Selected as Best
  • paul.stiniguta (Okta, Inc.)

    Hello @IsaacB.81593 (Customer)​ Thank you for posting on our Community page!

     

    The behaviour you see if expected and it works as intended. Because a proactive password change is considered an account modification rather than a recovery or expiry event, it hits the stricter 2-factor Catch-all rule.

    If you wanted users to be able to change unexpired passwords with only one factor, you would have to lower the requirement on the Catch-all rule to Any 1 factor type—though Okta generally advises against this, as it lowers the security posture for all self-service profile edits.

     

    Thank you for reaching out to our Community and have a great day!

    --

    Help others in the community by liking or hitting Select as Best if this response helped you.

    Expand Post
    Selected as Best

Loading
Account management policy defaults and self-serve password changes in OIE with no factors enrolled