Should organisations still accept SMS and OTP for business access?

When SMS and OTP are acceptable, and where they stop being good enough

SMS and OTP can still be acceptable as a transitional factor for low-impact access, but they should not be treated as a durable default for anything that can expose customer data, internal systems, finance workflows, or administrative functions. The core issue is not convenience versus security, it is whether the factor can withstand realistic interception, SIM-swap, phishing, and social-engineering pressure.

Once a login unlocks privileged actions, sensitive records, or lateral movement into internal applications, the assurance gap becomes material. At that point, a factor that can be relayed or tricked from the user is often weaker than the business consequences it is meant to protect.

Why SMS and OTP fail as a long-term baseline

SMS-based authentication depends on mobile carrier routing, device possession, and user attention, all of which are fragile compared with phishing-resistant methods. OTPs delivered by text or generated from shared secrets can also be harvested in real time, replayed through adversary-in-the-middle phishing, or obtained after account recovery abuse. For MFA Guide, these are not edge cases, they are the normal failure modes practitioners should assume.

The practical weakness is that the factor may prove only that someone can receive a code or trick a user into reading one back, not that the authentic user is present in a way that resists interception. That is tolerable for low-risk access where the blast radius is small, but it is a poor fit where the login itself protects high-value data or administrative control.

What a sensible access policy should require instead

A stronger policy separates access by business impact. Low-risk self-service access may keep SMS or OTP as an interim control, but anything involving admin roles, internal applications, payment actions, or sensitive data should move to phishing-resistant MFA such as passkeys, hardware keys, or certificate-backed methods. That direction aligns with broader control expectations in CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls, both of which push organisations toward tighter account and access governance.

For business access, the useful question is not whether SMS or OTP can work, but whether the organisation can justify them as proportionate to the consequence of compromise. If the answer is no, the control should be treated as temporary, not strategic.

How to decide when to keep, replace, or retire them

The decision should be based on risk concentration and recovery difficulty. If a compromised login could expose privileged actions, internal SaaS, support tooling, or regulated data, the factor should be phased out rather than merely supplemented. If the use case is constrained, the account is low privilege, and stronger methods are not yet feasible for a defined reason, SMS or OTP can remain in place with a clear retirement path.

There is also a lifecycle issue: organisations often keep SMS or OTP because migration is hard, not because the control is still acceptable. That is a governance problem, not a technical one. Standards such as ISO/IEC 27001:2022 Information Security Management and NIST Cybersecurity Framework 2.0 are useful here because they frame authentication as a managed control choice, not a permanently tolerated exception.

Risk and Threat Considerations

SMS and OTP are exposed to interception, social engineering, SIM-swap abuse, and real-time phishing relay. The danger rises sharply when the same factor protects admin consoles, internal systems, or data-rich applications, because a single successful capture can become immediate privilege misuse or account takeover.

Failure mechanism: An attacker either redirects the code, persuades the user to reveal it, or relays it through a live phishing session, then uses the resulting session to access the business application as the victim.

Impact: The compromise can reach far beyond the initial login, including data theft, fraudulent actions, support-channel abuse, privilege escalation, and lateral movement into connected systems.

Practitioner Guidance

What to prioritise: Classify every application by compromise impact, then remove SMS and OTP first from the highest-impact access paths. Focus on admin portals, finance workflows, internal business tools, and any system where a session token or authenticated action has meaningful consequence.

Decision rule: If the account can approve, modify, export, or administer anything material, treat SMS and plain OTP as an interim exception only. If the account is low impact and migration blockers are real, keep it under a dated exception with a defined replacement plan.

What to verify: Confirm that the alternative factor is phishing-resistant, that recovery paths are equally strong, and that helpdesk reset processes do not quietly reintroduce the same weakness. Weak recovery often defeats strong login policy.

Practitioner takeaway: SMS and OTP are acceptable only when the business consequence of compromise is genuinely low; once access can change state, expose data, or reach administration, they stop being a safe baseline and become a migration liability.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• What should organisations do when SMS OTP is still used for account recovery?
• When do short-lived access tokens still leave organisations exposed?
• How can organisations reduce over-privileged OAuth access without breaking business workflows?