How should security teams choose between SMS MFA, authenticator apps, and security keys?

Start with the sensitivity of the system and the attack paths you most need to stop. SMS and email are easy to deploy but weakest against interception and account takeover. Authenticator apps are stronger but can suffer from push fatigue. Security keys offer the best resistance to phishing for high-value access, especially for admins and other privileged users.

Why This Matters for Security Teams

Choosing an authentication factor is really a choice about which attack paths the organisation is most willing to tolerate. SMS MFA is easy to roll out, but it offers weak resistance to SIM swap, interception, and social engineering. Authenticator apps improve the bar, yet approval-based flows can still be abused through fatigue and prompt bombing. Security keys are the strongest option for phishing-resistant access, especially where privileged sessions or external exposure raise the stakes. Current guidance from NIST SP 800-63 Digital Identity Guidelines continues to favour phishing-resistant authenticators for higher assurance use cases.

The practical issue is not whether MFA exists, but whether the factor meaningfully blocks the likely compromise path. That matters most for admin consoles, VPNs, cloud control planes, and any system reachable from unmanaged endpoints. In NHI Management Group research, the State of Non-Human Identity Security found that only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a reminder that identity controls often lag behind real-world attack complexity. In practice, many security teams discover the weakness of their chosen MFA method only after a phishing campaign or help-desk bypass has already succeeded, rather than through intentional testing.

How It Works in Practice

A defensible selection process starts with risk, not convenience. Teams should map each access path to the attacker behaviour they most need to stop, then assign the strongest factor that is proportionate to that risk. For low-sensitivity employee portals, SMS or app-based MFA may be acceptable as a transitional control. For privileged admin access, finance systems, source control, and remote access, security keys are usually the better fit because they bind authentication to the origin and resist credential replay more effectively.

For implementation, the most reliable pattern is tiered assurance:

• Use SMS only where adoption friction would otherwise block any MFA at all, and treat it as temporary.
• Use authenticator apps for general workforce access when push fatigue and approval abuse are monitored and reduced.
• Use security keys for privileged users, break-glass paths, and any workflow exposed to phishing or consent attacks.
• Combine MFA choice with conditional access, device posture, and session controls so the factor is not doing all the work alone.

This is also where identity governance matters. NHI Management Group guidance in the Microsoft Midnight Blizzard breach and related research shows how identity abuse escalates once attackers reach trusted access paths. The same logic applies to human MFA: if the factor can be socially engineered, replayed, or approved under pressure, it is not enough for high-value access. These controls tend to break down when legacy applications cannot support modern phishing-resistant authenticators because organisations then preserve weaker MFA for the most sensitive systems instead of the least sensitive ones.

Common Variations and Edge Cases

Tighter authentication often increases user friction, support load, and hardware management overhead, requiring organisations to balance resistance to phishing against operational simplicity. That tradeoff is real, especially in large or distributed workforces where device enrolment, lost tokens, and recovery flows can become bottlenecks. There is no universal standard for every environment yet, but current guidance suggests that the more sensitive the system, the less acceptable SMS becomes as a long-term control.

Two edge cases matter most. First, authenticator apps are not automatically strong if the deployment still relies on push approval without number matching, device binding, or rate limiting. Second, security keys are not a silver bullet if recovery is weak, because attackers often target reset workflows when direct phishing fails. For that reason, best practice is evolving toward layered assurance: phishing-resistant MFA for high-value roles, stronger identity proofing for recovery, and tighter monitoring for anomalous enrolment or factor changes. For a broader governance lens on identity exposure and control gaps, the Ultimate Guide to NHIs is useful context even though this question is about human authentication. In practice, teams usually regret under-choosing authentication strength only after a privileged account has been taken over and recovery is suddenly the hardest part.

Related resources from NHI Mgmt Group

• How should security teams choose between API keys, Device Flow, and Client Credentials for CLI apps?
• How should security teams choose between self-signed and CA-signed SAML certificates?
• How should security teams choose between FIDO and certificate-based authentication?
• How should security teams decide between certificate-based authentication and MFA?