Allow both factors only if the user experience and risk model justify the extra choice, then require the user to complete one verified challenge during login. Keep enrollment, challenge creation, and verification separate so each factor remains auditable. Teams should also treat SMS as a convenience factor, not a replacement for stronger authentication where higher assurance is needed.
Why Offering Both TOTP and SMS Changes the Authentication Design
When teams allow both TOTP and SMS, they are not just adding convenience, they are creating two different assurance paths with different strengths, failure modes, and user expectations. The key design question is whether the added choice improves completion rates without weakening the authentication boundary or making verification logic ambiguous. The answer depends on how tightly each factor is enrolled, challenged, and audited.
TOTP and SMS are both common second factors, but they do not carry the same security properties. TOTP is generated from a shared secret and is generally more resistant to interception than SMS, while SMS is vulnerable to number takeover, forwarding abuse, and other telecom-layer weaknesses. Good design therefore treats the factors as alternatives within a controlled policy, not as interchangeable equivalents.
For practitioners, the important distinction is between factor availability and factor strength. If users can choose either option, the system should still enforce one verified challenge at login and record which factor satisfied the step-up. That keeps the authentication event attributable and prevents the login flow from quietly degrading into the easiest available path for every user.
How to Keep Enrollment, Challenge, and Verification Separate
The cleanest implementation separates three stages: enrolling the factor, creating the login challenge, and verifying the response. That separation matters because each stage has a different trust decision. Enrollment confirms that the user controls the phone number or authenticator, challenge creation binds the factor to the current session, and verification proves the response matches the stored enrollment record.
This is where many mixed-factor flows become messy. If a system lets the same endpoint both enroll and verify, or silently swaps between TOTP and SMS without logging the choice, the audit trail becomes weak. Teams should preserve enough evidence to answer a simple question later: which factor was used, under what policy, and did the user actually complete a verified challenge before access was granted?
The user interface should make the factor choice understandable, but the policy decision must remain server-side. If risk is low, either factor may be acceptable. If risk is higher, the login flow should steer the user toward the stronger option and reserve SMS for recovery, fallback, or lower-assurance situations where policy allows it.
What Security Teams Should Optimize For
The right design goal is not to offer the maximum number of factors, but to ensure the assurance level matches the access being requested. Teams should prefer the strongest viable factor for sensitive actions, then use SMS only where the business accepts its lower assurance and compensating controls exist. That is especially important where account recovery, device loss, or help-desk reset flows can otherwise become the easiest path to compromise.
Current guidance also supports keeping the login experience simple enough that users do not abandon it. A factor that looks secure on paper can still fail in practice if it creates support friction or causes users to bypass enrollment. The best balance is usually a clear preference order, visible fallback rules, and explicit logging for factor choice and challenge outcome.
When teams need both options, they should also check whether the policy is consistent across web, mobile, and support-driven recovery paths. A secure primary login with a weak recovery path is still a weak account. The security value comes from consistent enforcement across the full lifecycle, not from the strongest screen in the flow.
Risk and Threat Considerations
Allowing both TOTP and SMS can expand the attack surface if the weaker option becomes the default fallback or if users can repeatedly downgrade assurance during login. The main risk is not the existence of two factors by itself, but inconsistent policy, weak recovery logic, or over-reliance on SMS where stronger assurance is required.
Failure mechanism: Attackers can target the lower-assurance path through SIM swap, number porting, message interception, or social engineering, then use that access to satisfy the login challenge and take over the account. If enrollment and verification are not clearly separated, it also becomes harder to detect whether a factor was legitimately bound to the user or simply accepted through a weak workflow.
Impact: The result can be account takeover, fraudulent access, and loss of confidence in the authentication boundary. In higher-risk systems, the downstream effect is often privilege abuse rather than just a single compromised login, because the attacker can use the session to reset credentials, approve changes, or pivot into more sensitive actions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | The question is about choosing and verifying login factors. |
| V7 — Session Management | The answer depends on a completed challenge before session issuance. | |
| Recommendation — Require a verified authentication flow and document which factor satisfied login. Bind the verified factor to the session before granting access. | ||
| NIST SP 800-63 | Digital Identity Guidelines | It directly informs authenticator choice, assurance, and fallback strength. |
| Recommendation — Prefer stronger authenticators for higher assurance and limit weaker fallback use. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The subject concerns authenticating users during login. |
| IA-5 — Authenticator Management | Enrollment and verification of TOTP or SMS rely on authenticator lifecycle handling. | |
| Recommendation — Enforce a defined authentication policy for user access. Manage authenticator enrollment, rotation, and verification separately. | ||
Practitioner Guidance
What to verify: Confirm that the login policy explicitly decides when SMS is allowed, when TOTP is preferred, and when step-up authentication is required. Verify that the system logs the factor used, the challenge outcome, and the enrollment source so reviews can distinguish legitimate use from fallback behavior.
Decision rule: If the account or action carries meaningful business or security impact, treat SMS as a convenience or recovery option rather than a preferred primary factor. If the environment can support stronger authentication, require it for sensitive access and keep SMS as an exception with clear justification.
Practitioner takeaway: Mixed-factor support is acceptable when the policy is explicit and the audit trail is clean, but security teams should never let convenience factors silently become the normal path for higher-risk access.
Related resources from NHI Mgmt Group
- How should security teams handle TOTP authentication when users want one app for both password management and verification codes?
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams implement Client ID Metadata Documents?
- What do security teams get wrong about SMS verification risk?
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
