Why do SMS-based MFA flows create more risk than TOTP in custom auth systems?

SMS depends on a transport channel that can be intercepted through SIM swap, phishing, or malware, so it is weaker as a primary factor. TOTP reduces exposure by keeping the second factor tied to a shared secret and a local authenticator app, which is easier to govern as a controlled identity artefact.

Why This Matters for Security Teams

SMS-based MFA looks convenient, but it inherits the risks of a public telephony channel that is outside the application’s trust boundary. In custom auth systems, that means the second factor can be undermined by SIM swap, SMS interception, device malware, or account recovery abuse before the app ever sees a valid challenge response. By contrast, TOTP keeps the verifier tied to a locally generated code from a shared secret, which is easier to govern as an identity artefact and align with the NIST Cybersecurity Framework 2.0.

The operational issue is not simply that SMS is “less secure” in the abstract. It is that custom authentication teams often treat the channel as a factor while ignoring how easily phone-number control shifts over time. That makes assurance weak during onboarding, recovery, and step-up authentication. NHI Management Group’s Ultimate Guide to NHIs shows why identity controls fail when long-lived credentials and weak visibility are tolerated. In practice, many security teams encounter SMS abuse only after fraud or account takeover has already occurred, rather than through intentional control design.

How It Works in Practice

In a custom auth flow, the difference comes down to what the system can actually verify at runtime. SMS-based MFA depends on the telecom ecosystem proving possession of a phone number, which is an unstable proxy for identity. TOTP, by contrast, verifies possession of an enrolled authenticator and a shared secret that never needs to traverse the network after provisioning. That makes TOTP easier to model as a controlled secret, especially when paired with rotation, device binding, and recovery controls.

For security teams, the practical question is how the factor is enrolled, stored, and recovered. A sound implementation usually includes:

• Strong enrollment proofing before the shared secret is issued.
• Encrypted secret storage and clear recovery revocation paths.
• Short validity windows for codes and rate limits on verification attempts.
• Step-up policies for risky actions such as password resets or new-device enrollment.
• Monitoring for impossible travel, SIM change signals, and repeated recovery requests.

Where this matters most is in custom systems that still rely on SMS for backup access. The architecture may look simple, but every exception expands the attack surface. NHI Management Group’s Top 10 NHI Issues highlights how weak lifecycle controls and poor visibility turn identity mechanisms into persistent risk. For implementation guidance on digital identity assurance, teams often pair this with NIST SP 800-63B and the factor management guidance in CISA’s phishing-resistant MFA resources. These controls tend to break down when legacy recovery workflows still allow phone-number ownership to override stronger assurance signals.

Common Variations and Edge Cases

Tighter authentication often increases user friction and support overhead, so organisations have to balance phishing resistance against recovery complexity. That tradeoff is especially visible when users lose devices, travel internationally, or operate in low-connectivity environments. Current guidance suggests that TOTP is usually safer than SMS, but there is no universal standard for every recovery scenario, and some high-assurance environments now prefer phishing-resistant methods over both.

There are also cases where SMS remains in the stack as a temporary fallback, but it should be treated as a degraded path with tighter limits, not equivalent assurance. In regulated or high-risk environments, teams should prefer authenticator apps, hardware-backed factors, or platform-bound sign-in where available. If the custom auth system also protects service accounts, API keys, or agent workflows, the same lifecycle discipline applies to secrets and identity artefacts, as discussed in NHIMG’s Key Challenges and Risks section. Best practice is evolving, but the direction is clear: reduce dependency on channels that can be reassigned outside the application’s control, and reserve SMS only for the narrowest possible fallback use. This guidance breaks down when the recovery process itself is the primary attack path because the factor choice cannot compensate for weak account restoration rules.

Related resources from NHI Mgmt Group

• Why does SMS-based MFA still create account takeover risk?
• When does MFA create enough assurance for high-risk access?
• When does certificate-based authentication create more risk than it reduces?
• When do backup MFA codes create more risk than they reduce?