[FEATURE] Trusted devices: support multiple concurrently enrolled FIDO2 authenticators (currently single-enrollment, replace-only)

[DGTJBarker]

Preflight

• Searched existing issues. [BUG] After login I get a prompt whether I want to setup a passkey - when I click it, Claude Desktop reliably crashes #81550 covers the enrollment prompt crashing on click; no existing issue covers multiple authenticators.
• As of 2026-07-28, "passkey" returns zero results on support.claude.com and the feature is absent from release notes through July 24. The feature's UI name appears to be Trusted devices (claude.ai/settings/account#trusted-devices).
• Current behavior below was confirmed by Fin (Anthropic's support AI agent) on 2026-07-28; a parallel escalation to a human agent has been requested through support.

Summary

Claude Desktop for Windows (MSIX) recently began offering passkey enrollment at sign-in. I enrolled successfully using a hardware FIDO2 security key (resident/discoverable credential, verified present on the key).

Per Fin, enrollment is single-device / replace-only: to use a second authenticator, I must remove the currently trusted device at Settings > Account > Trusted devices and re-enroll with the other key at next sign-in. Between full sign-ins, biometric step-up (Windows Hello / Face ID / Touch ID) refreshes the session.

This makes a backup hardware key impossible in practice. A backup that must be pre-activated by disabling the primary is not a backup.

Request

1. Support multiple concurrently enrolled authenticators per account (primary + backup/travel key) — standard practice for hardware-key users and supported by every major relying party (Google, GitHub, Microsoft).
2. Provide a credential management UI: list, rename, and revoke individual enrolled authenticators, not only whole-device removal.
3. Publish documentation. The login article (13189465) still describes only Google and email-link sign-in; "Trusted devices" and the passkey prompt are undocumented.

Additional pain point: orphaned resident credentials

Because hardware-key enrollment writes a discoverable credential to the key itself, the remove-and-re-enroll swap orphans a resident credential on the removed key each cycle. It fails at sign-in and occupies one of the key's limited discoverable-credential slots until manually deleted via vendor tooling. Replace-only semantics multiply these over time.

Why it matters

• A single enrolled authenticator with no backup path creates lockout risk; the email magic link becomes the sole fallback.
• Hardware-key users specifically adopt the two-key pattern to survive loss, damage, and travel.
• Shipping enrollment ahead of multi-credential support, management UI, and docs leaves early adopters unable to follow FIDO2 best practice.

Environment

• Claude Desktop for Windows (MSIX), version: 1.24012.9.0
• Windows 11 Pro, version 25H2 (OS build 26200.8875)
• Authenticator: external hardware FIDO2 security key, USB

Related

• [BUG] After login I get a prompt whether I want to setup a passkey - when I click it, Claude Desktop reliably crashes #81550 — passkey setup prompt after login reliably crashes Claude Desktop (same feature surface, filed 2026-07-27)

[vbiroshak]

Adding a macOS dimension to this: the enrollment prompt is also effectively unusable for anyone whose credential store is a third party password manager rather than the platform one.

On macOS the desktop app runs auth through an in-app WebKit sheet (ASWebAuthenticationSession, see #61482), where no browser extension exists. A WebAuthn create request from that surface can only be answered by Apple Passwords, since macOS has no system level passkey provider mechanism for third party managers the way iOS does. There is no way to route the passkey to 1Password, Bitwarden, or any other manager at that dialog, and since enrollment only happens at sign in, there is no browser based enrollment path where an extension could intercept.

So on macOS the current choice is: put a credential for this account in a store you do not otherwise use, or keep declining the prompt forever. I want this feature, but I want it usable with my own password manager.

Concrete addition to the requests above: offer enrollment from the account settings page in a regular browser (not only at sign in inside the app sheet), so password manager extensions can participate. That single change would make the feature usable for third party manager users on macOS without Apple having to change anything.

---

Investigation and write-up by Claude (Fable 5, in Claude Code), at the user's direction.

[mccarthysean]

+1 to this. Single-enrollment, replace-only is a real blocker for anyone following normal FIDO2 practice of keeping a backup authenticator — the whole point of a backup key is that it's enrolled before you lose the primary, not after.

A related angle beyond backup keys: multiple concurrent enrollments are also what would make passkeys usable across surfaces at all. I use Claude on five clients — mobile app, Claude Code, web, Claude for Excel, and Claude for Chrome — spread across a phone and a desktop. With replace-only enrollment those devices can never all be enrolled at once, so this can't become the way I sign in. It stays a per-device trust step layered on top of a magic-link login I still have to complete by email.

+1 to the documentation request as well. Trusted Devices isn't mentioned in the Help Center at all — the "Log in to your Claude account" article still lists only Google and email as sign-in options.

I've filed #84862 for the broader "passkey as a sign-in method" request, which depends on this one being solved first.