[FEATURE] Passkey (WebAuthn) sign-in for Claude accounts, across every surface

Please add username+password+2FA methods for login as well. I don't like the fact that email is used for account authentication. I also do not want to tie in my website logins with Google/Apple/Microsoft/Meta/ et al for security reasons.

I'm honestly surprised that this hasn't been suggested here before (or in other Anthropic repos). I see #76624 was closed for being not strictly related to Claude-Code. Hoping this doesn't end up the same way!

Magic Link or third-party being the only sign-in methods is pretty bad to be honest.

omg please

+1, though for a reason the original post doesn't cover: for me this is about control, not speed.

Both existing paths put a dependency outside my control. "Continue with Google" creates an account relationship I've been burned by before with other providers — each one handles unlinking differently, and working out how (or whether) you can untangle it later is its own project. The magic link makes sign-in dependent on mail delivery latency, which is fine on a good day and unusable on a bad one. A passkey has neither property: it's a credential on my device, with no third party in the path.

The security-cost argument also runs the other way from how it's usually framed. Presumably part of why Claude accounts have no password is that passwords mean a shared secret at rest, brute-force defense, and a reset flow to build and maintain. Passkeys avoid all three. The genuinely hard part of going passwordless is recovery when someone loses every authenticator — and that's already solved here. Keep the magic link exactly as it is and make it the recovery path rather than the primary one. Nothing new to build.

Separately, and possibly worth its own issue: an authenticated claude.ai browser session doesn't satisfy Claude Code's authorize flow. I was already signed in to claude.ai in the browser, ran /login in Claude Code, and was still sent through the full email-link flow. A second /login shortly afterwards was a one-click approve, and a first-time /login on a different machine against that same browser session was also a one-click approve. So the claude.ai web session and whatever the authorize endpoint accepts are tracked on separate lifetimes. Making /login honour an existing claude.ai session would remove most of these interactions outright, independent of passkeys.

Todays Microsoft outlook outage proves how important that feature is.
Considering the 220 Million DAUs (https://sqmagazine.co.uk/microsoft-365-statistics/) who potentially have been unable to log in and do their Claude work for more that two hours now, demonstrates clearly, that this feature is not "nice to have".
It is an essential pillar of resilience, infrastructure independence, and securing service availabilty.

Coming at this from the account-security angle rather than the magic-link-latency angle in the original post - I think this deserves priority beyond convenience.

As it stands, email magic link (and OAuth sign-in) is the sole authentication factor for a Claude account — there's no password or independent second factor underneath it that also has to be defeated. That makes account security entirely dependent on the security of whatever mail delivery chain a given user happens to have, which isn't something Anthropic (or the user, in many cases) can fully control or verify:

• IMAP/POP still commonly negotiate TLS opportunistically via STARTTLS, and downgrade/stripping of that negotiation is a documented, demonstrated attack class (see the STARTTLS command-injection disclosures across multiple major MTAs/clients, ~2021), not theoretical.

• Where 2FA is enabled on the mail account itself, IMAP/POP/SMTP access is typically gated by a static app-specific password instead — a flat bypass of that 2FA for anyone reading mail through those protocols.

• Server-to-server SMTP transport is opportunistic TLS in most deployments, with many servers falling back to plaintext delivery rather than failing closed.

This puts Claude's login in essentially the same risk category as SMS OTP — an out-of-band channel controlled by a third party, standing in for a factor it doesn't actually cryptographically provide. Notably, Microsoft just removed SMS 2FA for personal accounts entirely in 2026, calling it "a leading source of fraud" due to SIM-swapping, and is pushing passkeys as the replacement. Claude's exposure is arguably worse than SMS OTP ever was, since SMS was typically a second factor on top of a password — compromising it alone wasn't sufficient. Here, compromising the one channel is fully sufficient.

Beyond the passkey sign-in requested above, I'd add two asks that close the gap even before passkeys ship:

1. New-session/new-device notifications — an alert (ideally via a channel other than the same email account, e.g. push) whenever a new session is created, so unauthorized access is visible immediately rather than only discoverable by manually checking Settings → Account → Active sessions after the fact.

1. Optional enforcement — once a second factor exists, let security-conscious users (and org admins, extending the infrastructure already built for Trusted Devices in #82095) require it for login, rather than leaving email/OAuth possession sufficient by default.

Related: #12480 requested TOTP-on-magic-link specifically and was closed as not planned — hopefully the broader passkey approach here fares differently, since the underlying problem it was trying to solve is still open.

+1 to all of the above, but especially Bjorn-Jahn's recent post. Magic Link is 1FA masquerading as 2FA.

Some additional dimension requests to FIDO2 sign-in:

• Please allow to enroll sufficiently high number of devices. I would love to do authentication with a Yubi on any of my devices, including with NFC on the mobile. I also want to have backup devices enrolled so when one key breaks or is lost, I have another one already available.
• Allow advanced users to select the desired FIDO2 enforcement level, on a per-enrollment level. It should be possible for a user to choose that for certain FIDO2 credentials, discoverability is sufficient and the per-activation PIN can be skipped. (IOW support the whole gamut of 'discouraged', 'preferred', 'required' for PIN activation.)
• Consider the option to treat device-bound passkeys and separate-physical-hardware-backed keys differently. The security properties of on-device Passkeys are sufficiently different from external FIDO2 devices.

pretty please do this! I don't like having to go to my email each time, it's a super clunky workflow

+1

As stated above, this is not a "nice to have"; It's 2026.

Within the last month the claude desktop app asked me to set up a passkey. I did, a credential was created on my YubiKey, and that option hasn't been presented again. I've looked in all the settings in web and desktop for the option and cannot find it. Maybe they're A/B testing.

Emailed magic-link sign-in is pathetic. Claude Desktop has prompted me to create a passkey, but I have no idea why - I can't log in with it, and I can't actually see it anywhere in my account. Implement full account sign-in via passkey ASAP. I'm sure Claude Code could implement it for you this afternoon.

How is passkey not an option in a supposedly modern platform? The engineering team should be downright embarrassed something so basic isn't available yet. Do better if you want to be taken seriously.

PLEASE. It's also insane that the Claude app now asks me to setup a Passkey then never even uses it for login. Like wtf. The round tripping between 3 apps just to login is a terrible UX. Claude app -> Email app link -> Web Browser -> back to Claude.

I’ll add that for myself that 100% of the time the magic link emails go to my spam folder on Fastmail. I’d tried training them to not be spam, they still go there. I’d much rather have passkeys.

Also the new CVP program requires phishing resistent logins. Presumably this feature is a prerequisite if not using google as an IDP.