Magic Links vs OTP vs Passkeys: Picking Customer Passwordless Login

Customer teams that drop passwords usually pick between magic links, one-time codes and passkeys, and the choice decides how many customers sign in first time, how easily attackers take accounts over, and how much the help desk spends on recovery. All three remove the password, but they move trust to very different places: the mailbox, the phone number or the device. This guide compares them for consumer and B2B customer sign-in on three questions: phishing resistance, conversion and recovery, plus the device mix your customers actually have. It is for product owners, CIAM architects and fraud teams. Token and code design, link scanners and message wording are covered in the Magic Links and Email OTP Security Guide and the OTP security guide; this page does not repeat them.

Key takeaways

• Only passkeys are phishing-resistant. NIST SP 800-63B-4 states that out-of-band and OTP authentication are not phishing-resistant, and that authenticators which need manual entry of an output cannot be; WebAuthn credentials are scoped to the site's origin and cannot be replayed against a different one.
• Email and SMS borrow someone else's security. A magic link is as strong as the customer's mailbox; an SMS code is as strong as their mobile carrier's SIM swap and port-out checks.
• Passkeys convert better once enrolled. The FIDO Alliance Passkey Index (October 2025) reported a 93 percent sign-in success rate for passkeys against 63 percent for other methods, from nine member organisations.
• Recovery sets the real strength. If a lost passkey can be replaced with an emailed link, the account is only as strong as email; design recovery before rollout.
• Plan for a mix, not a winner. Lead with passkeys where devices support them, keep one bound, rate-limited fallback, and step up for risky actions.

The three methods in brief

• Magic link: the service emails a single-use URL; opening it signs the customer in. Possession of the mailbox is the only factor. The link can be bound to the browser session that asked for it, so it only completes on the same device.
• One-time code (OTP): the service sends a short code by email, SMS or voice, and the customer types it into the page. It works across devices because the code is typed, which is also why it can be relayed. Codes from an authenticator app (TOTP) are a different case, covered in the Authenticator Apps and OTP Guide.
• Passkey: a FIDO credential, a key pair created for one site, unlocked with the same biometric or PIN the customer uses to unlock their device. Passkeys can be synced across a customer's devices by their platform or password manager, or bound to one device. FIDO cross-device authentication lets a phone approve a sign-in on a laptop through a QR code, with Bluetooth confirming the two are close. See WebAuthn vs FIDO2 vs Passkeys.

Decision table: phishing resistance, conversion and recovery

Threat model for each method

Magic links and email OTP: email account takeover

Both methods hand authentication to the email provider. Anyone who controls the mailbox, through a reused password, an infostealer session cookie or a forwarding rule planted earlier, can sign in. NIST SP 800-63B-4 section 3.1.3.1 states that email "SHALL NOT be used for out-of-band authentication", and OWASP ASVS 5.0 requirement V6.3.6 asks that email is not used as a single or multi factor. Email-based sign-in is therefore a low-assurance convenience method: acceptable for low-value accounts, not as the only barrier to stored payment cards, loyalty balances or personal data that would cause harm if exposed. A second email-specific risk is the change of email address: if an attacker who briefly holds a session can change the address of record without re-authentication, they own the account permanently. See the Account Takeover Prevention Guide.

OTP: real-time relay and SIM swap

A typed code can be phished. An adversary-in-the-middle page asks the customer for their code and submits it to the real site within its validity window, which is the pattern ATT&CK tracks as T1111 Multi-Factor Authentication Interception. Social engineering does the same without a fake page: a caller posing as the bank asks the customer to read out the code. SMS adds the carrier as a dependency: mobile ATT&CK T1451 SIM Card Swap describes attackers impersonating victims to their carrier to move the number to a SIM they control, after which every code goes to them. NIST treats PSTN delivery as restricted and treats a change of the pre-registered phone number as binding a new authenticator. Delivery providers are a third-party path too: after the Twilio Breach 2022, Signal said attackers could have seen about 1,900 users' phone numbers or SMS verification codes and could have tried to re-register those numbers. See the SIM Swap Fraud Guide and AiTM Phishing Guide.

Passkeys: device, sync account and recovery

Passkeys remove the phishable secret. The W3C WebAuthn Level 3 specification (a W3C Recommendation dated 25 August 2026, checked November 2026) scopes each credential to a relying party so that operations "cannot be replayed against a different origin". The remaining paths are different: an attacker with an unlocked device, an attacker who takes over the customer's platform or password manager account where synced passkeys live, and, most often, an attacker who skips the passkey entirely through a weaker recovery or fallback path. NIST SP 800-63B-4 notes that keys on syncable authenticators are inherently exportable and lists enforcing AAL2 for access to sync fabrics as a mitigation, which the relying party cannot enforce itself.

Failure modes and the controls that close them

Conversion: what the evidence says

The FIDO Alliance Passkey Index, published 14 October 2025 from a confidential survey of nine member organisations, reported that passkey sign-ins succeeded 93 percent of the time against 63 percent for other methods, took an average of 8.5 seconds against 31.2 seconds, and led to an 81 percent reduction in login-related help desk incidents. Treat these as indicative: the sample is small, self-reported and from organisations that chose to deploy passkeys. Measure your own funnel. The conversion losses for email and SMS come from predictable places: messages delayed or filtered, customers who cannot reach their inbox on the device they are using, links consumed by corporate mail scanners (a particular problem for B2B customers), and SMS that fails to arrive abroad. Passkey losses sit in enrolment, older devices and customers who do not recognise the prompt; autofill-style prompts reduce this, see Passkey Autofill and Conditional UI.

Recovery: the decision that sets real strength

NIST SP 800-63B-4 section 8 puts it directly: "one authentication factor cannot be leveraged to obtain an authenticator of a different factor". In customer terms, if a forgotten-passkey journey ends with "we have emailed you a link", the passkey added no protection against an attacker who holds the mailbox. Recovery design per method:

• Magic link and email OTP: recovery is the email provider's own recovery. Protect the change-of-email journey and alert the old address. There is little more the relying party can add.
• SMS OTP: number changes are new authenticator bindings under NIST. Require the strongest other bound method, or a cooling-off period with notification to the old number, before the new number is trusted for sign-in.
• Passkeys: encourage a second passkey at enrolment, rely on platform sync for device loss, and for full loss use step-up recovery proportionate to account value: recovery codes saved by the customer, identity verification for high-value accounts, or a delay with notification. NIST requires that "account recovery SHALL cause a notification to be sent to the subscriber". See Passkey account recovery.

Device mix and audience

Small businesses using a CIAM platform should take the platform's built-in passkey and email OTP options rather than building token handling. Large consumer brands should run controlled experiments on enrolment prompts and measure fallback use by segment, because a passkey programme that leaves 40 percent of customers on SMS still carries the SMS risk for those customers.

Worked scenario: an online retailer

A retailer with 3 million customer accounts uses passwords plus SMS OTP at checkout. Fraud reports show account takeovers through credential stuffing and some through SIM swap; SMS spend is rising and international customers often miss codes.

1. Offer passkeys after every successful sign-in and at checkout confirmation, with autofill prompts on sign-in pages.
2. Replace SMS as the default fallback with email OTP bound to the browser session, valid 10 minutes, single use, rate limited per account and IP range. Keep SMS only for customers with no usable email, and only with a validated number.
3. Re-design recovery: customers with a passkey who lose it get a code to email plus a 24-hour hold on payment method and address changes, with notifications to both email and phone.
4. Step up for sensitive changes: changing email, phone, delivery address or saved cards requires a passkey, or the email OTP plus a second check for customers without one.
5. Measure passkey enrolment, sign-in success by method, fallback rate and takeover rate monthly, and retire passwords for customers with a passkey once fallback use is stable.

How to implement: phased approach

1. Map every sign-in and recovery path in web, app, support desk and API. Undocumented pathways weaken everything else (ASVS V6.3.4).
2. Harden the fallbacks first. Binding, short expiry, single use and rate limits on links and codes, and re-authentication on email and phone changes.
3. Pilot passkeys with a share of signed-in customers, offering creation after a successful sign-in. Track enrolment and error codes per browser and platform.
4. Ship recovery before scale. Second-passkey prompts, recovery notifications and step-up recovery for high-value accounts.
5. Expand and make passkeys default for enrolled customers, with the fallback behind a "try another way" link.
6. Roll back safely. Keep the previous method enabled during the pilot; disabling passkey sign-in for a segment must leave existing passkeys stored, so they can be re-enabled without re-enrolment.

Detection and measurement

Log the method used for every sign-in, every recovery and every change of email, phone or passkey list, with device and network signals. Alert on recovery followed quickly by payment or address changes, many OTP requests for one number or to premium-rate ranges, sign-ins from new devices after a phone-number change, and passkey deletions followed by fallback sign-in.

• Sign-in success rate by method: share of started sign-ins that complete, per method and platform.
• Passkey coverage: share of active customers with at least one passkey, and with two or more.
• Fallback rate: share of sign-ins by enrolled customers that use email or SMS instead of the passkey.
• Account takeover rate: confirmed takeovers per 100,000 active accounts, split by the method used to get in.
• Recovery rate and abuse: recoveries per 1,000 active accounts, and the share later confirmed fraudulent.
• Cost per successful sign-in: SMS and email delivery spend divided by completed sign-ins.

Common failure patterns

• Passkey with an email back door: the "trouble signing in?" link sends a magic link that bypasses the passkey entirely.
• Magic link clicked by a scanner: links that sign in on a plain GET are consumed by mail security tools, so B2B customers see "link expired" and abandon.
• SMS kept as a silent default: passkeys launched, but the app still offers SMS first, so most customers never move.
• Unthrottled code endpoints: no per-number limits, leading to SMS pumping charges and guessing of short codes. See Phone Number Fraud.
• Contact change without re-authentication: an attacker with a short session changes the email address and then owns every future magic link.
• Support desk as the weakest method: agents reset access on knowledge questions. See the Account Recovery and Help Desk Security Guide.

Framework mapping

Practitioner checklist

• Passkeys offered to every customer whose device supports them, at sign-up and after fallback sign-ins.
• Customers can register more than one passkey and are prompted to add a second.
• Magic links and codes are single use, bound to the request and browser session, and expire within 10 minutes.
• OTP endpoints are rate limited per account, number, device and network.
• SMS used only with validated numbers and a stronger option available.
• Email and phone changes require re-authentication and notify the old contact.
• Recovery never resets a passkey account with email alone for high-value accounts, and always sends a notification.
• Sign-in success, fallback rate and takeover rate tracked per method.

Standards and references

• NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
• W3C: Web Authentication Level 3
• FIDO Alliance: Passkeys
• FIDO Alliance: Passkey Index announcement
• OWASP: Application Security Verification Standard 5.0
• MITRE ATT&CK: Multi-Factor Authentication Interception (T1111)
• MITRE ATT&CK Mobile: SIM Card Swap (T1451)

Related NHI Mgmt Group resources: Magic Links and Email OTP Security Guide · Passkeys for Everyone Guide · OTP security · Customer IAM (CIAM) Guide · Phishing-Resistant MFA Guide