Platform vs Roaming Authenticator Trade-offs

Every WebAuthn deployment eventually forces a design decision: do you steer users toward platform authenticators — the biometric sensors and PINs built into their phones and laptops — or roaming authenticators, the removable security keys that plug in or tap over NFC? The choice shapes attestation strategy, recovery UX, assurance level, and the value you pass to authenticatorAttachment. This page is a decision reference grounded in the WebAuthn Level 2 spec and CTAP2. For where this sits in the protocol, start from WebAuthn & FIDO2 Protocol Fundamentals; for how the relying party and authenticator roles are partitioned, see that cluster.

Concept Definition and Spec Grounding

The distinction is defined by authenticatorAttachment (WebAuthn L2 §5.4.5), a value inside authenticatorSelection:

  • platform — the authenticator is bound to the client device and cannot be removed: Touch ID / Face ID via the Secure Enclave, Windows Hello via the TPM, Android via the Titan/StrongBox-backed keystore. These typically produce synced passkeys that propagate across a user’s devices through the OS credential manager.
  • cross-platform (roaming) — the authenticator is a separate, portable device reached over USB, NFC, or BLE: a YubiKey, Feitian key, or a phone acting as a security key over hybrid transport. Its credentials are usually device-bound and non-syncing.

Attachment interacts with the AAGUID (the 16-byte authenticator model identifier in the attestation), the attestation conveyance you request, and whether the credential is discoverable vs server-side. A roaming security key from a known vendor yields a stable, verifiable AAGUID you can check against FIDO MDS3; a synced platform passkey may present an all-zero AAGUID and none attestation.

Architecture and Data Flow

The comparison matrix below is the decision surface — read down the column that matches your assurance and portability needs.

Platform vs roaming authenticator comparison Two-column comparison across attachment, credential portability, attestation, recovery, and assurance level, contrasting platform authenticators with roaming security keys. Platform (synced passkey) Roaming (security key) Attachment platform cross-platform Portability syncs across user devices carried physically AAGUID / attestation often zero AAGUID, none stable AAGUID, packed Recovery on loss cloud restore needs a backup key Phishing resistance high high Best-fit assurance AAL2, consumer AAL3, regulated / device-bound Enrolment friction low (built in) higher (buy + carry)

Implementation Guide

Step 1 — Decide what to request (WebAuthn L2 §5.4.4)

Leave authenticatorAttachment unset to accept both; pin it only when policy demands one kind.

// Accept both platform and roaming — the common consumer default
authenticatorSelection: { residentKey: 'preferred', userVerification: 'preferred' }

// Force a removable security key — high-assurance / regulated workforce
authenticatorSelection: { authenticatorAttachment: 'cross-platform', residentKey: 'required', userVerification: 'required' }

Step 2 — Read the resulting attachment on the server

The response reports which kind actually answered, so you can apply per-attachment policy.

import { verifyRegistrationResponse } from '@simplewebauthn/server';

const { registrationInfo } = await verifyRegistrationResponse({ /* … */ });
const attachment = credential.response.getAuthenticatorAttachment?.(); // 'platform' | 'cross-platform' | null
const aaguid = registrationInfo?.aaguid;                                // 16-byte model id

Step 3 — Apply attestation policy by attachment

Roaming keys justify direct attestation and an AAGUID allowlist; synced platform passkeys usually do not. This ties directly into the attestation conveyance policy selection guide.

if (attachment === 'cross-platform' && !allowlistedAaguids.has(aaguidHex)) {
  throw Object.assign(new Error('Unrecognised security key model'), { status: 403 });
}

Step 4 — Mandate a second authenticator

Whichever kind you favour, require a backup at enrolment so device loss is recoverable — reinforcing credential revocation and account recovery.

Validation Checklist

Error Reference Table

Error / Condition HTTP Status Trigger Diagnostic
ConstraintError (client) — authenticatorAttachment: 'platform' on a device with no platform authenticator Offer roaming/hybrid; relax the pin
Unrecognised AAGUID 403 Roaming key not on allowlist Compare AAGUID hex against MDS3 entries
Zero AAGUID rejected 403 Policy demands attestation from a synced passkey Allow none attestation for platform attachment
No backup credential 409 (policy) Enrolment completed with a single device-bound key Enforce second-authenticator policy
NotSupportedError — Requested attachment/algorithm unavailable Broaden pubKeyCredParams; unset attachment

Platform and Library Notes

@simplewebauthn/server

verifyRegistrationResponse returns aaguid in registrationInfo; credentialDeviceType distinguishes singleDevice (device-bound, typical of roaming keys) from multiDevice (synced platform passkey). Use credentialBackedUp to know whether a passkey can be cloud-restored.

iOS / macOS

Platform passkeys sync via iCloud Keychain and report multiDevice + backedUp. Roaming keys used via NFC/Lightning report cross-platform and singleDevice.

Android

Google Password Manager passkeys sync (multiDevice); a plugged/tapped security key is cross-platform.

Windows Hello

Windows Hello platform credentials are device-bound (singleDevice) and do not sync — a nuance versus Apple/Google. Treat Windows Hello as non-portable in recovery planning.

Pitfalls and Security Hardening

1. Pinning platform and locking out desktop users. Root cause: a hard authenticatorAttachment: 'platform' on machines without a platform authenticator. Mitigation: leave attachment unset or offer hybrid.

2. Assuming platform passkeys are device-bound. Root cause: threat models written for hardware keys. Mitigation: check credentialDeviceType/credentialBackedUp and model cloud-sync exposure.

3. Demanding attestation from synced passkeys. Root cause: requiring direct everywhere. Mitigation: scope attestation verification to roaming/enterprise flows.

4. No recovery for lost roaming keys. Root cause: single hardware key per user. Mitigation: mandate a spare key or recovery method.

5. Ignoring AAGUID drift on firmware updates. Root cause: allowlisting a single AAGUID per model. Mitigation: track MDS3 for model AAGUID changes.

Related