Disable Windows Hello for RDP remote credentials prompt

Question

We would like to disable the option where clients are able to Login with Whfb over RDP.

Whfb is used to logon to the Azure Joined windows devices, but when connecting to Domain Joined RDP servers, it asks at first for PIN, as a Kerberos Cloud / Safeguard trust is not possible in the setup and (some) users are confused which password to use, need would like to disable the option totally.

In the past we have done this via the RDP settings in mstsc. but after an update, the clients start receiving prompts again, is there a way with registry adjustments, policies, or any other long term trick to remove the option to logon with PIN fully for RDP Connections?

Thanks in advance

Answer 1

Hello again Eltjo Schol,

Just following up with your issue. Re-evaluating my previous recommendations regarding the DisableSmartCardNode registry key and the server-side fDisableSmartCard configuration, I must correct the architectural approach to this issue. While those policies successfully block virtual smart card redirection at the session host and kernel levels, they fundamentally cannot prevent the local Windows Security prompt from displaying the PIN option during the initial Network Level Authentication (NLA) handshake. This occurs because the Remote Desktop client relies on the universal CredUIPromptForWindowsCredentials API. When NLA is enforced, this API invokes the local machine's Credential Security Support Provider (CredSSP), which automatically enumerates all active system-wide credential providers, including the Windows Hello for Business (WHfB) PIN, entirely independent of the remote server's target capabilities.

Because the Windows LogonUI and CredUI subsystems share the exact same underlying credential provider architecture on the local Azure AD joined device, there is currently no native registry adjustment, Group Policy, or Microsoft-supported method to selectively exclude the WHfB PIN credential provider exclusively for the mstsc.exe process. Any attempt to globally block the WHfB credential provider GUID via the ExcludeCredentialProviders policy will persistently break the user's ability to log into their local physical device. Furthermore, as you noted with your past RDP settings, modifying connection strings in the .rdp files to bypass local CredSSP (such as setting enablecredsspsupport:i:0) is only a temporary workaround, as workspace feeds, Intune policies, or feature updates routinely overwrite these configurations back to their defaults.

I must admit that this is a known technical limitation within the current Windows credential provider architecture. Since configuring a Hybrid Cloud Kerberos Trust to seamlessly authenticate the PIN against the on-premises domain is strictly not possible in your environment, the resulting credential prompt confusion cannot be administratively bypassed at the client level. Microsoft has not yet introduced application-specific credential provider filtering. Until then, your users will unfortunately need to manually select the password option via the "More choices" interface during the RDP handshake.

Hope this answer brought you some useful information. If it has, please consider accepting the answer so that other people sharing the same issue would benefit too. Thank you :)

VP

Answer 2

Hello again Eltjo Schol,

Evaluating your environment description, we need a slight clarification on whether the PIN prompt occurs locally before the connection establishes via CredSSP, or remotely on the Terminal Server screen.

Regarding your deployment of the DisableSmartCardNode registry value under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork, your lack of success is almost certainly due to a pending system state. This specific policy dictates the behavior of the Windows Virtual Smart Card reader driver operating at the kernel level. Modifying this registry node strictly requires a full system reboot to completely unload the WHfB smart card emulation subsystem from the Windows Device Manager. Please ensure the affected client machines have been fully restarted after applying the DWORD value of 1, as restarting the mstsc.exe process alone will not apply the hardware-level change.

If the local registry adjustment continues to fail after a verified reboot, the most robust, long-term architectural solution is to enforce the restriction on the target Terminal Servers rather than battling client-side registry overwrites. By accessing your domain-joined RDP servers and navigating to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services, you can create a new DWORD value named fDisableSmartCard and set it to 1. This configuration explicitly instructs the Remote Desktop Session Host to reject smart card device redirection during the Network Level Authentication handshake. Consequently, the local client's CredSSP is forced to instantly bypass the WHfB PIN emulation and default directly to standard username and password credentials, permanently resolving the prompt confusion.

VP

Answer 3

Hello Eltjo Schol

The recommendation to disable Windows Hello for Business smart card emulation is technically accurate and aligns with Microsoft's documented behavior for WHfB legacy application compatibility. When mstsc.exe initializes an RDP session, the Local Security Authority subsystem detects the WHfB container and prioritizes it, prompting for a PIN despite the lack of Cloud Kerberos Trust in your target domain. Enforcing the DisableSmartCardNode DWORD value of 1 at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork permanently suppresses this by preventing WHfB from projecting credentials as virtual smart cards to the Windows security subsystem. Deploying this via the Intune Settings Catalog ensures persistent enforcement against feature update regressions that typically overwrite local user-profile connection strings.

While your environment description is adequately detailed to diagnose the root cause, applying this system-wide registry fix requires verifying if your endpoints rely on smart card emulation for any other legacy authentications, such as older VPN clients or internal legacy web applications. Disabling the node globally will completely break WHfB authentication for those specific workloads. If you must isolate the fix exclusively to the Remote Desktop client without affecting system-wide emulation, a more robust best-practice alternative is configuring the Exclude credential providers administrative template. By appending the smart card credential provider GUID to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System registry key under the ExcludeCredentialProviders string value, you specifically block the PIN prompt for RDP authentication without dismantling the underlying smart card emulation architecture. Confirm if your environment utilizes WHfB smart card emulation for other legacy services so we can determine the safest deployment path.

Do you find this answer useful? Should you have more questions, feel free to leave a comment. If the answer helps you get more insight into the issue, please consider accepting it. Thank you and have a nice day!

VP

Answer 4

To disable Windows Hello for Business (WHfB) for Remote Desktop Protocol (RDP) connections, you can consider the following approaches:

1. Exclude Password Credential Provider: You can use the Exclude credential providers policy setting to disable the password credential provider. This setting disables the possibility of using passwords for all accounts, including local accounts, which might also impact RDP connections. However, this might not be the most suitable option if you need to allow local account logins for troubleshooting.
2. Windows Passwordless Experience: If you have Windows Hello for Business enabled, you can configure the Windows passwordless experience, which hides the password credential provider for user accounts that sign in with Windows Hello or a FIDO2 security key. However, this is only applicable to Microsoft Entra joined devices.
3. Group Policy: You can configure Group Policy settings to manage RDP connections. Specifically, you can look into settings under Computer Configuration > Administrative Templates > System > Logon to manage credential providers.
4. Registry Adjustments: While specific registry adjustments for this scenario are not detailed in the provided context, generally, you can look for settings related to credential providers in the Windows registry. However, be cautious with registry changes as they can affect system behavior.
5. Remote Credential Guard: As an alternative, consider using Remote Credential Guard, which provides single sign-on (SSO) to RDP sessions using Kerberos authentication and does not require the deployment of certificates. This might simplify the login process for users.

It's important to test any changes in a controlled environment before deploying them broadly to ensure they meet your organization's needs without causing unintended issues.

---

References:

• Remote Desktop sign-in with Windows Hello for Business
• Common questions about Windows Hello for Business