SMS-based 2FA sends a one-time code over the mobile network, which makes it easy to use but vulnerable to SIM swapping and message interception. Authenticator apps generate codes locally on the device, so they do not depend on carrier delivery. That usually gives stronger protection, especially against remote attackers targeting phone numbers.
How SMS-based codes and authenticator app codes differ in practice
SMS-based two-factor authentication delivers a one-time code through the phone network, so the factor is tied to carrier delivery and the phone number itself. Authenticator app codes are generated on the device from a shared secret or time-based seed, so they can be produced even when the phone has no signal. The security difference is really about where the code comes from and how easily an attacker can intercept it.
That distinction matters because SMS introduces telecom dependencies that users do not control. A stolen number, redirected message, or compromised carrier account can expose the code path even when the password remains secret. App-based codes remove the carrier from the loop, but they still rely on the phone or device staying protected from malware, theft, or account recovery abuse.
Why authenticator apps are usually stronger against remote attackers
For most common account-takeover attempts, authenticator apps raise the attacker effort. They are not sent over a public messaging channel, so a remote attacker cannot simply phish or intercept a text message from the network. That makes them a better default for reducing risk from credential stuffing, phishing kits, and SIM swap style attacks.
SMS can still be useful as a fallback or for lower-risk accounts, but it is not the preferred option when the account protects sensitive data or privileged access. If the goal is to reduce dependence on a phone number as an identity recovery path, app codes are the better choice, and phishing-resistant methods such as passkeys are stronger still.
For a practical view of why SMS-based flows get abused, see Twilio 0ktapus breach 2022, Uber Breach, and Colonial Pipeline ransomware attack.
What each method still does not solve
Neither SMS codes nor authenticator app codes are immune to phishing if a user is tricked into entering the code into a fake login page. Both are also weaker than phishing-resistant authentication because a code can often be replayed in real time. Authenticator apps improve the transport path, but they do not automatically stop adversary-in-the-middle attacks or session theft after login.
That is why the right comparison is not “secure versus insecure,” but “less exposed versus more exposed.” SMS usually has the larger attack surface because it depends on phone-number control and message delivery. App codes narrow that exposure, yet they still rely on good device hygiene, strong recovery controls, and careful step-up authentication design.
For implementation guidance on stronger sign-in options, see Passwordless and Passkeys Guide, Workforce Identity Security Guide, and Microsoft Midnight Blizzard breach.
Risk and Threat Considerations
The main risk with SMS-based 2FA is that the second factor can be attacked through the telecom layer rather than the account itself. SIM swapping, number port-out fraud, SMS interception, and social engineering against the carrier can all defeat the protection even when the user has a strong password.
Failure mechanism: The attacker redirects or intercepts the texted one-time code, then uses it to complete login or reset access.
Impact: Account takeover can follow, especially where SMS also protects password reset, recovery, or privileged access flows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines authenticator assurance and comparative strength of SMS versus app-based authenticators. |
| Recommendation — Use phishing-resistant authenticators for higher-assurance accounts and limit SMS to low-risk fallback paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers issuing, protecting, and replacing authenticators used by SMS and app-based 2FA. |
| IA-2 — Identification and Authentication (Organizational Users) | Applies because the comparison is about user authentication strength for workforce access. | |
| Recommendation — Manage authenticators with rotation, revocation, and recovery controls that reduce takeover risk. Require stronger authentication for user access to sensitive systems and step-up where risk rises. | ||
| OWASP ASVS | V6 — Authentication | Directly addresses authentication mechanisms, including OTP-based and app-based login factors. |
| V10 — OAuth and OIDC | Relevant when codes support modern sign-in flows and authentication assurance decisions. | |
| Recommendation — Prefer stronger authentication requirements and avoid relying on SMS where better factors are available. Align factor choice with the assurance level required by the sign-in flow. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Supports enforcing stronger access methods for sensitive accounts and reducing weak recovery paths. |
| Recommendation — Restrict high-risk accounts from using weaker authentication paths and review recovery dependencies. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Applies to controlling who can authenticate and under what conditions across systems. |
| A.8.5 — Secure authentication | Directly addresses the security of authentication methods such as SMS and authenticator apps. | |
| Recommendation — Set access rules that require stronger authentication for sensitive or privileged access. Select secure authentication methods and reduce reliance on easily intercepted channels. | ||
Practitioner Guidance
What to verify: Treat SMS as a lower-assurance factor unless you have a documented reason to keep it. Confirm whether it is used for primary login, step-up authentication, or account recovery, because recovery use is often the higher-risk dependency.
Decision rule: If the account protects production systems, finance, admin access, or customer data, prefer authenticator apps or stronger phishing-resistant methods and reserve SMS for fallback only when no better option is practical.
Practitioner takeaway: The meaningful choice is not just “text versus app,” it is whether the second factor can be abused through the phone-number path. Removing that dependency is the real security gain.
Related resources from NHI Mgmt Group
- What is the difference between SIM-based authentication and SMS two-factor authentication?
- What is the difference between a push-based prompt and an authenticator app for two-step verification?
- What is the difference between password pasting support and two-factor authentication in app login security?
- What is the difference between SMS OTP and authenticator-app OTP?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
