<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-07-10T14:56:53.000Z2026-06-24T18:19:57.000Z2026-07-10T14:56:53.000Z

MikeP.85680 (Customer) asked a question.

Edited June 24, 2026 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?

  • 3 answers
  • 161 views

  • Paul S. (Okta, Inc.)

    Hello @MikeP.85680 (Customer)​ Even though Password Reset and Account Unlock are governed by the exact same legacy policy settings, they use different underlying evaluation sequences in OIE:

    • Password Reset: The UEP obfuscation logic successfully intercepts the request and enforces a consistent response before Okta's UX optimization logic can auto-select a single enrolled authenticator.
    • Account Unlock: The sequence is slightly inverted. The UX optimization logic (which looks for a single enrolled authenticator to auto-select) executes before the UEP fallback logic can standardize the response. This creates the exact observable difference you are seeing between valid users (who get auto-routed) and invalid users (who hit the fallback mock list).
    •  

    Additionally, you can open a case with Support for an additional deep dive into this to see if maybe something else is missed.

     

    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 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

  • MikeP.85680 (Customer)

    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.

     

    image 

    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?

    Expand Post

    • Paul S. (Okta, Inc.)

      Hello @MikeP.85680 (Customer)​ Even though Password Reset and Account Unlock are governed by the exact same legacy policy settings, they use different underlying evaluation sequences in OIE:

      • Password Reset: The UEP obfuscation logic successfully intercepts the request and enforces a consistent response before Okta's UX optimization logic can auto-select a single enrolled authenticator.
      • Account Unlock: The sequence is slightly inverted. The UX optimization logic (which looks for a single enrolled authenticator to auto-select) executes before the UEP fallback logic can standardize the response. This creates the exact observable difference you are seeing between valid users (who get auto-routed) and invalid users (who hit the fallback mock list).
      •  

      Additionally, you can open a case with Support for an additional deep dive into this to see if maybe something else is missed.

       

      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
User Enumeration Prevention not applied to Self-Service Account Unlock flow