Category: FIDO & Passkeys

Roaming Authenticator

Also known as: Cross-Platform Authenticator

Simply put

A roaming authenticator is a portable, external security device, such as a USB security key, that you can move between and use with multiple devices to prove your identity. Unlike an authenticator built into a single phone or laptop, it is removable and works across different platforms. It is often used as a strong login method or as a backup in case a device-bound authenticator is lost or stolen.

Formal definition

In the WebAuthn/FIDO2 model, a roaming (cross-platform) authenticator is an external, removable authenticator that can be used with more than one client device, communicating with the host typically over transports such as USB, NFC, or BLE via CTAP. It is distinguished from a platform (bound) authenticator, which is embedded in a single device. A roaming authenticator manages public key credentials and, during a WebAuthn ceremony, produces an assertion signed with the private key corresponding to the credential registered with the relying party; examples include hardware security keys such as a YubiKey, as well as earlier U2F/UAF devices. Because it is portable across devices, it is commonly deployed both as a primary authenticator and as a means of storing backup credentials. The specific transports, CTAP version, and credential capabilities (for example resident/discoverable credential support) depend on the device and deployment; those details are out of scope for this definition.

Why it matters

Roaming authenticators address a core weakness of many authentication schemes: dependence on a single device. Because a platform authenticator is embedded in one phone or laptop, losing or damaging that device can lock a user out of accounts or force a fallback to weaker recovery methods. A roaming authenticator, being portable and usable across multiple client devices, provides both a phishing-resistant primary login method based on public key cryptography and a practical way to store backup credentials in case a platform authenticator is lost or stolen.

For organizations deploying FIDO2/WebAuthn, roaming authenticators such as hardware security keys support the goal of strong, phishing-resistant authentication because the private key never leaves the device and assertions are cryptographically bound to the relying party. This makes them attractive for high-assurance use cases and for populations that move between shared or multiple workstations. Their cross-platform nature means the same physical key can serve as an authentication factor across desktops, laptops, and mobile devices that support the relevant transports.

The trade-offs are largely operational. A physical device can itself be lost, which is why many deployments issue more than one key per user or pair a roaming authenticator with a platform authenticator. Actual behavior, including supported transports, CTAP version, and whether discoverable (resident) credentials are available, depends on the specific device and deployment, so architects should validate capabilities against their requirements rather than assume uniform support.

Who it's relevant to

IAM engineers and security architects

Teams designing WebAuthn/FIDO2 authentication flows need to decide when to require or offer roaming authenticators versus platform authenticators. Because roaming authenticators work across multiple devices and support phishing-resistant assertions, they are commonly deployed as primary login methods for high-assurance scenarios. Architects should confirm the transports (USB, NFC, BLE), CTAP version, and credential capabilities each device supports, since these vary by hardware and deployment.

System administrators and help desk teams

Administrators managing enrollment and account recovery benefit from roaming authenticators as a way to store backup credentials in case a user's platform authenticator is lost or stolen. Because the physical key itself can also be lost, many deployments issue multiple keys per user, which affects provisioning, inventory, and recovery procedures.

End users on shared or multiple devices

Users who move between different workstations, laptops, and mobile devices can use a single removable key across those platforms, rather than relying on an authenticator bound to one device. This portability is a primary reason roaming authenticators are also referred to as cross-platform authenticators.

Inside Roaming Authenticator

Cross-platform authenticator

A roaming authenticator is a FIDO2/WebAuthn authenticator that is physically separate from the client device and can be moved between and used across multiple devices, as opposed to a platform authenticator that is bound to a single device.

External form factors

Typically implemented as external hardware such as USB security keys, or devices connecting over NFC or Bluetooth (BLE), depending on the authenticator and client transport support.

Credential storage

Holds cryptographic key material used in WebAuthn ceremonies. Depending on configuration, it may store either non-resident (server-side) credentials or resident/discoverable credentials that enable passkey-style usernameless flows.

Possession factor with inherence gating

Functions as a possession factor (something you have). Many roaming authenticators add a local user verification gesture such as a PIN (knowledge) or biometric (inherence) performed on the authenticator itself, though user verification support varies by device.

Transport binding

Communicates with the client platform over transports such as USB, NFC, or BLE, which the WebAuthn client and browser must support for the authenticator to be usable.

Role in authentication

Participates in the WebAuthn authentication (and registration) ceremony to prove possession of a private key; it is an authentication mechanism and does not by itself determine authorization.

Common questions

Answers to the questions practitioners most commonly ask about Roaming Authenticator.

Is a roaming authenticator the same thing as a passkey?

No. A roaming authenticator is a category of FIDO2/WebAuthn authenticator that is external and portable across devices, typically connecting via USB, NFC, or Bluetooth. A passkey is a term for a FIDO credential, and passkeys can reside on either roaming authenticators or platform authenticators. Treating the two as synonyms conflates the credential (passkey) with the hardware or software that holds and exercises it (the authenticator). Note that passkey terminology and its exact boundaries continue to vary somewhat across vendors and documentation.

Does using a roaming authenticator mean my sign-in is inherently multi-factor?

Not by itself. A roaming authenticator establishes a possession factor. Whether the overall ceremony is multi-factor depends on configuration and the specific WebAuthn request. If user verification is required and the authenticator enforces it via a PIN or biometric, the ceremony can combine possession with a knowledge or inherence factor. If only user presence (for example a touch) is required, the interaction typically remains single-factor from the possession category. The relying party's policy and the authenticator's capabilities determine the outcome.

How does a relying party require or prefer a roaming authenticator during registration?

In WebAuthn, the relying party expresses this through the authenticatorSelection criteria in the credential creation options, notably the authenticatorAttachment value. Setting it to cross-platform typically signals a preference for roaming authenticators, while platform signals a device-bound platform authenticator. Depending on browser and platform behavior, these are preferences or constraints rather than absolute guarantees, so relying parties should validate the resulting attestation and attachment where that information is available and relevant to policy.

How should we handle user verification settings for roaming authenticators?

User verification is controlled through the userVerification parameter, which can typically be set to required, preferred, or discouraged in the WebAuthn request. Setting it to required prompts the authenticator to verify the user via PIN or biometric where supported, which is what turns a possession-only interaction into a multi-factor one. The effective behavior depends on the authenticator's capabilities and configuration, so relying parties that depend on user verification for assurance should confirm it was actually performed by inspecting the authenticator data flags rather than assuming it.

What happens if a user loses their roaming authenticator, and how do we plan for it?

Because a roaming authenticator is portable hardware, loss or damage can lock a user out of accounts bound to credentials on that device. In most deployments this is mitigated by registering more than one authenticator per user, maintaining backup or recovery methods, and defining an account recovery process governed by identity governance and administration procedures. Recovery flow design is a policy and lifecycle concern and sits largely outside the WebAuthn protocol itself, so the strength of recovery should match the assurance level of the primary authenticator to avoid weakening it.

How do we distinguish a resident (discoverable) credential from a non-discoverable one on a roaming authenticator?

Discoverable credentials, sometimes called resident keys, store enough state on the authenticator to enable usernameless flows where the authenticator can present available credentials without the relying party first supplying an identifier. Non-discoverable credentials rely on the relying party sending credential identifiers in the request. In WebAuthn this is influenced by the residentKey and requireResidentKey settings during registration. Support and storage capacity for discoverable credentials vary by authenticator model, so relying parties should account for those limits when designing usernameless experiences.

Common misconceptions

A roaming authenticator and a passkey are the same thing.

They are related but distinct. A passkey is a WebAuthn (typically discoverable) credential, while a roaming authenticator is a cross-device authenticator form factor that can store and exercise such credentials. A roaming authenticator may hold passkeys, but the terms are not interchangeable, and passkeys can also reside on platform authenticators.

Using a roaming authenticator automatically provides multi-factor authentication.

The authenticator itself is a possession factor. Whether the ceremony constitutes MFA depends on whether user verification (such as a PIN or biometric) is performed and required by the relying party's configuration; a possession-only assertion without user verification is a single factor.

A roaming authenticator can be used on any device without further consideration.

Usability depends on the client platform and browser supporting the relevant transport (USB, NFC, or BLE) and the WebAuthn API. If the required transport or user verification method is not supported, the authenticator may not work in that context.

Best practices

Require user verification (PIN or biometric) at the relying party when a roaming authenticator is intended to satisfy multi-factor authentication, rather than assuming possession alone is sufficient.

Decide deliberately between resident/discoverable credentials and non-resident credentials based on whether usernameless or passkey-style flows are needed and on the authenticator's storage limits.

Verify that target client platforms, browsers, and transports (USB, NFC, BLE) support the roaming authenticators you plan to issue before rolling them out to users.

Register at least one backup authenticator per user so account access is not lost if a single roaming authenticator is misplaced or damaged.

Define a clear lifecycle process for enrolling, rotating, and revoking roaming authenticators, and keep this governance workflow distinct from runtime authentication enforcement.

Where supported, evaluate authenticator attestation during registration to confirm devices meet your assurance requirements, noting that attestation availability and policy vary by deployment.