SMS OTP becomes weaker when organisations assume the phone channel is trustworthy by default. Attackers can exploit SIM swap events, insecure VoIP lines, or low SIM tenure to intercept codes and complete account takeover. Without a prior risk check, the organisation may validate the wrong person while believing the second factor is protecting the session.
Why This Matters for Security Teams
SMS OTP is often treated as a simple second factor, but that assumption breaks when the phone number itself becomes the target. sim swap attacks, VoIP forwarding, recycled numbers, and weak telecom controls can let an attacker receive the code and pass the challenge without ever touching the legitimate device. NIST guidance on identity assurance and control selection reinforces that authentication factors should be matched to risk, not treated as interchangeable. See NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now for the broader lesson: identity controls fail when organisations trust a channel they do not actually govern.
For security teams, the real issue is not whether SMS can work in a narrow flow, but whether the organisation is checking whether that phone endpoint is still trustworthy at the moment of authentication. Without that check, the factor confirms possession of a number, not possession of a secure identity. In practice, many security teams encounter SMS OTP abuse only after account takeover, not through intentional testing of telecom risk.
How It Works in Practice
The safer pattern is to treat SMS OTP as a low-assurance step that must be conditioned on risk signals. A phone number should not be considered trustworthy by default. Before sending or accepting an OTP, teams should evaluate whether the number has signs of SIM swap, recent port-out activity, VoIP characteristics, disposable numbering, or other fraud indicators. That evaluation can be done through telecom intelligence, fraud scoring, or step-up rules in the identity layer.
In mature environments, this means combining authentication with context-aware controls rather than relying on a static allow rule. The organisation may require stronger authentication when the number is newly issued, recently changed, associated with VoIP, or used from an unfamiliar device. This aligns with NIST’s control-first approach in NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially where access decisions depend on current risk rather than a single factor check. NHIMG’s Top 10 NHI Issues shows the same principle in another identity domain: credentials and trust assumptions decay faster than most organisations expect.
- Check number age, SIM tenure, and recent porting history before trusting SMS delivery.
- Block or step up authentication for VoIP, virtual numbers, or high-risk carriers where feasible.
- Use risk-based authentication to replace static “OTP equals verified” logic.
- Prefer phishing-resistant factors for sensitive actions, especially account recovery and admin access.
- Log OTP delivery, verification, and risk-score outcomes for later review.
These controls tend to break down in high-friction customer environments where legacy identity stacks cannot consume telecom risk signals in real time.
Common Variations and Edge Cases
Tighter SMS risk screening often increases user friction and support load, so organisations have to balance account protection against recovery failures and false positives. That tradeoff becomes sharper in consumer services, healthcare portals, and regions where SMS is still the most accessible channel. Current guidance suggests SMS should be phased down for higher-risk use cases, but there is no universal standard for replacing it everywhere at once.
Edge cases matter. A number may be legitimate yet still unsafe because the carrier recently reassigned it. A VoIP line may be acceptable for low-risk notifications but not for step-up authentication. A device may remain the same while the phone number has already been moved to an attacker-controlled SIM. For that reason, teams should separate “delivery succeeded” from “identity verified,” and they should not treat successful OTP entry as proof that the rightful user is present. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is relevant here because it underscores a broader control failure: organisations frequently secure the credential path while ignoring the conditions that make the credential trustworthy in the first place.
For high-value workflows, the practical answer is to use SMS only as a fallback, then add stronger checks such as device binding, policy-based step-up, or out-of-band approval for recovery and privilege changes.
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, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-04 | Authentication strength should match current risk, not the channel alone. |
| NIST SP 800-63 | AAL2 | SMS OTP maps to a weaker authenticator level with known interception risks. |
| NIST AI RMF | Risk-based decisions and monitoring support trustworthy identity outcomes. | |
| NIST Zero Trust (SP 800-207) | SA-3 | Zero Trust requires continuous trust evaluation, not one-time factor checks. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static trust in a credential channel mirrors NHI credential misuse and weak validation. |
Apply strict issuance and validation controls to authentication paths that depend on mutable external trust.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on phishing simulations without a broader human risk management program?
- What breaks when organisations rely on SIM binding without additional identity checks?
- What breaks when security teams rely on passkeys without removing weaker account recovery options?
- What breaks when organisations rely on passwords and OTPs for high-risk access?
