Last verified June 2026 · 8 min read

Magic link vs password vs passkey: what actually happens to conversion

What a magic link is

A magic link is a one-time, time-limited URL emailed to the user at signup or login time. The user enters their email, receives the link, clicks it, and is signed in without ever choosing or typing a password. Slack popularised the pattern at consumer scale. Notion, Medium, and Substack use it as their primary auth method.

The conversion math is simple: no password field means no password-creation friction, no password complexity rejection, no confirm-password field, and no password typo. Every one of those eliminated friction points contributes to the 15-30pp lift.

The decision matrix

Passkeys for 2026

Passkeys (WebAuthn/FIDO2 credentials) are now production-ready. They use public-key cryptography bound to the device and origin, which makes them phishing-resistant by design - a phishing site cannot intercept a passkey because the credential is tied to the origin URL. iCloud Keychain syncs passkeys across Apple devices. Google Password Manager handles Android. 1Password, Bitwarden, and Dashlane all support passkeys as of 2025.

The signup UX for a passkey is typically: enter email, biometric prompt (Face ID, fingerprint, or PIN), done. No password field. On first-time devices, the user is walked through passkey creation. The conversion lift is comparable to magic link without the repeat-login email-check penalty.

The honest complexity caveat: passkey implementation is harder than email+password. Fallback paths (what if the user is on a new device with no passkey?) must be carefully designed. Auth vendors (Auth0, Clerk, Stytch) have abstracted most of this, but it still requires more thought than a standard email+password form.

When password still wins

Shared accounts (a team shares one login), kiosk environments (public terminals without reliable email access), and users with poor email deliverability all benefit from a persistent password. The password is still the most universally accessible credential. Never remove it entirely - always offer it as a fallback even if magic link or passkey is the primary.

The NIST caveat

A common misconception is that NIST recognises email magic links as an AAL1 authenticator. It does not. NIST SP 800-63B-4 (the final 2025 revision) states that "email SHALL NOT be used for out-of-band authentication" because it can be accessed with only a password and intercepted in transit. An emailed magic link is therefore not an approved NIST authenticator at any AAL (email confirmation and recovery codes are a separate, permitted use and are unaffected). Passwords and passkeys are recognised authenticators: a password meets AAL1, passkeys meet AAL2, and AAL3 requires a hardware authenticator with verifier-impersonation resistance. The practical takeaway for product teams: most consumer SaaS is not bound by NIST AALs and can use magic links freely, but if you operate under a NIST-aligned framework (federal systems, or sectors that adopt it), a magic link cannot be your sole login factor - pair it with or graduate users to a password or passkey. See NIST 800-63B for product teams.