What breaks when SMS is used as a primary account recovery factor?

Why This Matters for Security Teams

SMS looks convenient because it is already familiar, widely deployed, and easy to understand for help desk teams. The problem is that recovery factors are supposed to restore trust after primary authentication fails, yet SMS depends on the same telecom ecosystem that attackers can subvert through SIM swap or port-out fraud. Once that happens, the recovery path becomes the compromise path.

This matters because account recovery often has higher privilege than ordinary sign-in. A successful reset can bypass password hygiene, MFA enrollment, and sometimes even device-based checks. NIST guidance places strong emphasis on phishing-resistant and appropriately bound authenticators, while recovery channels need their own threat model rather than being treated as a lower-cost version of login. The Ultimate Guide to NHIs is useful here because it shows how identity failures are usually lifecycle failures, not single-factor failures. In practice, many security teams encounter recovery abuse only after the attacker has already redirected the phone number and completed the reset, rather than through intentional account compromise testing.

How It Works in Practice

SMS breaks down as a primary recovery factor because it is not truly independent from the identity being recovered. If an attacker can convince a carrier to move a number, or can take control of the victim’s SIM, they can receive one-time reset codes, password reset links, or step-up prompts. At that point, the recovery flow is validating the attacker’s access to the telecom account, not the user’s intent.

Better recovery designs separate the recovery factor from the channel most likely to be intercepted. Current guidance suggests using a more resistant recovery path such as a hardware-bound authenticator, verified device possession, or a pre-enrolled recovery method that is not exposed to the public phone network. For enterprise environments, recovery should also include fraud monitoring, help desk verification controls, and explicit step-up approval for high-risk changes. The NIST Cybersecurity Framework 2.0 is relevant because recovery is part of identity governance and protective controls, not just an end-user support task.

Practically, teams should think in terms of recovery assurance:

• Use SMS only for low-risk notifications, not as the sole recovery path.
• Require a stronger factor for account changes, especially password resets and MFA re-enrollment.
• Bind recovery approval to a trusted device, help desk workflow, or out-of-band verification that is harder to hijack.
• Log and alert on number changes, recovery attempts, and repeated failed reset requests.

The Ultimate Guide to NHIs also highlights how frequently weak identity controls persist across environments, which is why recovery design should be reviewed alongside secrets handling and privilege boundaries. These controls tend to break down in consumer-facing support desks and telecom-heavy regions because number ownership can change faster than the organization can verify the real user.

Common Variations and Edge Cases

Tighter recovery controls often increase friction, requiring organisations to balance user convenience against account-takeover risk. That tradeoff becomes sharper for executives, finance users, and privileged administrators, where recovery abuse can have outsized blast radius. Best practice is evolving, but there is no universal standard for when SMS is acceptable as a backup-only factor versus when it should be removed entirely.

Some environments still use SMS as a fallback when no other authenticator is available, but that approach should be limited to low-value accounts and paired with strict time delays, manual review, and forced re-enrollment after use. High-risk accounts should use recovery methods that survive telecom compromise, such as pre-registered recovery codes stored securely, hardware security keys, or verified device-based recovery. Teams should also remember that number recycling, shared family plans, and roaming can create false assumptions about who controls the number. The NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the need for layered verification and monitoring, even though neither treats SMS recovery as a high-assurance control.

In practice, SMS recovery breaks most often in support-heavy workflows where attackers exploit urgency, call center process gaps, and weak number-change verification before defenders can react.

Related resources from NHI Mgmt Group

• What breaks when account recovery is easier than primary authentication?
• What breaks when a phishing-resistant primary login still falls back to SMS recovery?
• What should organisations do when SMS OTP is still used for account recovery?
• How should security teams govern API keys used for generative AI access?