Magic Links vs OTP: Picking the Passwordless Fallback

Key takeaways

• Magic links favor desktop-only flows; OTP favors mobile and cross-device flows where switching apps is friction.
• Email magic links are bounded by email account auth strength, only as secure as the user's email.
• SMS OTP is no longer adequate for AAL2 per NIST SP 800-63-4; use email OTP or TOTP instead.
• Both are fallback patterns in 2026, passkeys are the primary, magic links / OTP cover unsupported devices and recovery.
• Deliverability dominates the user experience, email tuning often matters more than the protocol choice.

What each pattern is

The choice between them is largely UX, not security. Both are bounded by their delivery channel, both are phishable via AitM proxy in ways passkeys are not, and both serve as appropriate fallback factors when the user's device doesn't support passkeys.

When magic links win

• Desktop-only flows. User is at their laptop, opens email in the same browser, clicks the link, and is signed in without switching apps.
• Single-use convenience. No code to remember, no typing.
• Branded UX. The email layout, copy, and CTA can be designed end-to-end.

When OTP wins

• Mobile or cross-device flows. User is on phone, signs in on laptop. Switching to email app, copying a code, typing it on laptop is faster than navigating to the laptop email and clicking the link.
• Recovery scenarios. User is asked for a code to verify identity, paste it into the app, works without an email link round-trip.
• MFA second factor. OTP composes cleanly as the second factor after a primary auth.

Why SMS OTP is no longer adequate

NIST SP 800-63-4 (2024) places SMS OTP outside AAL2. The reason: SIM-swap attacks and adversary-in-the-middle proxies defeat SMS OTP at scale. Production phishing campaigns through 2023–2024 demonstrated real-time SMS-OTP harvesting against major SaaS targets.

For 2026 deployments, SMS OTP remains acceptable only as a fallback where the alternative is no MFA at all. Email OTP, TOTP, and push MFA with number matching are stronger; passkeys are stronger still.

Deliverability is the hidden cost

The most common complaint about magic links and email OTP is "they don't arrive" or "they take 5 minutes." This is almost always email deliverability, not the auth code itself:

• SPF / DKIM / DMARC alignment, without all three, mail providers throttle or reject.
• Sender reputation, new sending domains require warming over weeks.
• Dedicated sending IPs, for high-volume senders, IP reputation isolates from neighbor abuse.
• ESP choice, Postmark has a strong reputation for transactional; SendGrid and SES require careful tuning to match.

Most CIAM vendors send via their own infrastructure but let teams configure custom SMTP. For consumer apps where deliverability is a sales concern, dedicate engineering to it.

What to ship in 2026

The 2026 best practice for passwordless deployments:

1. Passkeys as primary, conditional UI, device-aware prompting, the orchestration patterns described in the passwordless guide.
2. Magic links / email OTP as fallback, for users on devices without passkey support or who haven't enrolled.
3. TOTP for users who explicitly want it, security-savvy users with authenticator apps.
4. SMS OTP as last-resort fallback only, never the primary or only second factor.

Vendor support snapshot

Every CIAM in this index supports magic links and email OTP. The differentiator is orchestration, how cleanly the vendor handles conditional UI for passkeys with magic-link fallback. Stytch, Clerk, MojoAuth, and Rownd ship the cleanest combined passkey + magic-link UX for B2C consumer apps.