How do IAM teams decide between FIDO2, TOTP, and SMS codes?

Use FIDO2 where phishing resistance matters most, TOTP where hardware keys are not yet practical, and avoid SMS for anything high risk because SIM-swap abuse weakens it. The decision should follow the sensitivity of the account and the recovery burden you can actually support.

Why This Matters for Security Teams

IAM teams are not really choosing between three equally secure login methods. They are choosing between three very different trust and recovery models. FIDO2 gives phishing resistance and strong device-bound authentication, TOTP gives broad compatibility with moderate assurance, and SMS trades convenience for a well-known compromise surface. NIST SP 800-63 Digital Identity Guidelines frames this as an assurance and authenticator-selection problem, not just a user-experience decision.

The risk shows up when organisations apply the same MFA standard everywhere, then discover that some accounts can be recovered too easily while others are too hard to support at scale. NHIMG’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which is a reminder that identity controls fail when they are harder to operate than attackers find them to abuse. For human accounts, the same operational reality applies: if recovery is weak, users bypass policy; if recovery is too costly, support teams create exceptions.

In practice, many security teams encounter MFA weakness only after phishing, number-porting, or account recovery abuse has already occurred, rather than through intentional design.

How It Works in Practice

Most IAM teams should decide by matching authenticator strength to account sensitivity, then checking whether recovery and enrollment can actually be supported. FIDO2 is the best default for administrators, finance users, developers with production access, and any account exposed to phishing or help-desk takeover. TOTP is usually the fallback where hardware keys are not yet practical, such as large contractor populations, legacy apps, or environments that still depend on shared enrollment workflows. SMS should be treated as a last resort for low-risk use cases only.

In operational terms, the decision is less about which factor is “better” in the abstract and more about what attack path remains available after login. FIDO2 binds authentication to a cryptographic key and a user gesture, which sharply reduces phishing replay. TOTP still depends on a shared secret and a code that can be relayed, intercepted, or coerced. SMS relies on the phone number and carrier process, which makes it vulnerable to SIM-swap and message interception. NIST’s guidance is clear that authenticator strength and recovery channels should be considered together, because a strong login factor can be undone by a weak reset process.

• Use NIST SP 800-63 Digital Identity Guidelines to map the required assurance level before selecting the factor.
• Prefer FIDO2 for privileged, remote, and high-phishing-risk accounts.
• Use TOTP only where hardware key rollout, device binding, or browser support is still incomplete.
• Avoid SMS for administrative access, production systems, and any account with meaningful blast radius.
• Align account recovery with the chosen factor, or the weakest recovery step becomes the effective authenticator.

NHIMG’s 2024 Non-Human Identity Security Report found that only 19.6% of security professionals are strongly confident in their organisation’s ability to securely manage non-human workload identities, which reflects a broader identity-operations maturity gap. These controls tend to break down in distributed enterprises with inconsistent help-desk procedures and mixed device fleets because recovery and exception handling become the easiest way around policy.

Common Variations and Edge Cases

Tighter MFA policy often increases enrolment and recovery overhead, requiring organisations to balance phishing resistance against user friction and support capacity. That tradeoff matters most in environments with frontline workers, shared kiosks, unmanaged devices, or users who cannot reliably carry a hardware key.

There is no universal standard for every application class, so current guidance suggests tiering by risk rather than mandating one authenticator across the board. For example, a payroll administrator and a low-risk self-service portal user do not need the same control profile. TOTP may be acceptable for moderate-risk accounts where FIDO2 rollout is delayed, but it should usually be paired with strong recovery verification and step-up controls. SMS can still appear in legacy environments, yet it is increasingly hard to justify once an organisation has any meaningful phishing exposure. The key issue is not only initial authentication, but whether the authenticator can withstand social engineering, help-desk compromise, and account recovery abuse.

For teams comparing rollout paths, NHIMG’s Azure Key Vault privilege escalation exposure and JetBrains GitHub plugin token exposure are useful reminders that identity controls fail fastest when attackers can pivot from one weak trust path to another. In practice, the right answer is often FIDO2 for privileged access, TOTP for transitional coverage, and SMS only where business tolerance for account compromise is genuinely low-impact.

Related resources from NHI Mgmt Group

• How should security teams decide between authentication and governance IAM tools?
• How should IAM teams decide between authentication controls and governance controls?
• How should IAM teams decide between SSO and federated authentication?
• How should IAM teams decide between SaaS and self-managed identity software?