Windows Hello for Business Not Defaulting to PIN or Biometrics in Hybrid Entra ID – Root Cause and Fix

A Real-World Hybrid Entra ID Troubleshooting Story

Windows Hello for Business (WHfB) is designed to provide a seamless, passwordless sign-in experience. Once enabled, users expect PIN, Face, or Fingerprint authentication to be the default sign-in method.

However, in one of our customer environments, we encountered a strange and frustrating issue where Windows Hello worked perfectly , but never stayed as the default option.

This blog walks through the issue, the false leads, the real root cause, and a simple fix that avoids removing a critical third-party agent.

The Environment

• Hybrid Microsoft Entra ID joined devices
• Windows Hello for Business deployed via Intune
• PIN and biometric authentication enabled
• Mix of modern and legacy applications
• Passwords still required for some business-critical services

The Problem. . .

On affected machines:

• Windows Hello for Business enrollment completed successfully
• PIN, Face, and Fingerprint authentication worked as expected
• Intune policies were correctly applied

• After restart or sign-out, the Windows sign-in screen:
• Defaulted back to Password
• Required users to manually switch to PIN or Biometrics
• Never remembered the last-used sign-in method

What made this more confusing:

• Some test devices worked perfectly
• The issue appeared only on production machines

Initial Troubleshooting and Dead Ends

We started with all the commonly documented checks:

1. Interactive Logon Policy

Many articles point to:

Interactive logon: Don’t display last signed-in Policy

We confirmed this setting was not enabled via:

• Group Policy
• Intune Policy

2. Credential Provider Configuration

Some recommendations suggest:

• Forcing a default credential provider via GPO or Intune

This approach wasn’t viable because:

• Some devices supported PIN only
• Others had biometrics
• The requirement was to preserve user choice, not force a specific method

3. Intune and AD GPO Review

• WHfB policies were correctly scoped
• No conflicting AD GPOs were identified
• Nothing explained why only production devices were affected

At this stage, the issue clearly wasn’t caused by Windows Hello, Intune, or Group Policy.

The Breakthrough: Comparing Installed Agents

The turning point came when we compared:

• Working test devices
• Affected production devices

One difference stood out immediately:

ManageEngine ADSelfService Plus client software

The customer had valid business reasons to keep this agent:

• Legacy applications still depend on passwords
• Self-service password reset remains a requirement
• Manage Engine Offers Mobile App Based Password reset Options
• Full passwordless adoption is not yet possible

So removing the agent was not an option.

The Real Root Cause

The ManageEngine ADSelfService Plus client modifies Windows sign-in behavior by controlling which credential tile is shown by default.

This behavior is governed by a registry setting.

Registry Path : HKLM\SOFTWARE\WOW6432Node\ZOHO Corp\ADSelfService Plus Client Software

Registry Value : Name: ShowSelectedTile

Correct Configuration : ShowSelectedTile = false

What This Setting Controls

True: Forces Password as the default sign-in method

False:  Displays the last-used sign-in method (PIN / Face / Fingerprint)

In our cutsomer environment, the value was set to true, which explained the behavior perfectly.

Manage Engine AD Self Service Document Reference you can find here https://download.manageengine.com/products/self-service-password/gina-cp-installation-using-sccm.pdf  You can find the Value Reference in Page number 9 of this doc

The Fix (Without Removing the Agent)

By changing the registry value to:

ShowSelectedTile = false

The issue was resolved immediately:

• Windows Hello PIN and biometrics remained the default
• The last-used sign-in method was remembered
• ManageEngine ADSelfService Plus continued to function
• Legacy password-based applications were unaffected

No re-enrollment, policy change, or WHfB reset was required

Why This Matters

This issue highlights an important real-world lesson:

Not all Windows Hello problems are caused by Intune, GPO, or Entra ID.

Third-party tools that integrate with:

• Credential providers
• Password workflows
• Login tiles

can silently override Windows sign-in behavior — especially in hybrid environments.

The Real Learning

• If Windows Hello works but doesn’t stay default, check third-party agents also while checking the GPO's & MDM Policy's
• Compare test vs production device software
• Password self-service tools often modify credential behavior by design
• You can support passwordless + legacy passwords together with the right configuration

Final Thoughts

Customers rarely move to passwordless overnight. Hybrid identity, legacy apps, and compliance needs mean passwords often coexist with Windows Hello for Business.

Understanding how third-party identity tools interact with Windows sign-in is critical to delivering a smooth user experience , without breaking business requirements.

Hope this helps anyone running Windows Hello for Business alongside password management solutions in production environments.