Why a hardware key will not work down a remote desktop tunnel
An operative controlling a laptop remotely can move the mouse, type, read the screen and run anything on it. The one thing they cannot do is press a button on a security key plugged into a desk they are not sitting at.
Can a security key be used over a remote desktop session?
Not unless device redirection is enabled. RDP, AnyDesk and TeamViewer forward keyboard, mouse and screen. They cannot synthesise a capacitive touch on a key attached to the far machine, because the authenticator performs the presence check itself and signs the result.
- User presence in FIDO2 requires a physical interaction with the authenticator itself, which remote protocols cannot synthesise.
- Device redirection features can forward a USB authenticator across a session, which reverses the property — this must be disabled.
- The control's value depends on the key being physically where the legitimate person is, and on redirection being off.
Part of Remote workforce identity
What remote access can and cannot forward
| Capability | Forwardable over a remote session |
|---|---|
| Keyboard input | Yes |
| Mouse movement and clicks | Yes |
| Screen contents | Yes |
| Clipboard | Yes, if enabled |
| File transfer | Yes, if enabled |
| Audio | Yes, if enabled |
| A capacitive touch on a security key | No |
| A fingerprint on the local sensor | No |
The distinction is between input the operating system receives as events and interaction with a device that verifies presence internally. The authenticator's user-presence check is performed by the authenticator, not reported to it.
What the flags mean
An authenticator sets two flags in its response.
- User present — someone physically interacted with the authenticator, typically a touch
- User verified — the authenticator additionally verified the user with a biometric or PIN
Both are asserted by the authenticator and covered by its signature. Software on the host cannot set them, because the host does not produce the signature.
The redirection problem
This is where the property is commonly lost, and it is worth being blunt about it.
Remote desktop implementations support device redirection: a USB device attached to the client machine is presented to the remote session as though attached there. Where this includes authenticators, a key held by the remote operator satisfies the presence check for the session.
# Without redirection
operative's machine ──RDP─→ corporate laptop
└─ security key here
→ presence check requires someone at the laptop. BLOCKED
# With USB redirection enabled
operative's machine ──RDP─→ corporate laptop
└─ security key here (redirected)
→ presence check satisfied by the operative. BYPASSEDSo the control depends on a configuration setting, and the default in some environments permits redirection because it is a legitimate convenience for travelling staff.
What to configure
- Disable USB and smart card redirection for remote sessions to corporate endpoints. This is the single decisive setting.
- Prefer platform authenticators for the sensitive checks — a fingerprint sensor built into the laptop cannot be redirected.
- Detect remote session presence and require verification from a separate device, such as the employee's phone, when a session is remote.
- Audit third-party remote tools, which have their own redirection features and are often installed outside IT's inventory.
The fourth is the practical gap. Corporate remote desktop policy is usually managed; consumer remote access tools installed by a user are not, and they are what appears in these arrangements.
The legitimate remote access case
Plenty of employees legitimately connect to a machine remotely — a workstation from home, a jump host, a lab system. A control that blocks all of that is not deployable.
The workable arrangement: the verification comes from a device the employee holds in their hand, not from the machine they are controlling. Their phone, wherever they are, produces the signature. The remote session is irrelevant because the credential was never on the remote machine.
This also happens to be more robust than relying on redirection settings, because it does not depend on a configuration that someone might change.
Being honest about the limits
If the facilitator is willing to press the key when asked, the control is defeated. That is collusion, and it is a different problem — though it does change the arrangement's economics, since the facilitator must now be available and involved rather than passively hosting a laptop.
The control also only applies where it is required. An organisation that requires verification at login and nowhere else has gained little, because the remote session continues afterwards.
The setting that decides it
Remote desktop implementations support device redirection, presenting a USB device attached to the client as though attached to the session. Where that includes authenticators, a key held by the remote operator satisfies the presence check — so the control depends on a configuration setting, and the default in some environments permits redirection because it is a genuine convenience for travelling staff.
| Setting | Effect |
|---|---|
| USB / smart card redirection disabled | Presence check requires someone at the endpoint |
| Redirection enabled | The remote operator's key satisfies it — control bypassed |
| Platform authenticator used instead | Built-in sensor cannot be redirected |
| Consumer remote tools installed outside IT inventory | Their own redirection features, unmanaged |
Objections and honest limits
“We block remote access entirely.” Few organisations can. Legitimate remote work to a workstation, a jump host or a lab system is normal, and a control that blocks all of it is not deployable.
“So a willing facilitator defeats it.” Yes. That is collusion, and it is a different problem. It does change the economics: the facilitator must be actively available at each challenge rather than passively hosting a laptop.
Configuring this correctly
- Disable USB and smart card redirection for remote sessions. The single decisive setting.
- Prefer platform authenticators for sensitive checks. A built-in sensor cannot be redirected.
- Verify from a device in the person's hand. Their phone, wherever they are — more robust than relying on a configuration someone might change.
- Audit consumer remote tools. Corporate RDP policy is managed; a user-installed remote tool is not, and that is what appears in facilitator arrangements.
Terms used here
- User presence
- A physical interaction with the authenticator itself, asserted in a flag the authenticator signs. Host software cannot set it.
- Device redirection
- Presenting a peripheral attached to the client machine as though attached to the remote session.
- Jump host
- An intermediate system used to reach a protected environment. Legitimate, common, and a place remote-session assumptions quietly break.
Frequently asked questions
Why can't a touch be forwarded? The authenticator performs the presence check internally and signs the result. The host does not produce the signature, so software on it cannot assert the flag.
What breaks this control? USB device redirection in remote sessions, which presents a key attached to the remote operator's machine as though attached locally.
How do legitimate remote workers use this? The credential lives on a device in their hand — typically their phone — not on the machine they are controlling. The remote session becomes irrelevant.
Does this stop a willing facilitator? No. That is collusion. It does change the economics, since the facilitator must be actively available rather than passively hosting a laptop.
Where this fits in Manav
Manav issues the challenge to a credential on the person's own device rather than to the machine they are operating. The remote session becomes irrelevant, and the control no longer depends on a redirection setting staying disabled.