How to get FIDO key working within an Azure Virtual Desktop sessionhost?

Question

I have an Azure Virtual Desktop environment with personal assigned VMs, running Windows 11 25H2. The hostpool is configured with an RDP policy to redirect WebAuthn requests to the local device and map any USB devices that are not yet mapped by another high-level redirection method. I am using my regular Entra ID account to sign in to the VM, which works fine. Beside the regular account I do have a privileged Entra account that has a FIDO key configured. In a local browser on my laptop I can authenticate this PRV account with the FIDO key without any issues. When trying this on a browser inside the sessionhost, it returns:

We couldn't sign you in Something went wrong when trying to sign in with a passkey. Please try again. Learn more about passkeys Sign in another way

My coworker uses another AVD sessionhost VM in the same hostpool and for him the FIDO key works perfectly fine inside the VM.

I tried a lot of different things, even unassigning my account from the sessionhost, deploying a new sessionhost, assigning my account and performing a new Fido key registration on my PRV account from within the sessionhost, which worked once, and then returned to the same behaviour.

Any experience with this, or guidance on what to check would be highly appreciated. Thank you.

Answer 1

For Azure Virtual Desktop, FIDO inside the session depends on WebAuthn redirection and on using the correct sign-in flow inside the remote session.

Check these items in order:

1. Verify WebAuthn redirection prerequisites on both ends.
   • The local PC and the session host must both use supported operating systems for in-session passwordless authentication.
   • WebAuthn redirection must be enabled as a device redirection for the host pool.
   • The local Windows device must already have Windows Hello for Business or a security device such as a FIDO USB key configured.
2. Confirm the FIDO2 method is enabled for the privileged Entra account.
   • If Windows Hello for Business or security keys do not appear as options when accessing Microsoft Entra resources in the session, make sure the FIDO2 security key method is enabled for that user account in Microsoft Entra ID.
3. Use the correct account-selection flow inside the session. If the session host was signed in with a single-factor credential and then a Microsoft Entra resource requires MFA, passwordless methods can fail in-session. In that case:
   • Sign out of the prompt.
   • On the account selection page, select Use another account.
   • Select Sign-in options.
   • Select Sign in with Windows Hello or a security key.
4. Check for an orphaned passkey on the security key. Since re-registration worked once and then failed again, this matches a known issue where a passkey remains on the physical key but is no longer registered in Microsoft Entra ID.
   • Remove the orphaned passkey from the security key by using the security key vendor’s management tool.
   • Re-register a new passkey after cleanup.
5. Rule out unsupported scenarios. FIDO2 security key sign-in to Windows does not support scenarios such as RDP, VDI, and Citrix unless they use WebAuthn redirection. Since the coworker works in the same host pool, the host pool configuration is likely close to correct, so focus on account-specific state, sign-in flow, and the key registration state.
6. Capture Windows client diagnostics from the affected session host. For a user-specific issue that reproduces on one account but not another, collect a trace from the affected Windows client:
   • Open Feedback Hub.
   • Create a new feedback item of type Problem.
   • Choose Security and Privacy > FIDO.
   • Enable Send attached files and diagnostics to Microsoft along with my feedback.
   • Select Recreate my problems > Start capture.
   • Reproduce the failure by attempting the FIDO sign-in in the session.
   • Stop capture and submit.
   • Use the shared feedback link when opening a support case.

What this points to in this case:

• Because another user in the same host pool succeeds, the issue is less likely to be the host pool-wide WebAuthn configuration.
• Because the privileged account works on the local laptop, the key itself is functional.
• Because re-registration worked once and then stopped, the strongest documented check is orphaned passkey cleanup plus retrying the in-session sign-in with Use another account and Sign-in options.

---

References:

• Troubleshoot device redirections for Azure Virtual Desktop
• Configure WebAuthn redirection over the Remote Desktop Protocol (azure-virtual-desktop)
• Sign in with a FIDO2 security key
• Enable FIDO2 security key sign-in to Windows 10 and 11 devices with Microsoft Entra ID
• Troubleshooting for hybrid deployments of FIDO2 security keys in Microsoft Entra ID