Magic links and OTP codes are not equivalent authenticators

What it is

“Passwordless” only says someone does not memorize a password; it does not say how strong the authenticator is. A magic link is a high-entropy token redeemed by a click in mail (or a message). An OTP is a short space, often copied from SMS or mail, used as a shared secret. Both are passwordless; resistance to guessing, interception, and phishing is not in the same band. This entry isolates non-interchangeable strength: dropping the password does not make a six-digit SMS code the same control as a long email link. It does not cover burning a link after one use, and it does not cover a second confirmation on the device.

Why it happens

Strength comes from three things: entropy of the secret, the delivery channel, and how the person presents it. Short codes have low entropy and live on TTL plus guess caps; the channel is often SMS, which can be SIM-swapped or intercepted on the signaling path. NIST SP 800-63B marks SMS OTP a restricted authenticator not because it is unpleasant to use, but because the channel cannot carry high assurance. Magic links have high entropy, so enumeration barely applies; the attack surface moves to a stolen mailbox, a phishing page that swaps the URL, or a click on an untrusted device. Drawing both as one “passwordless” switch lets a cheap short code guard actions that need high assurance (change of email, transfer), or lets an email link cover people with no mailbox while still claiming equal security. A shared label hides a difference in authenticator assurance level.

Studying it

Measure by threat model, not by “passwordless completion rate” alone.

Independent variables: authenticator kind (SMS OTP, email OTP, email magic link, in-app TOTP), assurance demanded by the action (sign-in, password change, funds). Dependent variables: online guessing success (short codes), successful link-swap phishing (links), takeover after channel compromise, whether people judge the two as “equally safe.”

Usable-security experiments can put a phishing page next to a real one and compare codes copied versus links clicked. Do not invent “links are X percent safer than SMS”; NIST-style guidance gives tiers (allowed / restricted / not for this assurance), not a conversion formula. Completion rate speaks to friction, not strength.

Where it stops holding

For low-assurance, low-consequence sign-in (an optional account after reading public content), either can be “better than nothing.” Once the action changes ownership, contact channels, or money, short codes and links must be graded apart, and short codes are often not enough. Enterprise gateways that rewrite links lower link assurance; that does not automatically raise short-code assurance. Passkeys and hardware keys are a third class and should not be scored inside this passwordless pair. When people say “I log in with a code,” they may mean SMS, mail, or an authenticator app; fix the channel before talking about strength.

Applying it

• Internally label authenticators at different assurance levels: SMS OTP, email OTP, email links, authenticator apps each list allowed actions. Do not let the word “passwordless” in settings imply equivalence.
• For changing email, changing password, or moving funds, do not treat SMS short codes as a single factor equal to a long email link or an authenticator; when stepping up, say “this step cannot use an SMS code.”
• Explain the difference with channel facts (“a new SIM can receive the SMS” versus “whoever clicks the link is in”), not an abstract score.
• Verify by listing which authenticator each sensitive action currently accepts, against a written assurance tier, and finding paths where a short code alone covers a high-consequence action. In one phishing drill, check whether copying a code and clicking a link were treated as the same “it is all passwordless, so it is all safe” decision.

Related

• Within the group: H6.03.1 OTP fields must accept paste and autofill · H6.03.2 OTP expiry and resend interval must be visible · H6.03.3 SMS failure needs a fallback channel · H6.03.4 A magic link must expire after one use so forwarding cannot reuse it · H6.03.5 Limit OTP guesses to stop brute-force enumeration · H6.03.7 Passwordless login still needs a device-side confirmation against intercepted links
• Adjacent: H6.12 Multi-factor authentication · H6.04 Password rules
• Search terms: authenticator assurance · magic link · restricted SMS OTP