Organisations should prioritise phishing-resistant and device-bound factors for sensitive workflows, especially admin access and transaction approvals. TOTP can be a practical step up, but FIDO2, push authentication, biometric factors, and PKI-based MFA provide stronger assurance. The right choice depends on risk, user population, recovery processes, and whether regulators expect higher assurance for critical use cases.
Why This Matters for Security Teams
SMS 2FA fails most often where organisations need the highest assurance: privileged admin sessions, payment approvals, and regulated customer operations. SMS codes are vulnerable to SIM swap, number porting, message interception, and recovery-path abuse, so the factor can be defeated without touching the account password. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward stronger authentication and tighter control over high-value access paths.
For regulated environments, the issue is not just whether a second factor exists. It is whether the factor resists phishing, device takeover, and social engineering, while still fitting audit, recovery, and segregation-of-duties requirements. That is why organisations increasingly move from SMS to phishing-resistant factors such as FIDO2, PKI-based MFA, or device-bound authenticators, then reserve weaker methods only for low-risk recovery flows. NHIMG research on Ultimate Guide to NHIs shows how weak identity controls often persist because they are convenient, not because they are defensible.
In practice, many security teams discover the weakness of SMS 2FA only after an account takeover, not through a planned assurance review.
How It Works in Practice
Replacing SMS 2FA starts with classifying access by assurance level rather than applying one factor to every workflow. High-risk access should use phishing-resistant authentication for the primary step-up path, with device binding where possible. FIDO2 security keys, certificate-based MFA, and strong push approvals on managed devices can materially reduce replay and interception risk. For regulated access, the control objective is to prove possession of a trusted device or cryptographic key, not just control of a phone number.
A workable pattern is to use the following layers:
- Primary sign-in with passwordless or strong password plus phishing-resistant MFA.
- Step-up authentication for sensitive actions such as wire release, policy changes, or data export.
- Device posture and session risk checks before granting access.
- Fallback recovery that is separate from the main authentication path and tightly supervised.
For operational consistency, organisations should align authentication policy with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls around authentication strength, session protection, and access enforcement. Where user populations include contractors or legacy devices, TOTP may be an interim improvement over SMS, but it still does not fully resist phishing in the way FIDO2 does. For teams building a broader identity program, NHIMG’s Top 10 NHI Issues is useful because it reinforces the same principle: short-lived, context-aware, and tightly governed access is safer than static trust.
These controls tend to break down when recovery processes still depend on the same phone number, help desk workflow, or weak escalation path being replaced.
Common Variations and Edge Cases
Tighter authentication often increases user friction and support overhead, so organisations must balance assurance against operational continuity. That tradeoff is real in regulated environments where field staff, shared kiosks, or contractor populations may not all have managed hardware keys on day one.
Best practice is evolving, but current guidance suggests three common exceptions need special handling. First, SMS may remain as a temporary recovery channel for low-risk users, but it should not be the default for privileged or transaction-critical access. Second, TOTP can serve as a transitional control where device-bound methods are not yet deployable, though it is not the strongest answer against targeted phishing. Third, some regulated sectors require explicit evidence of authentication strength in audit logs, so the chosen factor must be documented, monitored, and periodically reassessed.
Organisations should also separate authentication from authorisation. Strong MFA does not replace least privilege, just as better identity proofing does not excuse broad standing access. In environments with shared workstations, offshore operations, or highly variable device hygiene, even strong factors lose value if sessions are not revalidated and privileged tokens are not constrained. This is why modern programs pair stronger MFA with device trust, step-up policies, and periodic access reviews.
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 Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers weak credential handling and stronger authentication for sensitive access. |
| NIST CSF 2.0 | PR.AC-7 | Supports authentication strength and access enforcement for high-risk workflows. |
| NIST SP 800-63 | Digital identity guidance informs assurance levels and authenticator selection. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust requires continuous verification, not trust in a phone number. |
| NIST AI RMF | Risk governance is needed when authentication is part of broader regulated AI or digital workflows. |
Map regulated access to higher assurance authenticator requirements and document recovery assurance.
Related resources from NHI Mgmt Group
- Why do organisations replace SMS OTP in high-risk journeys before full account-wide migration?
- Why do ephemeral credentials still leave risk in machine access models?
- Should organisations replace symmetric JWT signing in high-risk API flows?
- When should organisations treat machine access as a high-risk identity problem?