USB token forwarding is a virtualisation or remote access feature that redirects a physical USB device, such as a security key, dongle or smart card reader, from a local machine to a remote session or virtual machine. It lets the remote system use the device as if it were directly attached, which can extend device-dependent authentication or licensing across a network connection.
What USB token forwarding actually changes
usb token forwarding makes a physical authentication or licensing device available to a remote desktop session or virtual machine as if it were locally attached. The security significance is that the remote environment can consume the token’s trust, not just display its output.
That distinction matters because the redirected device is often treated by the remote session as a real local authenticator. If the remote host is compromised, the attacker may gain the same practical access as the user who plugged the device in.
Where USB token forwarding is used
Organisations usually deploy this feature when a workflow depends on a hardware-bound credential, such as a smart card, USB security key or dongle, but the work must happen inside a VDI, published app or remote workstation. It is common in environments that still rely on device-bound signing, legacy licensing, or strong authentication that was designed for local endpoints.
When used well, it preserves business continuity without forcing users to duplicate credentials or move to weaker alternatives. When used poorly, it creates a hidden dependency on both the endpoint and the remote session, because either side can become the point of failure or compromise.
Security implications of device redirection
The main security question is whether the redirected token is being used as a controlled trust anchor or as a pass-through to a less trusted system. Hardware-backed credentials are meant to narrow exposure, but forwarding can widen the blast radius if the remote host, broker, or session layer is not strongly protected.
Forwarding also blurs the boundary between local presence and remote use. A user may think the token is only available in one place, while in practice the remote session can prompt for PIN entry, sign transactions, or complete authentication flows on the user’s behalf. For a broader view of device-bound credential risk, Ultimate Guide to NHIs covers how certificates, tokens and workload credentials function as access-bearing material, while Guide to the Secret Sprawl Challenge explains why exposed credentials become a durable security problem.
Operational controls and lifecycle concerns
USB token forwarding should be treated as an access-path decision, not just a convenience setting. The key questions are who is allowed to redirect the device, whether the session host can observe or reuse the credential, and how the organisation revokes or replaces the token if the remote environment is suspected to be unsafe.
Lifecycle discipline matters because a forwarded token can keep working long after the original security assumptions have changed. If a device is lost, cloned, shared, or used from an unmanaged session, the organisation needs a clear path to invalidate the credential, not just close the remote connection. USB PKI tokens and eTokens guide is the most direct companion resource for token PIN policy, token lifecycle and hardware-backed signing use cases, while Guide to NHI Rotation Challenges is useful when the forwarded device is part of a larger credential rotation problem.
Risk and Threat Considerations
USB token forwarding can turn a strong local authenticator into a remotely reachable attack surface. If the endpoint, broker, or virtual session is compromised, an attacker may use the redirected device to authenticate, sign, or license actions without needing to steal the token itself.
Failure mechanism: The remote session inherits trust in the forwarded device, so compromise of the session layer can convert a local hardware control into a reusable remote access path, especially when the device is used for authentication or signing.
Impact: Attackers can bypass the intended locality of the token, persist through active sessions, abuse signing or login rights, and extend a single compromise into broader identity or licensing abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | USB token forwarding depends on control of token lifecycle and use. |
| IA-2 — Identification and Authentication (Organizational Users) | Forwarded USB tokens often support user authentication into remote sessions. | |
| AC-17 — Remote Access | The feature exists inside remote-access pathways and their control boundaries. | |
| Recommendation — Manage token issuance, protection, rotation, and revocation to reduce misuse of forwarded authenticators. Require strong user authentication before permitting device redirection into remote sessions. Restrict remote access pathways that can present forwarded authenticators to less trusted hosts. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Forwarded tokens create access pathways that need explicit permission and review. |
| Recommendation — Limit and review who may use redirected devices in remote access environments. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | USB token forwarding changes trust boundaries and demands continuous verification. |
| Recommendation — Treat redirected peripherals as untrusted inputs and verify every remote session before granting access. | ||
Practitioner Guidance
Why practitioners should care: USB token forwarding is only safe when the remote access stack is treated as part of the trusted path. If the remote host is less trusted than the endpoint, the feature can weaken the very control it was meant to preserve.
What to watch for: Pay attention to shared workstations, unmanaged VDI images, weak session isolation, and any setup where users can forward high-value tokens into environments they do not fully control. Those are the conditions where the device becomes a bearer of unintended authority rather than a simple peripheral.
Related resources from NHI Mgmt Group
- How does delegated credentialing differ from forwarding a user token?
- What is the difference between token passthrough and token forwarding in an MCP gateway?
- What breaks when delegation chains rely on token forwarding instead of explicit authorization?
- Why does forwarding a bearer token unchanged create both a security risk and an audit problem in agent workflows?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org