Security teams should choose the second factor based on both resistance to interception and everyday usability. Push prompts and authenticator apps are usually easier than security keys, while security keys offer stronger phishing resistance. SMS is the weakest option because it depends on the phone network and is more exposed to abuse. The best choice is the one users will actually keep enabled consistently.
Choosing a second factor that users will accept and attackers cannot easily reuse
The right second-factor method is a balance between assurance and adoption. If a control is too difficult, users route around it, delay enrollment, or generate help desk pressure that weakens the overall security posture. If it is too weak, it adds a false sense of protection. For this question, the practical issue is not whether multifactor authentication is good in theory, but which method gives meaningful resistance to interception, replay, and phishing while still fitting normal login behaviour.
That trade-off is why organisations should compare second factors by how they fail in the real world, not only by how they look on paper. A method that is consistently used is usually more valuable than a stronger method that is rarely enabled. NIST’s control guidance on authentication and access enforcement is a useful baseline for thinking about that balance in operational terms, especially when policies must work across a mixed user population and different application risk levels. In practice, many security teams discover the weakness of their chosen second factor only after users begin bypassing it or support teams are forced to make exceptions.
How organisations should compare the main second-factor options
Second-factor choice should start with the threat model and then move to the user journey. If the main concern is phishing and session theft, methods that bind the approval to the login context are stronger than methods that only prove possession of a phone number. If the main concern is rollout speed, recovery complexity, or broad employee acceptance, a more convenient method may be the better operational choice, provided the residual risk is understood.
Push-based approvals and authenticator apps usually reduce friction because most users already understand smartphone-based prompts. They are often easier to deploy at scale, but the organisation still has to think about prompt fatigue, device loss, and account recovery. Security keys are more resistant to phishing because they rely on cryptographic proof rather than a one-time code that can be relayed, but they introduce physical handling, procurement, replacement, and user education overhead. SMS is often chosen for convenience, but it remains the weakest mainstream option because it depends on the phone network and is more exposed to interception, SIM swap abuse, and recovery-path abuse.
- Use a stronger factor when the account protects privileged systems, sensitive data, or administrative functions.
- Use a lower-friction factor when broad adoption matters, but only if the remaining risk is acceptable and monitored.
- Require a recovery method that is at least as controlled as the primary second factor, or the account will inherit the weakness of the fallback path.
- Review whether the same factor should be allowed for all user groups, because executives, admins, contractors, and customers often need different assurance levels.
The choice becomes most reliable when organisations measure actual enrolment, failure rates, and exception handling rather than assuming the strongest method will always be the safest operationally. NIST Cybersecurity Framework 2.0 is helpful here because it reinforces the need to align authentication practice with broader access governance and resilience objectives. Where teams cannot support the recovery path cleanly, the “strongest” option may create more risk than it removes.
Common edge cases that change the answer
Tighter second-factor controls often increase enrolment and recovery overhead, so organisations have to balance stronger phishing resistance against the friction that drives abandonment or exception requests.
Shared devices, frontline workforces, contractors, and high-turnover populations often change the decision. A method that works well for office staff may fail in environments where phones are not always available, where staff cannot install apps, or where device management is inconsistent. In those cases, the issue is not just user preference; it is whether the control can be supported reliably without creating bypasses.
There is also a genuine trade-off between usability and account assurance. Industry consensus is clear that SMS should not be treated as a preferred strong factor, but there is less consensus on whether push prompts or authenticator apps are the best default for every organisation. The answer depends on whether the bigger risk is phishing resistance, device lifecycle management, or recovery burden. For higher-risk access, a security key or equivalent phishing-resistant method is usually the better long-term choice, even if it requires a more deliberate rollout.
Another edge case is fallback design. If password reset, help desk identity checks, or backup codes are weaker than the main factor, attackers often target the recovery route instead of the sign-in screen. That is why the safest factor choice can fail when the surrounding process is left unattended. The best method is not simply the one with the strongest cryptography; it is the one whose enrolment, recovery, and exception paths remain enforceable at scale.
Risk and Threat Considerations
The main risk is choosing a second-factor method that looks protective but is still easy to bypass through phishing, interception, or recovery abuse. Low-friction methods can also create hidden exposure if they encourage broad exceptions, weak fallback paths, or overreliance on a phone number as proof of identity.
Failure mechanism: Attackers typically succeed when they can relay a one-time code, trick a user into approving a prompt, abuse SIM swap or number takeover, or pivot into a weaker reset path. In practice, the control often fails at the boundary between the second factor and the account recovery process rather than at the sign-in screen itself.
Impact: A compromised second-factor path can lead to account takeover, persistence through repeated sign-in, access to privileged systems, and loss of confidence in the organisation’s authentication model. When the factor is weak across many users, the result is also systemic, because one design decision creates repeated exposure rather than a one-off incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-1 — Identity Management, Authentication, and Access Control | Second-factor choice directly affects authentication assurance. |
| Recommendation — Select an authentication method that matches the account's required assurance level. | ||
| CIS Controls v8 | 6.3 — Access Control Management | Method selection and enforcement are part of controlling account access paths. |
| Recommendation — Apply strong authentication requirements to protect sensitive accounts and services. | ||
| MITRE ATT&CK | T1110 — Brute Force | Weak second factors can be bypassed through credential and prompt abuse paths. |
| Recommendation — Harden authentication paths that attackers can abuse to gain account access. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | The question concerns selecting an authenticator with stronger account protection. |
| Recommendation — Choose an authenticator that satisfies the assurance needed for the account's risk. | ||
Practitioner Guidance
What to prioritise: Decide first whether the account set needs phishing resistance or mainly needs a practical uplift over password-only access. That distinction should drive the choice more than internal preference for the easiest rollout.
What to verify: Test the recovery and exception process before standardising the factor. If a help desk can reset access too easily, the effective assurance level is set by recovery, not by the second factor itself.
Decision rule: Use the most phishing-resistant method the user population can sustain consistently. If adoption will be poor, a slightly weaker but durable method is usually better than a stronger method that users ignore or bypass.
Practitioner takeaway: The best second factor is the one that survives everyday use, because consistent enforcement matters more than theoretical strength when attackers target the weakest operational path.
Related resources from NHI Mgmt Group
- How should organisations implement PSD2 controls without adding too much checkout friction?
- How can IAM teams make authentication stronger without adding too much friction?
- How should government teams reduce resident account takeover without adding too much login friction?
- How should small and midsize organisations reduce the risk of credential compromise without adding too much friction for users and admins?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
