SMS failure needs a fallback channel

What it is

When sign-in treats SMS as the only delivery pipe, a channel outage freezes identity. A fallback is another delivery or verification path aimed at the same proof: a voice call that speaks the code, a verified email, an authenticator, a passkey—not “send the same failing SMS again.” This entry is about a way out when the channel fails. It does not compare the strength of magic links, and it does not treat “switch channel” as a guess-limit policy.

Why it happens

SMS fails in unlike ways: carrier delay, roaming, unsynced number porting, spam filtering, a phoneless device that still claimed “this device’s number.” All the person sees is “nothing arrived.” If the UI only offers a countdown resend, every resend walks the same broken path and waiting is mistaken for a fix. A fallback’s value is fault orthogonality: voice uses the circuit domain, mail uses another identifier, an authenticator needs no in-the-moment delivery. Without a fallback, channel failure is shown as user error (“enter the correct code”), and people change the phone number or quit. The fallback should appear after failure is observable; listing every channel up front splits traffic before SMS has a chance, which wrecks measurement and cost.

Studying it

Under injectable delivery failure, compare “SMS resend only” with “a second channel after failure,” measuring recovery rather than first-delivery rate.

Independent variables: fallback type after failure (voice, email, authenticator), when it appears (all channels at once, after N resends, after an explicit “didn’t get it”), whether the fallback requires a prior binding. Dependent variables: eventual sign-in after channel failure, rate of wrongly changing the phone number, time from first send to success, premature fallback use.

Labs cannot faithfully copy roaming and carrier filtering; a never-deliver stub and airplane mode on a real device approximate. Fallback click-through is not success—if people skip an SMS that would have arrived, the measure is impatience. Interviews must split “did not receive” from “received but do not want SMS.”

Where it stops holding

With no second identifier bound, a fallback cannot be invented; voice to the same number, or a delayed human review, is what remains—not a pretend email channel. Some markets have no voice-OTP vendor; fallback is then mail or a passkey. If risk engines treat channel switching as account takeover, the fallback is killed by its own fraud rules; “user says not received” must be an explicit state, not silent multi-channel blasting. If the fallback is easier to hijack than SMS (an unverified mailbox), it may admit read-only access, not password change or transfer.

Applying it

• Place “didn’t get the code” beside the resend countdown; expand options orthogonal to the current failure; keep SMS as default and do not auto-switch.
• Voice fallback calls the same declared number; email fallback only if that mailbox was previously verified. Unbound channels must be bound first, not minted as an unverified exit while sign-in is stuck.
• State that fallback and SMS are the same sign-in attempt: do not reset the session or silently change the identifier.
• Verify by blocking SMS delivery (stub or airplane mode) and checking that someone can finish without changing the number; sample logs where SMS did arrive but fallback was tapped, to confirm a healthy channel was not declared dead. Report eventual success of channel-failed sessions, not how often the fallback control was shown.

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.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.6 Magic links and OTP codes are not equivalent authenticators · H6.03.7 Passwordless login still needs a device-side confirmation against intercepted links
• Adjacent: H6.12 Multi-factor authentication · H3.10 Retry strategy
• Search terms: SMS fallback · voice OTP · out-of-band recovery