Passwordless authentication: the methods that actually remove the password

Passwordless authentication means signing in without a password as one of the factors. It is not the same as two-factor authentication: adding a one-time code on top of a password is still a password login, just with a second step. The password has to disappear for the login to be passwordless.

There are several ways to do that, and they differ more than vendors admit.

The methods

SMS is the weakest of these: phone numbers get recycled, ported and SIM-swapped, which is why NIST SP 800-63B treats SMS as a restricted authenticator rather than a default. Email links and codes inherit the security of the mailbox.

What "passkey" actually means

A passkey is a WebAuthn credential. The server sends a random challenge; the authenticator signs it with a private key that never leaves the device or the platform's keychain; the server verifies the signature with the registered public key. Because the signature is bound to the site's origin, a lookalike domain cannot reuse it, which is what makes passkeys phishing-resistant in a way codes and links are not.

Passkeys come in two shapes:

• Device-bound, such as a hardware security key or a credential stored only on one phone.
• Synced, such as iCloud Keychain or Google Password Manager, which copy the private key to the user's other devices.

Synced passkeys trade a single-device failure for a dependency on the platform account. NIST's current guidance treats synced authenticators as single-factor unless the sync service also requires a second factor at sign-in.

The hard part is recovery, not login

Every passwordless rollout eventually hits the same question: the user lost the device. The design work is in the answer:

• Enroll at least two authenticators per user, ideally on different devices.
• Keep a recovery path that does not silently fall back to a password reset link, or attackers will use it.
• Give administrators a way to re-enroll a user after an identity check.
• Log every enrollment, removal and recovery event.

A passwordless system with a weak recovery flow is a password system with extra steps.

How to roll it out

1. Add passkeys next to passwords. Do not remove the password on day one. Users enroll a passkey when they next sign in, and the password stays as a fallback for a transition period.
2. Make enrollment visible. Put it in the account settings page and prompt after a successful login, not during a failed one.
3. Measure adoption per group. If a team reaches a high share of passkey logins, you can require passkeys for that group first.
4. Turn off the password for the groups that are ready. Keep the recovery process and support runbook in place.
5. Retire the fallback last. Removing passwords for everyone at once is how projects end up rolling back.

Organizations that need a second factor for compliance can combine a passkey with a PIN or biometric check; the passkey satisfies possession, and the local check satisfies the inherence or knowledge factor inside one authenticator.

Where Casdoor fits

Casdoor supports WebAuthn credentials as a sign-in method, so users can register a passkey and sign in without a password. The same deployment also supports email and SMS verification codes and the usual second factors, which lets you run the transition period (password plus passkey) and the end state (passkey only) from one identity provider. See the WebAuthn documentation.

For the related concepts, see what passkeys are, what MFA covers and MFA vs 2FA.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.