<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
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D5WR00001oTPKl0AOOkta Classic EngineAuthenticationAnswered2026-06-24T21:06:06.000Z2026-06-24T18:19:57.000Z2026-06-24T21:06:06.000Z

MikeP.85680 (Customer) asked a question.

Edited yesterday at 6:33 PM
User Enumeration Prevention not applied to Self-Service Account Unlock flow

We have User Enumeration Prevention (UEP) enabled in our org, and it works as expected for the login and password reset flows. However, we've noticed a behavioral inconsistency in the self-service account unlock flow that appears to undermine UEP entirely.

 

Observed behavior

 

When a user submits the account unlock form:

 

1. Account exists: the form immediately pre-selects "Email" with no authenticator list shown.

 

Screenshot 

2. Account does not exist: the form displays a list of available authenticators (email is the only option in our case, but it is presented as a selectable list item).

 

Screenshot 

 

Expected behavior

The response should be identical regardless of whether the account exists - either always show the authenticator selection list, or always pre-select email. No observable difference should be present between the two states. This is exactly how it works for the Forgot Password scenario btw.

 

Questions

- Is there a configuration workaround to enforce consistent behavior for the unlock flow?

- Is this a known issue or an acknowledged gap in UEP coverage?

  • 1 answer
  • 18 views

  • Paul S. (Okta, Inc.)

    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.

    Expand Post

Loading
User Enumeration Prevention not applied to Self-Service Account Unlock flow