Windows Hello for Business Doesn't Work Over RDP — Here's What Actually Does

A user unlocks their laptop with a fingerprint every morning without a second thought. Then they open Remote Desktop Connection to a server, and Windows Hello for Business simply isn't offered as an option — they're back to typing a password, or worse, staring at a credential prompt that rejects everything they try. The instinctive reaction is "this is broken, WHfB should just work here too." It isn't broken. Windows Hello for Business was never designed to authenticate a remote session the way it authenticates the local device, and Microsoft's own documentation is explicit about it. This post explains exactly why, and walks through the two approaches Microsoft actually supports instead.

The problem — a working WHfB gesture, and a remote session that won't accept it

Here's the exact scenario. A device is Microsoft Entra joined, Windows Hello for Business is fully provisioned, and the user signs in every day with face or fingerprint recognition without issue. That same user opens mstsc.exe to connect to another Windows device — a jump box, an on-prem application server, an Azure Virtual Desktop session host — and the Windows Hello gesture that just worked seconds ago is nowhere to be found. Depending on configuration, they either get dropped straight to a standard password prompt, or they see a message stating that the selected credential requires local smart card and Windows Hello for Business devices to be made available to the remote session.

Nobody changed a policy. Nothing broke overnight. This is the default, expected behaviour, because a Windows Hello for Business credential and a remote desktop session are two fundamentally different trust boundaries — and understanding that boundary is the entire key to fixing this properly instead of fighting it.

Why it happens — the credential is bound to a chip, not to you

A Windows Hello for Business PIN or biometric gesture doesn't authenticate you directly to anything. It unlocks a cryptographic key pair that Windows generated and sealed inside your device's TPM (Trusted Platform Module) — Microsoft's documentation calls this the Microsoft Passport Key Storage Provider (KSP). That private key never leaves the TPM, is never exported, and by design cannot be transmitted anywhere, including to a remote session running on a different physical or virtual machine. Your fingerprint doesn't "log you in" to a remote server. It unlocks a key that only exists, physically, in the chip on the device sitting in front of you.

RDP's standard mechanism for using local credentials on a remote connection is credential redirection — specifically, redirected smart card support. A physical smart card and its PIN can be redirected over an RDP session because the card presents itself to the remote session as a device, and the remote session can query it. A TPM-sealed WHfB key doesn't work that way by default; there's no redirected "TPM device" concept. This is exactly why Microsoft's supported RDP path (covered below) works by making Windows emulate a smart card using a certificate stored in the WHfB container — not by finding some way to project the raw WHfB gesture into the remote session.

Both of Microsoft's real, supported approaches follow directly from that constraint: either give the device a certificate it can present as a redirected smart card, or skip credential transmission entirely with a Kerberos-based mechanism that never sends anything resembling a password or key to the remote host.

How to verify — check what your device is actually carrying before you configure anything

Before configuring either fix, confirm the device's current state. Two things matter: whether a redirected-smart-card-capable certificate already exists in the WHfB container, and whether the target device is Active Directory domain-joined or Microsoft Entra joined — because that single fact determines which of the two fixes is even available to you.

If Provider = Microsoft Passport Key Storage Provider appears against a certificate whose Extended Key Usage includes Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2), the device already has what it needs for certificate-based RDP sign-in. If nothing comes back with that provider, no such certificate has been deployed yet.

The fix — two supported paths, chosen by what your target device is joined to

Cover both CSP (Intune) and Group Policy paths for whichever route applies, since most estates run a mix of both during a hybrid transition.

Path 1 — Certificate-based sign-in (works for any target, AD or Entra joined)

This deploys a certificate into the WHfB container that Windows can present as a redirected smart card credential. Microsoft documents two deployment routes for the certificate itself: Microsoft Intune with a SCEP or PKCS certificate profile, or an Active Directory Certificate Services (AD CS) enrollment policy for hybrid-joined devices with line of sight to a CA.

Once deployed, verify with the same certutil -store -user my command shown above. Users can then RDP to any device in the same Active Directory forest as their account by opening Remote Desktop Connection — they're prompted to unlock the certificate's private key with their existing WHfB gesture, and the certificate does the rest.

Path 2 — Remote Credential Guard (works only for AD domain-joined targets)

Remote Credential Guard needs no certificate deployment at all. It uses Kerberos to give the remote session single sign-on as the connecting user, while ensuring credential material never crosses the wire to the target device — genuinely more secure than certificate-based sign-in, but only usable when the target is AD domain-joined.

Two settings are required: one on the remote host (enable delegation of nonexportable credentials), one on the client (require Remote Credential Guard for outbound connections).

Don't want to roll this out tenant-wide yet? Force it for a single connection without touching policy at all:

Troubleshooting the Intune policy delivery, not just the WHfB behaviour

Both fixes in this post are delivered as Intune configuration profiles, not compliance policies — worth being precise about, because the two get confused constantly. A configuration profile pushes a setting to the device (the WHfB policy itself, or the SCEP/PKCS certificate profile for RDP). A compliance policy only ever evaluates and reports a pass/fail state; it never configures anything. But compliance can still block this entire scenario indirectly: if a Conditional Access policy requires the target resource to see "device marked as compliant," and that compliance state hasn't evaluated yet, the connection gets refused regardless of whether your WHfB certificate or Remote Credential Guard policy is perfectly configured.

When either fix "should" work but doesn't, check the Intune side before assuming the WHfB or RDP configuration itself is wrong:

If the portal shows the profile as delivered but the device still doesn't behave correctly, confirm what actually landed locally. Rather than checking the registry by hand, this site's own local Intune policy export script dumps both the relevant hives — PolicyManager\current\device (where the WHfB CSP settings land) and SOFTWARE\Microsoft\Enrollments (the enrollment record itself) — into one readable report in seconds.

What the community is saying

This exact limitation trips up enough admins that it comes up repeatedly across the Microsoft MVP community — several of whom are aggregated on this site's own MVP Feed.

Both point at the same documented fact confirmed directly on Microsoft Learn's cloud Kerberos trust deployment guide, under Unsupported scenarios: "RDP/VDI scenarios using supplied credentials (RDP/VDI can be used with Remote Credential Guard or if a certificate is enrolled into the Windows Hello for Business container)." That's the exact same two-path guidance this post walks through — cloud Kerberos trust specifically can't supply the credential directly, but both supported workarounds remain fully available regardless of which WHfB trust model (key, certificate, or cloud Kerberos) the device uses.

Proof it worked — Test-WHfBRdpReadiness.ps1

This script checks, on a given device, exactly what's needed to know before troubleshooting an RDP + WHfB complaint: whether WHfB is actually provisioned, whether a redirected-smart-card-capable certificate exists in the container with the right EKUs, and what the local Remote Credential Guard client policy is currently set to. It makes no changes of any kind.

That's a genuine "before" result — WHfB is provisioned on this device, but neither RDP fix has been configured yet, which is exactly the state this post exists to help you move out of.

References

• Remote Desktop sign-in with Windows Hello for Business — Microsoft Learn
• Remote Credential Guard — Microsoft Learn
• Windows Hello for Business cloud Kerberos trust deployment guide — Microsoft Learn
• Policy CSP - ADMX_CredSsp — Microsoft Learn
• MVP Feed — EndpointWeekly
• Deploy Free WHfB Health Scripts to Intune — EndpointWeekly