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

You are completely right—this observable difference defeats the entire purpose of User Enumeration Prevention (UEP) for that specific flow.

Here is the breakdown of why this is happening and how you can force consistency.

Is this an acknowledged gap?

Yes, this is a known architectural quirk in Okta Identity Engine (OIE). The inconsistency is the result of Okta's UX optimization logic clashing with its security obfuscation logic:

• Valid User (UX Optimization): When a valid user initiates the unlock flow and only has one recovery authenticator enrolled (in your case, Email), Okta optimizes the experience by skipping the selection screen entirely and auto-selecting their only valid option.
• Invalid User (UEP Fallback): When a non-existent user is submitted, Okta's UEP logic takes over. Because it cannot query a non-existent user's enrolled authenticators, it falls back to your org-level or policy-level allowed authenticators. Even if Email is the only allowed recovery method, the UEP fallback generates a generic mock response that renders the available options as a selectable list.

Furthermore, Okta’s official documentation explicitly notes limitations surrounding UEP in recovery flows. Most notably, UEP is completely unsupported in recovery scenarios if your org is using the Okta Account Management Policy (the newer policy framework for managing self-service recovery and authenticator enrollment).

You can also check our doc here :

https://support.okta.com/help/s/article/user-enumeration-prevention-influencing-okta-sspr?language=en_US

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.

Hi Paul,

Thank you for the detailed explanation - the architectural breakdown is helpful.

I do want to clarify one point though: we are not using the Okta Account Management Policy. We are on the "legacy" configuration, so the limitation you mentioned regarding UEP being unsupported under that newer policy framework does not apply to our setup, and we are already aware of it.

The core issue we are seeing is this: with the exact same legacy configuration, the behavior is inconsistent across flows:

• Password Reset - UEP works correctly. The response is identical regardless of whether the account exists.
• Unlock Account - UEP does not work. The observable difference between a valid and invalid account remains, as described in my original post.

Since the only variable here is the flow (Password Reset vs. Account Unlock), and both are governed by the same legacy configuration and policy settings, this suggests a flow-specific gap in the legacy UEP implementation for Account Unlock.

Could you confirm whether this is a known gap specifically in the legacy (non-Account Management Policy) Account Unlock flow, and whether there is a workaround or a fix planned?