Hello @A.AnnaS.82284 (Customer)​ Thank you for posting on our Community page!

This is a very common and frustrating pain point for teams migrating to Okta Identity Engine (OIE) with mixed-management environments.

Address your primary question immediately: There is no native, out-of-the-box toggle in the Okta Admin Console to conditionally hide the Okta Verify for Windows download prompt based on device management state during enrollment. Here is a breakdown of why this happens and how other IT and Identity and Access Management (IAM) teams are handling it.

The Root of the Problem: Same Device Enrollment

When you enable FastPass (all platforms) in your Okta Authenticator settings, Okta activates a feature called Same Device Enrollment. Because Okta Verify is treated as a single unified authenticator (handling both mobile Push and desktop FastPass), Okta's browser enrollment flow automatically detects the user's OS.

If it detects Windows, it aggressively prioritizes the Windows desktop app to encourage FastPass adoption. Okta's Authenticator Enrollment policies dictate who can enroll in Okta Verify, but they cannot dictate which version (mobile vs. desktop) the UI prioritizes based on whether the device is Intune-managed, a VDI, or unmanaged.

How Organizations Are Handling This

Since native controls fall short here, admins typically rely on one of the following workarounds to protect their user experience and service desk queues.

1. Customizing the Sign-In Widget (CSS/JS Injection)

If you are using a Custom URL Domain in Okta, you can modify the HTML, CSS, and JavaScript of your Okta-hosted Sign-In Widget.

• The Strategy: Admins inject custom CSS to hide the DOM element for the "Download Okta Verify for Windows" button, or they use a simple JavaScript snippet to force the "Mobile" enrollment tab to be the default active view.
• The Catch: You have to maintain this custom code. If Okta updates the widget and changes their CSS class names, your custom injection might temporarily break.

2. Tailoring the UI Localization Strings

If you cannot or prefer not to use custom CSS, you can change the text directly on the enrollment screen to forcefully guide the user's behavior.

• The Strategy: Using Okta's Customization > Brands > Settings > Email and Language (or within the code of your Custom Sign-In Widget), you can modify the default Okta localization strings. You can change the standard enrollment text to something impossible to miss, such as: "VDI AND UNMANAGED USERS: STOP. Do not install the Windows app. Click 'Setup Okta Verify on Mobile' below."
• The Catch: Users notoriously ignore warnings and click the biggest blue button on the screen anyway, so this usually only reduces help desk tickets rather than eliminating them entirely.

3. Alternative Authenticators for Unmanaged Cohorts

If your offshore VDI users do not strictly require Okta Verify Push, you can separate their authentication methods entirely to bypass the FastPass trap.

• The Strategy: Adjust your Authenticator Enrollment Policies so that Okta Verify is only allowed for the UK-based Intune group. For the offshore thin clients, require a generic Google Authenticator or OATH TOTP.
• The Catch: Offshore users lose the convenience of Push notifications and have to manually type in 6-digit codes.

4. Engaging Okta Support for Backend Feature Flags

Okta controls some of the aggressiveness of the "Same Device Enrollment" flow via backend feature flags on your tenant.

• The Strategy: Open a ticket with Okta Support. Explain clearly that Same Device Enrollment is breaking your VDI and unmanaged laptop deployments because users lack install permissions. In some instances, Okta can tweak the feature flags on your specific tenant to revert the UI to prioritize the mobile QR code flow by default.

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 your detailed response. I really appreciate the time taken to explain each option.

We're not currently using a custom URL domain, and I suspect tinkering with the sign in page would come back to bite us eventually. I will do some testing in a sandbox to see how this behaves, but I suspect it'd be more likely something we'd look if we rebuild our hub tenant, which is a massive body of work which is probably not likely to happen.

Google auth is a good shout. This will be quite complex to manage because we'll be trying to separate users for testing FP, users who will never use FP, and users who will use FP but not yet, without accidentally allowing the last group access to enrol Google auth. There are combined environments involved offshore, so it's naturally not straight forward as just looking at the environment they are on, location, or company they work for, but this is definitely worth exploring.

I think we've been advised the backend feature for same device enrollment was already off for one of our sandboxes I was testing on, but I've raised a new support ticket to double check. If this is something that works this could be key to moving forward.

I am wary every time we catch up with our CSM we're warned about the risks of not having FastPass and how phishing-resistant MFA needs to become our primary authenticators. It feels like there's a major gap in getting customers like us onboarded that I can't plug on my own? I've not had much luck posting in the Ideas forums before, appreciate everyone has ideas and Okta can't listen to them all.

I am keen to hear from others in our situation, I don't know how many customers are similar to our setup that might be willing to share experiences.

Kind regards

Anna