Only when the use case justifies the fraud exposure and cost. SMS is convenient, but it is easy to automate, expensive at scale, and weak against abuse. Most teams should reserve it for trusted fallback scenarios and use stronger challenge or verification controls for routine journeys.
Why SMS looks convenient but behaves like a weak default
SMS persists because it is familiar, low-friction, and nearly universal, but those operational benefits do not make it a strong default for every login journey. As a second factor, it is especially vulnerable when the channel itself can be intercepted, redirected, socially engineered, or reused at scale. The practical question is not whether SMS works, but whether the risk profile is acceptable for the account or transaction being protected.
For routine workforce or customer authentication, stronger methods usually provide a better balance of security and user experience. Phishing-resistant options such as passkeys or security keys reduce the attack paths that make SMS attractive to attackers. NHIMG’s MFA Guide compares these methods directly and explains where SMS still fits as a fallback rather than a primary choice.
SMS also becomes a poor default when the organisation needs consistent assurance across high-volume journeys. Because the factor is tied to a phone number and a telecom delivery path, the security outcome depends on external systems the organisation does not fully control. That makes SMS a weaker fit for high-value access, privileged actions, and accounts that would cause disproportionate damage if compromised.
Where SMS fails in real attacks and operations
Attackers do not need to “break” SMS encryption to make it fail. They can abuse SIM swap, number porting, message interception, OTP relay, smishing, or MFA fatigue adjacent workflows to capture or bypass the code. Session theft and legacy account abuse also matter because a weak second factor can be sidestepped entirely once an attacker gets into a trusted path.
NHIMG’s Twilio 0ktapus breach 2022 is a useful reminder that SMS-based or SMS-adjacent sign-in flows can be phished at scale, while CitrixBleed exploitation 2023 shows how stolen session material can render MFA irrelevant after initial access. The lesson is that “two factors” is not the same as “resistant to takeover”.
Operationally, SMS also carries hidden cost. Help desk resets, SIM replacement cases, roaming issues, delayed delivery, and support escalations all add friction, especially at scale. If SMS is the default, teams often absorb that cost everywhere, even when only a small subset of journeys truly needs it.
When SMS belongs, and when it should not be the default
SMS can still be reasonable in narrowly defined fallback scenarios, for example when a user temporarily lacks access to stronger authenticators and the account does not expose high-impact systems. It may also be acceptable for low-risk consumer journeys where convenience and reach are the overriding constraints, provided the organisation understands the residual fraud exposure.
It should not be the default for administrative access, high-value transactions, recovery flows, or any journey where account takeover would cause material loss. In those cases, a better pattern is to reserve SMS as an exception path and make stronger challenge or verification methods the normal route. NHIMG’s Passwordless and Passkeys Guide covers the main replacement path, while the Workforce Identity Security Guide explains how to handle recovery, resets, and step-up authentication without over-relying on phone codes.
For organisations that still keep SMS in the mix, the key design decision is whether it is a controlled fallback or a broad default. The more an account can reach sensitive data, production systems, or irreversible transactions, the less defensible SMS becomes as the everyday method.
Risk and Threat Considerations
SMS as a default 2FA method creates a measurable fraud and takeover exposure because the second factor can be attacked outside the application itself. Attackers target the phone number, the carrier workflow, the message channel, or the user’s trust in a code prompt, which makes the control easier to scale against than phishing-resistant methods.
Failure mechanism: An attacker uses SIM swap, number porting, smishing, OTP relay, or session theft to capture or bypass the SMS challenge, then reuses the authenticated session or performs account recovery to persist access.
Impact: Account takeover can lead to fraud, data theft, admin compromise, support burden, and repeated recovery events, especially where SMS is the primary or only second factor.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Sets assurance expectations for MFA strength and phishing resistance in authentication choices. |
| Recommendation — Prefer phishing-resistant authenticators over SMS for higher-assurance sign-in journeys. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers authentication strength for workforce access and second-factor design. |
| IA-5 — Authenticator Management | Addresses lifecycle and protection of authenticators, including OTP delivery and recovery risks. | |
| Recommendation — Require stronger authenticators than SMS for organizational access where risk is material. Manage fallback authenticators so they are governed, limited, and revocable. | ||
| OWASP ASVS | V6 — Authentication | Authentication assurance and factor resistance are central to the SMS-versus-stronger-MFA decision. |
| V7 — Session Management | Session theft can bypass MFA, so session controls materially affect SMS reliance. | |
| Recommendation — Use stronger authentication requirements for sensitive sign-in and recovery flows. Harden session handling so stolen sessions do not negate second-factor checks. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | SMS depends on a weaker authentication path that is easier to intercept and abuse. |
| NHI-07 — Long-Lived Secrets | One-time codes and recovery credentials become abuse-prone when reused or overly durable. | |
| Recommendation — Replace weak second-factor paths with stronger authenticators where possible. Minimise reusable or durable fallback secrets in authentication and recovery. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Authentication weaknesses in adjacent APIs and recovery flows can undermine SMS-based assurance. |
| Recommendation — Audit API and recovery authentication so SMS is not the weakest link. | ||
Practitioner Guidance
What to prioritise: Treat SMS as an exception path, not the baseline. Keep it only where the business case clearly outweighs the fraud and support cost, and where a failed SMS delivery does not block a high-risk action.
What to verify: Check which journeys still allow SMS by default, which accounts can reach privileged or financial actions through it, and whether recovery flows silently reintroduce it after stronger authentication has been deployed. NHIMG’s IAM and Identity Provider Buyer’s Guide is helpful when you are deciding how much of the lifecycle should be handled by the identity platform versus the app.
Decision rule: If a login or recovery path can unlock sensitive data, production access, or irreversible transactions, replace SMS with a stronger method and keep SMS only as a tightly governed fallback.
Practitioner takeaway: The right question is not whether SMS is usable, but whether it is still defensible as the default when stronger, phishing-resistant methods are available for the same journey.
Related resources from NHI Mgmt Group
- Why do organisations keep relying on passwords and SMS-based 2FA even when stronger options exist?
- When should organisations keep social login optional rather than making it the default sign-in method?
- What breaks when organisations keep passwords as the default identity control?
- What do organisations get wrong about SMS-based 2FA and fraud risk?