What is passwordless login? Methods, trade-offs, and recovery

Start by naming the actual authenticator

Passwordless is a category, not a protocol. A service can remove the password box while using very different evidence underneath. A passkey proves possession of a private key scoped to the service’s web identity. A magic link proves access to a delivered bearer link. A one-time code proves access to a delivery channel or authenticator. A managed workforce credential may combine a device certificate, local unlock, and organization policy.

The distinction matters because an attacker’s job changes with each method. A fake site cannot obtain a valid passkey signature for the real domain, but it may persuade someone to forward an emailed link or enter a one-time code. Ask what the browser, device, and service verify—not only whether a password disappears.

Passkeys are a passwordless method with domain binding

FIDO describes passkeys as credentials based on cryptographic key pairs. The service stores a public key; a passkey provider or authenticator protects the private key. During sign-in, the browser and authenticator bind the proof to the relying party. The W3C WebAuthn specification describes consumer use cases in which a device provides phishing-resistant sign-in with multi-device credentials.

A fingerprint, face scan, or device PIN commonly authorizes local use of the passkey. The biometric is not sent to the website as the credential. A passkey may sync through a provider or remain bound to a device or security key. Read what a passkey is and compare passkey portability before assuming a credential will follow every device change.

Magic links move trust into the inbox

A magic link is usually a time-limited URL sent to an email address. Opening it proves possession of the link and may complete sign-in without a password. This can reduce password reuse and guessing, but it makes email account security, link handling, device handoff, and expiration central to the login.

Treat the link as a temporary secret. Do not forward it, paste it into support chat, or open it after an unsolicited sign-in request. Check that you initiated the request and that the message’s destination belongs to the service. If a phone opens the link while a desktop initiated the session, read the confirmation carefully; services handle cross-device binding differently. This guide does not label magic links phishing-resistant.

One-time codes are not automatically strong passwordless authentication

A service may send an email or SMS code instead of asking for a password. The code is temporary, but a fake site can ask for it and relay it to the real service. NIST’s current authentication guidance says out-of-band authentication is not phishing-resistant. A code can still be useful, especially compared with a reused password, but the delivery account or phone number becomes part of the attack surface.

Never read a live code to a caller, send it in a support ticket, or approve a prompt you did not start. If a message says the code is needed to cancel fraud, end the conversation and open the official service yourself. The code belongs only in the sign-in flow you initiated.

Passwordless and 2FA answer different questions

Passwordless asks whether the login requires a reusable password. Two-factor authentication asks whether the proof spans two factor categories or a multifactor authenticator. A flow can be passwordless and single-factor, passwordless and multifactor, or password-based with a second factor. Product labels do not settle the technical question.

For example, a FIDO authenticator unlocked by a local activation factor can provide phishing-resistant cryptographic authentication and may meet a service’s multifactor policy. An emailed link may be passwordless but rely only on control of the inbox. Review two-factor versus two-step verification and what a two-factor authentication method means for the factor distinction.

Recovery can quietly reintroduce the weakest path

A strong daily sign-in is only part of account security. If losing one phone falls back to an emailed link, SMS code, support call, or old password, that recovery route may be easier to attack than the passkey. NIST treats account recovery as a separate process and describes saved codes, issued codes, recovery contacts, and repeated identity proofing as distinct classes.

Before removing a password, register more than one supported authenticator when possible. Store recovery codes offline, keep recovery contacts current, and test another device without deleting the known-good credential. Record which provider syncs a passkey and what protects that provider account. Do not discover the model during an emergency.

Use a practical comparison, not a “passwordless equals safe” slogan

The strongest practical choice depends on the service, threat model, devices, and recovery needs. Prefer a domain-bound cryptographic method when available, but do not delete a working recovery route until backups are tested. A method that cannot be recovered responsibly may create availability risk even when its normal authentication is strong.

Checklist before enabling a passwordless method

1. Open the service from a trusted bookmark and verify the registered domain.
2. Identify whether the option is a passkey, link, code, device approval, or another credential.
3. Confirm what the browser or device verifies and whether the method resists relay phishing.
4. Register a second supported authenticator or create the service’s recovery material.
5. Store recovery codes away from the device they recover.
6. Test a fresh session and a second device before removing a password or old factor.
7. Review sessions, connected apps, and recovery contacts after the change.

Continue safely

Related sign-in guides

• Five9 login and identity-provider routesA separate route and evidence boundary.
• Find your employer’s Workday sign-inA separate route and evidence boundary.
• DoorDash customer, Dasher, and merchant sign-inA separate route and evidence boundary.