Every Passwordless Method, Compared

A customer taps "Email me a sign-in link" on your mobile site. The email opens inside their mail app's built-in browser, which has no session, no cart, and no saved address. They are signed in, technically, in the wrong place. Then they close the tab and try again tomorrow, or not at all.

That customer did not meet a password. They still met friction. "Passwordless" covers methods with very different security and very different experience. A magic link and a passkey both remove the password, but only one stops phishing. This chapter puts every method side by side so you can pick a default and your fallbacks on purpose, not by accident.

Three questions to ask of any method

Before the comparison table, here is the lens I use. Ask three questions of every sign-in method you offer.

1. What does the user have to do? Count the steps, the app switches, and the moments where they can get lost.
2. What can an attacker relay? If a code, link, or approval can be passed through a fake page or a phone call, the method is phishable.
3. What does it cost you? Include per-message fees, support tickets, and the fraud that the method invites.

A method that scores well on the first question and badly on the second is a convenience feature, not a security control. That is fine, as long as you know which one you shipped.

The comparison

Method	User experience	Phishing-resistant	Main risk	Best role
Passkey (synced)	One biometric or PIN unlock, about 2 seconds	Yes	Recovery when every device is lost	Primary sign-in and step-up
Passkey (device-bound or security key)	Tap or touch a specific device	Yes	Lost key without a backup	Admins and high-value accounts
Social or platform sign-in (Apple, Google)	One tap if already signed in	Inherits the provider's security	Dependency on a third party; account-linking errors	Fast signup, especially on mobile
Email magic link	Leave the app, open email, tap link	No	Inbox compromise; link forwarding; app switching friction	Signup and recovery
Email one-time code	Copy a 6-digit code from email	No	Relay by phishing pages	Fallback and recovery
SMS or WhatsApp one-time code	Copy a code from a message	No	SIM swap, SS7 interception, phishing, per-message cost	Last-resort fallback, phone-first markets
Push approval with number matching	Tap and type a number in an app	No	Social engineering; still phishable	Workforce interim control

SMS classification per CISA via SecurityWeek. NIST Rev 4 treats SMS as a restricted authenticator: still allowed, but it requires a risk assessment and an alternative option for users. (Presencis)

Only the first two rows are phishing-resistant. Everything below them is a shared secret or an approval that a convincing fake page can capture and replay within seconds.

What each method is really good for

Passkeys

Passkeys win on both axes at once. Chapter 4 covers how they work and where adoption stands. The point for this chapter is role: a synced passkey is the only method in the table that is both the fastest option and the strongest one. That makes it the right primary method and the right step-up method. Make it the first thing a returning user sees, not a link under the password field.

Device-bound passkeys and hardware security keys belong to a smaller group. Use them for staff with admin rights, for high-value customer accounts that ask for them, and anywhere a regulator expects AAL3 (NIST's highest assurance level, which requires a non-exportable key).

Social and platform sign-in

"Sign in with Apple" and "Sign in with Google" are the fastest path to a new account on mobile. The user is usually already signed in to the provider. Your security then inherits theirs, which is strong for most consumers.

The risk is not the provider. It is your account linking. If someone signs up with Google today and with email next month, you can end up with two accounts for one person. Match on verified email at the provider, ask before merging, and never merge silently on an unverified address.

Email magic links

Magic links feel effortless in a demo. In production they break in three common ways:

• The wrong browser. The link opens in an in-app browser or a different device from the one that asked for it, so the session lands in the wrong place.
• Link scanners. Some corporate mail filters open links to check them. A single-use link can be consumed before the human ever clicks.
• Forwarding. Anyone who holds the email holds the account for as long as the link is valid.

A useful fix is to show a short code alongside the link, so a user on another device can type it instead. I cover the deeper design choices in Mastering Magic Link Security.

Email one-time codes

An email code is the most portable fallback. It works on any device, in any browser, with no app switch beyond reading mail. It is phishable, so treat it as a door for users without passkey support and as a recovery channel, never as step-up for a high-risk action.

SMS and WhatsApp codes

Phone codes are the method users understand best and the one attackers have studied longest. SIM swap and phishing relay are the familiar risks. A newer one hits your budget directly.

SMS pumping fraud uses your phone number field to trigger one-time passcode messages to numbers that fraudsters choose, then takes a share of the revenue from the carrier (Twilio). Twilio's own advice is to disable every country you do not plan to send to and to block suspicious traffic. Any public form that sends a code needs rate limits for this reason alone.

Push approval

Push with number matching is a workforce control. It reduces blind approvals but stays phishable, and Chapter 6 covers the push-bombing pattern it was built to blunt. Consumer brands rarely need it, because the passkey on the same phone does the job better.

A sensible default stack for most consumer brands

1. Primary: passkey, surfaced through autofill on the identifier field.
2. Fast signup: Sign in with Apple and Google, plus a passkey offer right after the first sign-in.
3. Fallback: email one-time code or magic link for users on devices without passkey support.
4. Recovery: two pre-registered methods, never a single SMS number.
5. Retire over time: passwords, then SMS as a primary factor.

Chapter 7 shows how to build the screen that puts this stack in front of users, including the autofill markup.

Which fallback for which market

The default stack holds almost everywhere. The fallback layer is where your audience changes the answer. The table below is my working guidance, not a published standard. Test it against your own sign-in data.

Audience pattern	Best fallback	Watch out for	Notes
Phone-first markets, where the phone number is the identity and email is rarely checked	SMS or WhatsApp code	SMS pumping, SIM swap, delivery delays	Offer a passkey right after every code sign-in. Restrict sending to the countries you serve.
Email-first, desktop-heavy audiences	Email one-time code	Codes landing in spam or promotions tabs	Send from a dedicated, authenticated sending domain.
Business users on company domains	SSO routed by email domain	Personal and work accounts getting mixed	Identifier-first routing (Chapter 7) makes this invisible.
Older or shared devices without passkey support	Email code, with a typed code as an alternative to the link	Users signed in on a shared computer	Keep sessions short on devices the user does not mark as theirs.
High-value accounts (finance, health, admin)	A second passkey or security key	Users with only one device	Ask for a backup passkey at enrollment, not after a loss.

In a phone-first market, removing SMS on day one will lock out real customers. The goal there is to make SMS the door people pass through once, on the way to a passkey.

How to retire SMS safely

Retiring SMS is a migration, not a switch. Microsoft set a public precedent: passkeys became the default in Entra ID on September 1, 2026, and its own SMS and voice codes stop on February 1, 2027 (Cybernews). That is a five-month runway with a date users can see. Here is a sequence that works for consumer brands.

1. Measure first. Find the share of sign-ins that use SMS, by country and by device type. That number is your migration backlog.
2. Stop the inflow. New accounts get a passkey or email code by default. SMS stays available only where the market needs it.
3. Convert at every SMS sign-in. After a successful code, offer a passkey in one tap. The user has just proven who they are, which is the best enrollment moment there is.
4. Demote, then remove. Move SMS from primary sign-in to recovery only. Keep the cool-down and notification rules from Chapter 7 on every SMS recovery.
5. Harden what remains. Restrict sending countries, rate-limit by number and by IP, and alert on spikes in unusual destinations.
6. Announce a date. Tell users in product, by email, and on your help center. Give them the passkey path in the same message.
7. Keep a monitored exception path. Some users will arrive after the date. Route them to email recovery with a cool-down, not to a support agent who can override everything.

NIST's position makes this sequence defensible. SMS is still allowed, but as a restricted authenticator it needs a risk assessment and an alternative for users (Presencis). The steps above are that assessment and that alternative, written down.

Where passwordless goes wrong

• Treating email links as strong security. They remove password pain, but they are only as safe as the user's inbox.
• Keeping the password as a silent backdoor. A passkey next to a password still leaves the password for attackers and reset tickets. A FIDO and Imprivata survey found 28% of organizations use passkeys, but only 15% use them without a password. (Start with Identity)
• Ignoring desktop. Passkey creation and use behave differently on shared or older desktops. Test cross-device QR flows before you launch.
• Measuring enrollment instead of use. As Chapter 4 showed, a passkey nobody is routed to is a cost with no benefit. Track passkey share of sign-ins from week one.

For a vendor-by-vendor view of who supports which methods, see Passkey Solutions Compared in the enterprise passkey ebook, and Chapters 9 and 10 of this book.

Key takeaways

• Only passkeys and security keys are phishing-resistant. Every other passwordless method removes the password but leaves a secret or approval that can be relayed.
• Default to a synced passkey for sign-in and step-up, with social sign-in for fast signup and an email code as the portable fallback.
• Choose the fallback by audience. Phone-first markets may need SMS or WhatsApp codes, but only as a door to a passkey.
• Retire SMS in stages: measure, stop the inflow, convert at every SMS sign-in, demote to recovery, then announce a date.
• A passkey next to a password keeps most of the password's risk. Plan the password's exit from the start.