SMS becomes risky because it can be intercepted, redirected, or abused through fraud schemes that generate charges or bypass intended assurance. It also provides weaker proof of possession than phishing-resistant methods. The risk rises when organisations use SMS as the only factor for account creation, money movement, or changes to sensitive customer data.
Why This Matters for Security Teams
SMS verification is attractive because it is familiar and fast, but that convenience hides a weak assurance boundary. For important transactions, the real question is whether the organisation can trust that the person or workflow receiving the code still controls the intended device and number at the moment of approval. Attackers exploit SIM swap fraud, call forwarding abuse, malware on mobile devices, and social engineering to defeat that assumption. NIST guidance on identity assurance and control selection treats factor strength as context dependent, not universal, which is why SMS should not be treated as a high-confidence proof of possession for sensitive actions. The issue is not just account login. It is account recovery, money movement, beneficiary changes, and customer data edits where a single intercepted text can become a transaction approval. Current guidance also aligns with NHI Mgmt Group’s broader warning that weak identity controls fail when they are asked to carry more assurance than they were designed to provide; see the Ultimate Guide to NHIs — Why NHI Security Matters Now. In practice, many security teams discover SMS weakness only after fraud, chargeback, or account takeover has already been recorded.
How It Works in Practice
For low-risk notifications, SMS can still be acceptable. For high-impact transactions, it should be treated as a legacy fallback, not the primary trust signal. Stronger approaches use phishing-resistant authentication such as FIDO2 or passkeys, or step-up verification bound to the specific transaction. The control objective is to verify both the actor and the action, not just the phone number.
A practical design usually combines several elements:
- Transaction-specific confirmation, so the approval code is tied to amount, recipient, or account change.
- Risk-based step-up checks that trigger stronger verification when device, geography, or velocity looks abnormal.
- Short-lived, single-use tokens with automatic expiration, reducing replay value if the message is intercepted.
- Out-of-band alerts that inform users, but do not by themselves authorize the transaction.
- Recovery paths that avoid SMS as the sole method for resetting credentials or changing contact details.
For organisations building a mature identity program, the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls provide the governance language to classify these flows by risk and enforce stronger controls where assurance matters most. The NHI-specific lesson is similar: when credentials or assertions are easy to redirect, the problem is not the channel alone, but the decision to trust it as a durable proof of identity. NHI Mgmt Group’s data shows why weak identity artefacts persist as an enterprise risk, including that 79% of organisations have experienced secrets leaks and 77% of those incidents caused tangible damage; see Ultimate Guide to NHIs — Key Challenges and Risks. These controls tend to break down in customer service workflows where agents are pressured to resolve requests quickly and bypass stronger step-up checks.
Common Variations and Edge Cases
Tighter verification often increases friction, so organisations must balance fraud reduction against conversion loss, support burden, and accessibility. That tradeoff is real, especially where SMS remains the only broadly available option for some user populations.
Current guidance suggests a few important exceptions. SMS may be acceptable as a backup factor when paired with another stronger method, but not as the only safeguard for high-value transfer approvals or sensitive account changes. In regulated or high-fraud environments, best practice is evolving toward phishing-resistant methods plus contextual policy checks, because the same phone number can be hijacked even when the account itself is otherwise protected. There is no universal standard for this yet, but the direction is clear: assurance should scale with transaction risk.
Operationally, the hardest cases are account recovery and number change flows. If SMS is used to re-establish trust after a password reset or device loss, it can become the easiest path for takeover rather than the safety net. Organisations should also watch for edge cases where SMS delivery delays cause users to retry, increasing exposure to relay or phishing attacks. The Top 10 NHI Issues reinforces the broader principle that identity controls fail when they are reused beyond their intended assurance level, and that principle applies just as much to customer-facing verification as it does to machine identities.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-03 | Addresses identity proofing and authentication assurance for sensitive actions. |
| NIST SP 800-63 | IAL2 | SMS is weak evidence for identity assurance in sensitive workflows. |
| NIST AI RMF | Risk management should align authentication strength to transaction impact. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Shows how weak, reusable credentials increase takeover risk. |
Use higher-assurance proofing and phishing-resistant authenticators where transactions matter.
Related resources from NHI Mgmt Group
- What breaks when organisations rely only on upstream patching for SAML security?
- What breaks when organisations rely on help desk resets to recover access?
- What breaks when organisations rely on network mitigations instead of patching for LDAPNightmare?
- Why do copied verification seals become dangerous when they are reused outside their original context?