What causes "device cannot fulfill platform attachment requirement" in gravitational/teleport?

Use the device's built-in platform authenticator (Touch ID/Windows Hello) for this flow.

device cannot fulfill platform attachment requirement

Error message

device cannot fulfill platform attachment requirement

What it means

errNoPlatform is a user-friendly device filter error returned when a ceremony requires platform attachment (plat=true, e.g. Touch ID/passkeys attached to the device) but the connected FIDO2 device is a roaming authenticator (USB/NFC key), not a platform device.

Source

Thrown at lib/auth/webauthncli/fido2.go:68

	// Timeout for blocking operations.
	// Functions fail with FIDO_ERR_RX on timeout.
	fido2DeviceTimeout = 30 * time.Second

	// Operation retry interval.
	// Keep it less frequent than 5Hz / 0.2s.
	fido2RetryInterval = 500 * time.Millisecond

	// Timeout for touch.Status operations.
	// Keep it less frequent than 5Hz / 0.2s.
	fido2TouchMaxWait = 200 * time.Millisecond
)

// User-friendly device filter errors.
var (
	errHasExcludedCredential = errors.New("device already holds a registered credential")
	errNoPasswordless        = errors.New("device not registered for passwordless")
	errNoPlatform            = errors.New("device cannot fulfill platform attachment requirement")
	errNoRK                  = errors.New("device lacks resident key capabilities")
	errNoUV                  = errors.New("device lacks PIN or user verification capabilities necessary to support passwordless")
	errPasswordlessU2F       = errors.New("U2F devices cannot do passwordless")
)

// TouchRequest abstracts *libfido2.TouchRequest for testing.
type TouchRequest interface {
	Status(timeout time.Duration) (touched bool, err error)
	Stop() error
}

// FIDODevice abstracts *libfido2.Device for testing.
type FIDODevice interface {
	// Info mirrors libfido2.Device.Info.
	Info() (*libfido2.DeviceInfo, error)

	// IsFIDO2 mirrors libfido2.Device.IsFIDO2.
	IsFIDO2() (bool, error)

View on GitHub (pinned to 1283425b60)

Solutions

Use the device's built-in platform authenticator (Touch ID/Windows Hello) for this flow.
If a roaming key should be accepted, relax the authenticator attachment requirement (attachment auto/plat=false) in the WebAuthn config.
Check teleport's WebAuthn configuration for attachment requirements and adjust them to your hardware.

Example fix

// before (server credential options)
"authenticatorSelection": {"authenticatorAttachment": "platform"}
// after
"authenticatorSelection": {"authenticatorAttachment": null} // allow cross-platform keys

Defensive patterns

Strategy: validation

Validate before calling

// confirm attachment requirements match hardware
// plat requirement true? use built-in Touch ID / Windows Hello instead of a USB key

Try / catch

err := login(ctx)
if err != nil && strings.Contains(err.Error(), "platform attachment requirement") {
	// retry with platform authenticator or relax attachment config
}

Prevention

Only require platform attachment when targeting laptops/phones with built-in authenticators.
Prefer authenticatorAttachment auto when hardware keys are also in use.
Document which MFA devices satisfy which WebAuthn policies.

When it happens

Trigger: fido2.go:519 — plat && !info.plat during device filtering in registration/login that requests authenticatorAttachment=platform.

Common situations: Server-side config requires platform authenticator (e.g. for attestation or passkey policy) while the user uses a USB YubiKey; mixing platform-only policies with hardware keys.

Related errors

AI-assisted analysis of gravitational/teleport@1283425b60 (2026-09-02). Data as JSON: /api/errors/a3e877d953c5c5a5. Report an issue: GitHub.