Why SMS second factors are a weak shared channel
An SMS-delivered second factor depends on PSTN delivery to a telephone-number channel. NIST tells verifiers to consider device swap, SIM change, number porting, and other abnormal behavior before using the network to deliver an out-of-band authentication secret. Those indicators do not prove an event occurred, an account was accessed, or the same number controls recovery.
Not legal advice. This page is research, not compliance guidance.
Why SMS is a shared delivery channel, not an independent location
An SMS-delivered authentication secret depends on PSTN delivery to a telephone-number channel, so the verifier should consider whether the device or number context shows a listed risk indicator before delivery.
The supported risk statement begins before delivery. NIST Special Publication 800-63B says a verifier SHOULD consider risk indicators before using the public switched telephone network to deliver an out-of-band authentication secret. Its examples are a device swap, SIM change, number porting, and other abnormal behavior. The guidance makes the telephone-number channel part of the authentication analysis rather than an invisible transport detail.
The word shared describes the dependency, not a claim that every account has the same architecture. The verifier makes an authentication decision, while delivery relies on the PSTN and a telephone-number context in which the NIST guidance says the verifier SHOULD consider risk indicators. VoIP and Carrier Numbers: What a Number Establishes keeps that statement narrow: the guidance is a risk check, not a general rule for accepting or rejecting a number.
The title's word weak is therefore bounded. It does not assign a failure rate, say that SMS delivery always fails, or establish that one of the listed events happened. It identifies a channel whose surrounding device or number context may present indicators that NIST says should be considered before delivery. The listed indicators do not establish that an authentication secret was intercepted, that an account was compromised, or that access followed.
Account recovery remains outside that statement. Evidence that an authentication secret can be delivered through the PSTN does not show that the same telephone number is attached to recovery. It also does not show that a recovery process uses SMS. Factor delivery and account-recovery attachment are separate facts that require separate support.
Use Passkeys and Second-Factor Location without copying its passkey claims
Passkeys and Second-Factor Location shows that factor location has multiple technical boundaries, but it expressly does not provide a complete location taxonomy for SMS codes, so its passkey-specific details cannot be projected onto SMS.
Passkeys and Second-Factor Location establishes one useful analytical boundary: factor location is not one undifferentiated place. Its documented passkey flow separates credential use, synchronization, and device binding. Those distinctions explain why a factor should not be described with one vague location label when its technical steps occupy different boundaries.
That source also states its limit. Its evidence does not establish a complete location taxonomy for SMS codes, authenticator applications, push approvals, or every hardware factor. The passkey page therefore supplies a way to keep technical boundaries separate, not an SMS architecture that can be copied here. Its statements about passkey keys, synchronization, device binding, or biometric processing are not treated as facts about SMS.
For the SMS question, the supported location statement is narrower. NIST addresses a verifier using the PSTN to deliver an out-of-band authentication secret and tells that verifier to consider specified risk indicators before delivery. That identifies a verifier decision, PSTN delivery, and a telephone-number context. It does not establish where every secret originates, what a particular device stores, how a named service validates a response, or what happens after a response is accepted.
The same discipline applies to recovery. A factor-delivery map cannot fill an account-recovery attachment, account policy, or post-recovery access that the sources do not establish. A general location framework does not supply product-specific SMS behavior.
Device swap, SIM change, and number porting are examples of risk indicators
NIST names device swap, SIM change, number porting, and other abnormal behavior as examples of risk indicators a verifier SHOULD consider before using the PSTN to deliver an out-of-band authentication secret.
The NIST list is verifier-facing and conditional. It says a verifier SHOULD consider risk indicators before PSTN delivery of an out-of-band authentication secret. The examples are a device swap, SIM change, number porting, and other abnormal behavior. The list tells a verifier what context to consider at that point in the process; it does not report that any event occurred.
Each item must keep that label. A device swap is an example of a risk indicator, not proof that a secret was delivered to the wrong device. A SIM change is an example of a risk indicator, not proof that a particular person caused the change. Number porting is an example of a risk indicator, not proof that an account was accessed. The broader phrase other abnormal behavior does not authorize an unstated event, actor, or outcome.
The normative word SHOULD must remain intact as well. The source does not say that every listed indicator must produce one universal response, and this page does not turn the recommendation into a carrier, product, or number-acceptance rule. The linked number reference summarizes the same boundary: the guidance is a risk check rather than a general acceptance rule.
A complete incident claim would need evidence beyond this list. The guidance does not establish a named account, a named carrier, a particular transfer, an intercepted secret, a successful authentication, or post-authentication access. It also supplies no frequency or probability for compromise. The accurate conclusion is limited to the verifier's pre-delivery decision: these are examples of context that should be considered before the PSTN carries the secret.
Account recovery is a separate evidence question
An SMS second factor does not establish that the same telephone number controls account recovery, and a recovery attachment does not establish that the number is used as an SMS second factor.
The cited sources stop before account recovery. The passkey reference says it does not provide a complete SMS location taxonomy. The NIST statement addresses risk indicators before PSTN delivery of an authentication secret. The number reference describes that statement as a risk check rather than a general acceptance rule. None of those statements identifies a product's recovery channel or account policy.
That leaves two implications unsupported. First, the presence of an SMS-delivered second factor does not establish that the same number can recover the account. Second, evidence that a telephone number is attached to recovery would not by itself establish that the account uses the number for second-factor delivery. Similar labels do not collapse the two roles into one relationship.
A careful review keeps at least five evidence slots separate: the account policy, the factor-delivery channel, any recovery attachment, any observed number or device event, and any observed access result. The sources on this page fill only a small part of that map. They support PSTN delivery as the setting for the NIST guidance and supply examples of pre-delivery risk indicators. They do not fill the account-policy, recovery-attachment, event-observation, or access-result slots for a named service.
This boundary prevents a standards statement from becoming an incident story. A device swap, SIM change, number port, or other abnormal behavior cannot be written as an observed event without evidence that it occurred. Even an observed event would not prove that it affected a recovery flow or produced account access. Every link in that path needs its own support.
Product, carrier, plan, and regional behavior also remain unresolved. No named carrier control, transfer safeguard, recovery workflow, or account-lock mechanism is established here. Those details require current evidence for the particular service and context rather than an inference from the NIST risk-indicator list.
Limits and non-findings
This page does not establish a named product's recovery attachment, an observed device or number event, an access outcome, a compromise rate, a carrier comparison, or a universal mitigation sequence.
No named product is shown using SMS for account recovery. The presence of an SMS second factor does not establish that the same number controls recovery, that SMS is the only factor, or that every SMS factor shares one recovery path. The reverse inference is unsupported too: a telephone number used for recovery would not by itself establish second-factor delivery through that number.
No device swap, SIM change, number port, or other abnormal behavior is reported for a particular account. NIST names those items as examples of risk indicators a verifier SHOULD consider before PSTN delivery. The list does not show that an event occurred, identify an actor, establish that an authentication secret was intercepted, or prove that account access followed.
No source here compares carriers, plans, transfer PINs, account locks, products, or regions. No source supplies a frequency, prevalence, probability, or compromise rate. The sources also do not establish one universal mitigation sequence or review cadence. A risk-indicator statement cannot become carrier guidance or a promise that one control resolves every delivery or recovery dependency.
The NIST passage used here was observed on 2026-10-04. The factor-location and number-reference passages were observed on 2026-10-05. Those dates identify the material used for this explanation; they do not establish later product, carrier, or account behavior. Private Pierce methodology explains that the site records source dates and treats an unobservable fact as an unknown.
The narrow conclusion is that PSTN delivery of an out-of-band authentication secret carries a verifier-facing context check: NIST says to consider device swap, SIM change, number porting, and other abnormal behavior before delivery. That statement supports treating the telephone-number channel as a shared dependency. It does not establish a universal failure, an observed compromise, or an account-recovery path.
Frequently asked questions
Why does an SMS second factor depend on a shared telephone-number channel?
The authentication secret is delivered through the PSTN to a telephone-number channel. NIST therefore tells verifiers to consider specified device and number-context risk indicators before delivery.
Which risk indicators does NIST name before PSTN delivery of an authentication secret?
NIST names device swap, SIM change, number porting, and other abnormal behavior as examples of risk indicators a verifier SHOULD consider before using the PSTN to deliver an out-of-band authentication secret.
Does a SIM change or number port prove that an account was accessed?
No. NIST lists SIM change and number porting as examples of risk indicators. The list does not establish that an event occurred, that a secret was intercepted, or that account access followed.
Does an SMS second factor mean the same number controls account recovery?
No such relationship is established by the cited sources. Factor delivery and account-recovery attachment are separate facts that require separate support.