Why do SMS-based recovery flows remain risky in modern IAM programmes?

Why This Matters for Security Teams

SMS-based recovery still appears in modern IAM programmes because it is easy to deploy and familiar to users, but that convenience masks a brittle trust assumption: the phone number is treated as proof of possession even when the carrier, handset, and number porting process can all be manipulated. Security teams usually discover the weakness after a takeover attempt, not during design review. The issue is especially serious for high-value accounts, support desks, and privileged users where account recovery becomes the path of least resistance.

At a programme level, SMS recovery also weakens assurance because it bypasses the stronger controls organisations have already invested in, such as phishing-resistant MFA, device binding, and step-up authentication. NIST’s NIST Cybersecurity Framework 2.0 emphasises identity protection as a core risk-management function, yet recovery flows often sit outside the same scrutiny. NHIMG’s Top 10 NHI Issues shows how identity processes fail when trust is placed in a single weak signal instead of layered assurance. In practice, many security teams encounter SMS recovery abuse only after an attacker has already redirected the recovery channel and reset the account.

How It Works in Practice

The risk is not just interception in transit. SMS recovery is vulnerable because attackers can target the underlying telephony ecosystem, impersonate the user to support staff, or exploit weak identity proofing at the help desk. Once a number is ported, swapped, or redirected, the recovery code becomes attacker-accessible. That is why SMS is a poor deciding factor for high-value accounts, even if it remains acceptable as a low-assurance notification channel.

Modern IAM programmes reduce this risk by treating recovery as a controlled assurance workflow rather than a simple code check. Stronger patterns typically include:

• Phishing-resistant authenticators for primary login, with recovery separated from normal sign-in.
• Device-bound or cryptographic recovery methods, such as passkeys, backup codes, or verified device approval.
• Help desk step-up procedures that require multiple independent signals before any reset is approved.
• Risk-based checks that evaluate user history, device posture, location anomalies, and recent account changes.
• Short-lived recovery windows with audit logging, so a reset cannot linger as an open attack path.

This aligns with NHIMG guidance on reducing weak identity dependencies in both human and non-human workflows, especially where one compromised signal can cascade into broader access abuse. The same pattern appears in NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now, where over-reliance on a single credential or channel creates systemic exposure. These controls tend to break down in large service desks with inconsistent verification scripts because attackers only need one undertrained operator or one permissive recovery exception.

Common Variations and Edge Cases

Tighter recovery controls often increase friction, so organisations have to balance user convenience against account safety and operational cost. That tradeoff is real, especially for consumer-facing services, frontline employees, and geographies where alternative authenticators are not uniformly available. Current guidance suggests that SMS can remain as a secondary signal in low-risk scenarios, but there is no universal standard that treats it as sufficiently strong for privileged or sensitive accounts.

Edge cases matter. Some organisations still rely on SMS for account bootstrap, emergency access, or fallback when a primary authenticator is lost. Those uses should be constrained by policy, time limits, and additional verification rather than treated as automatic trust. The same logic is echoed in NHIMG’s DeepSeek breach, where exposed credentials and weakly protected access paths amplified downstream risk. For teams seeking a more mature baseline, the practical direction is to reserve SMS for notification or low-confidence backup, then move high-assurance recovery to passkeys, verified devices, or supervised support workflows. Best practice is evolving, but the core rule is stable: if compromise of the recovery channel equals compromise of the account, the design is too weak for modern IAM.

Related resources from NHI Mgmt Group

• Why do rule-based fraud controls fail against modern identity abuse?
• Why do weak KYC and recovery flows create outsized fraud risk in crypto?
• What is LLMjacking in an IAM context?
• Why do reused passwords still matter in modern IAM programmes?