What causes "device lacks resident key capabilities" in gravitational/teleport?

Use a resident-key-capable authenticator (YubiKey 5+, CTAP2.1 device).

device lacks resident key capabilities

Error message

device lacks resident key capabilities

What it means

errNoRK is a user-friendly device filter error: the ceremony requires a resident (discoverable) key — needed for passwordless and usernameless flows — but the device lacks resident key capabilities (info.rk false), typically an older U2F-only or CTAP1 key.

Source

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

	// 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 a resident-key-capable authenticator (YubiKey 5+, CTAP2.1 device).
Update device firmware if the vendor added FIDO2 support (YubiKey 5 firmware updates).
Disable the resident key requirement if discoverable credentials are not strictly needed.

Example fix

// before
"authenticatorSelection": {"requireResidentKey": true}
// after
"authenticatorSelection": {"requireResidentKey": false} // if RK not required

Defensive patterns

Strategy: validation

Validate before calling

// check resident key support before RK-requiring flows
// ykman fido info  -> resident key supported?

Try / catch

err := login(ctx)
if err != nil && strings.Contains(err.Error(), "resident key capabilities") {
	// retry without requireResidentKey or prompt for a different device
}

Prevention

Standardize on CTAP2.1 hardware (YubiKey 5+) where RK is required.
Keep key firmware updated.
Only set requireResidentKey=true for passwordless flows that genuinely need discoverable credentials.

When it happens

Trigger: fido2.go:521 — rrk && !info.rk during device filtering when requireResidentKey is set in the ceremony.

Common situations: YubiKey 4/older keys without CTAP2 resident key support used for passwordless; key firmware too old; passwordless registration attempted with a non-RK key.

Related errors

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