“I want to RDP into a Windows Server 2022 and log in with my FIDO2 security key instead of typing a password.” It sounds like a single feature you turn on. It is not. Whether it works at all depends on one thing most people skip past: what your server and your client are joined to.

Before you touch a single setting, you also need to be clear about which of two completely different things you actually want, because they share the word “FIDO2” and almost nothing else:

1. Authenticate the RDP logon itself with a FIDO2 key – passwordless sign-in to the remote server.
2. Redirect a FIDO2 key into the session so a web app or app inside the RDP session can use WebAuthn, while the key stays plugged into your local machine.

These have different requirements and different failure modes. Let me take them in order, and for the first one walk through all three join states.

First, the one that trips everyone up: a FIDO2 key is an Entra credential

This is the single fact that makes the rest of the post make sense. A FIDO2 security key is registered in Microsoft Entra ID. It is not, by itself, an on-premises Active Directory credential.

So when you log on to a remote server with a FIDO2 key, two things have to happen:

• Entra ID authenticates the key.
• Something has to turn that into a Kerberos ticket the on-prem world (and the server) understands.

That second step is where the join state decides your fate.

Scenario 1: FIDO2 sign-in to the RDP session

Entra-joined

The cleanest case. If both your client and the target are Microsoft Entra joined, FIDO2 sign-in over RDP works with the modern RDP stack (the web-account-selector flow) on current Windows 10, Windows 11 and Windows Server 2022 builds.

The catch with servers: pure Entra join is not supported on Windows Server. Server SKUs do not Entra-join the way a client does. So in practice “Entra-joined target” applies to Windows 10/11 remote hosts, and your Windows Server 2022 box lands in the hybrid scenario below even when the rest of your estate is cloud-first.

What you need:

• Client (and where applicable the host) Microsoft Entra joined.
• FIDO2 enabled as an authentication method in Entra ID > Authentication methods (see Microsoft’s FIDO2 enablement guide), with the user in scope and a key registered.
• Current Windows builds on both ends and an up-to-date RDP client.

For an Entra-joined client signing into an Entra-joined Windows 10/11 host, there is no Kerberos-trust plumbing to configure – it largely just works once the method is enabled.

Hybrid-joined (this is where Server 2022 actually lives)

Because Windows Server 2022 cannot be pure-Entra-joined, hybrid is the realistic target join state for a server. Both the client and the server are Microsoft Entra hybrid joined – joined to on-prem AD and registered to Entra ID.

Here you must build the bridge that turns the Entra FIDO2 authentication into an on-prem Kerberos ticket. That bridge is Microsoft Entra Kerberos, deployed as cloud Kerberos trust:

• Run the Entra Kerberos setup to create the Microsoft Entra Kerberos Server object in your on-prem AD. It shows up as a special computer object (effectively a read-only-DC-style KDC object) that lets Entra ID issue partial TGTs for your AD domain.
• Configure Windows Hello for Business cloud Kerberos trust via Intune or Group Policy so the FIDO2/WHfB credential is allowed to request those tickets.
• Enable the security key sign-in credential provider on the machines. On Entra-joined clients this is on by default; on hybrid-joined devices you turn it on explicitly – via Intune (Authentication method / “Enable security key sign-in”) or the equivalent ADMX policy Turn on security key sign-in under Computer Configuration > Administrative Templates > System > Logon.

With cloud Kerberos trust in place, the flow is: key authenticates to Entra, Entra issues a partial TGT, the on-prem DC completes it, and the server gets a Kerberos logon it trusts. Service tickets and authorization stay on your on-prem domain controllers – you are not moving authorization to the cloud, only the initial credential.

If FIDO2 RDP “authenticates but won’t log on to the server,” cloud Kerberos trust is almost always the missing piece.

On-prem only (no Entra at all)

Here is the honest answer: the native FIDO2 credential provider does not work for on-premises-only devices. Microsoft is explicit about this. No Entra, no FIDO2 sign-in – because there is nothing to issue the Entra side of the credential.

That does not leave you stuck, but it does mean changing the question. Your realistic options are:

• Use the key as a smart card. Many FIDO2 keys also carry a PIV/smart-card applet. Stand up AD CS (your on-prem PKI), issue smart-card logon certificates onto the key, and you get certificate-based passwordless RDP using the long-standing smart-card logon path. RDP already knows how to redirect a smart card reader into the session. This is “passwordless RDP with a security key” in the literal sense, but the mechanism is smart-card logon, not FIDO2/WebAuthn.
• Go hybrid. If passwordless-with-FIDO2 specifically is the goal, the supported route is to hybrid-join the estate and deploy cloud Kerberos trust as above. For most shops this is the better long-term answer than building out smart-card PKI just for RDP.
• A third-party MFA-for-RDP product if you want a step-up factor on top of passwords without the PKI or Entra work.

So: pure on-prem FIDO2 sign-in is not a checkbox – it is either smart-card-via-PKI or a move to hybrid.

Scenario 1 at a glance

Join state (client + server)	FIDO2 RDP logon?	What you have to configure
Entra joined (Win10/11 host)	Yes	FIDO2 method enabled in Entra; current builds
Hybrid joined (typical for Server 2022)	Yes	Entra Kerberos (cloud Kerberos trust) + WHfB cloud trust + security key sign-in enabled
On-prem only (no Entra)	Not natively	Key-as-smart-card via AD CS PKI, or move to hybrid

Scenario 2: WebAuthn redirection into the session

Different problem, much smaller. You do not want to log into the server with the key – you want a website or app running inside the RDP session to use the FIDO2 key that is physically plugged into your local PC.

That is WebAuthn redirection, and the good news is:

• It is supported on Windows Server 2022 (and Windows 10 1809+ / Windows 11).
• It is on by default. There is no positive switch to flip – you only need to make sure nobody disabled it.

The control that matters lives on the server (the RDP host) as Group Policy:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection > Do not allow WebAuthn redirection

Set it to Disabled or Not Configured to allow redirection. If it is Enabled, redirection is blocked and any in-session FIDO2 prompt fails instantly.

This is the one I see bite people most often, and the cause is almost always the same: a hardened golden image. CIS benchmarks and a lot of corporate baselines set “Do not allow WebAuthn redirection” to Enabled. If your security key worked fine on the local desktop but dies the moment you are inside RDP, check this policy before anything else. The ADMX comes from the Windows 11 22H2 administrative templates or newer, so make sure your Central Store is current too.

On a current Remote Desktop client you opt in on the Local Resources tab by ticking WebAuthn (Windows Hello or security keys). For the full walkthrough of using your key inside the session – including Windows 11 client cross-device passkey support – see the companion post: Using Your FIDO2 Key From Inside the RDP Session.

Picking the right path

• “I want to log into the server with my key.” → Scenario 1. Find your join state in the table. For a real Windows Server 2022, that almost always means hybrid + cloud Kerberos trust.
• “I want to use my key for a website/app running on the server.” → Scenario 2. Confirm “Do not allow WebAuthn redirection” is not Enabled, and you are done.
• “We are on-prem only and want passwordless RDP.” → It is not native FIDO2. Either key-as-smart-card via AD CS, or move to hybrid.

Wrap-up

The reason “enable FIDO2 over RDP” has no single answer is that the key is an Entra credential and your server probably is not pure-cloud. Sort out the join state first, then the rest follows: Entra-joined is nearly free, hybrid needs cloud Kerberos trust, and on-prem-only means smart-card PKI or a hybrid move. And if it is really just an in-session web app you are after, the whole thing collapses to one Group Policy that your hardening baseline may have already turned off.