After Passkeys, Attackers Click “Can’t Sign In?”

Server-side WebAuthn verification in Python, the two flags that show who is one lost phone from lockout, and a recovery flow that holds.

Add passkeys to your sign-in page, and that page stops being phishable: the browser won’t produce a signature for a look-alike domain.

Your app still has a “Can’t sign in?” link, though. If it emails a code that lets someone enroll a new passkey, whoever holds that inbox gets in, and the account is exactly as strong as that link.

The mental model most of us start with

The common picture: a passkey replaces the password. The server stores a public key instead of a hash, the private key stays on the device, and phishing stops working because every signature is bound to your domain.

That’s all true, which is why the picture sticks. Tutorials walk the happy path, register and sign in, and treat recovery as “fall back to email.”

The picture also blurs two words. “Passwordless” is an experience, and magic links and SMS codes qualify even though both can be phished. A passkey is a specific object: a discoverable WebAuthn credential.