How should organisations choose between push notification MFA, TOTP, SMS codes, and physical keys when rolling out MFA at scale?

Choose the factor that balances security, usability, and deployment effort for your environment. Push notifications and TOTP both improve on passwords, but push is usually easier for end users because they approve a prompt instead of copying a code. SMS is more convenient than passwords alone but adds exposure through the phone network, while physical keys offer strong protection but higher cost and administration overhead.

How to compare MFA factors at rollout scale

The right choice is not just about strength in isolation. Organisations need to compare phishing resistance, user friction, recovery complexity, device dependency, help desk burden, and how well each factor fits workforce, contractor, and privileged-access use cases. The best answer often differs by population, risk tier, and whether the factor must survive account recovery pressure.

Push and TOTP are both workable for broad deployment, but they solve different operational problems. Push is simpler for many users, while TOTP avoids dependence on mobile network delivery. For scale, the real question is whether the chosen factor can be supported reliably through onboarding, reset, lost-device handling, and exception management.

Physical keys are usually the strongest option where compromise tolerance is low, especially for admins and high-value accounts. They raise the bar against phishing and push fatigue, but the trade-off is procurement, distribution, spares, and recovery planning. SMS remains the easiest to roll out, but it is generally the weakest option among these four when attacker resistance matters.

What each factor changes in practice

Push MFA shifts the burden from code entry to prompt approval, which improves adoption but creates exposure to fatigue attacks and social engineering if the push is not bound to a strong authenticator experience. It is often best treated as a usability win, not as the final endpoint for the highest-risk users.

TOTP removes reliance on telecom delivery and works well across mixed device estates, but it still depends on the user correctly entering a six-digit code and on the seed being protected. It is usually a reasonable step up from passwords alone, but it is not phishing-resistant in the same way as a hardware-backed factor.

SMS codes are easy to understand and deploy, which is why they survive in many legacy environments, yet they inherit risks from SIM swap, number takeover, and interception paths outside the organisation’s direct control. Physical keys, especially when paired with phishing-resistant authentication, give the strongest practical assurance for accounts where compromise would be disproportionately harmful.

For many programmes, the most important design decision is not a single universal factor but a policy hierarchy. The stronger the account’s blast radius, the more the factor should move toward phishing resistance and hardware-backed proof, while lower-risk populations may justify simpler factors if operational constraints are real.

Choosing a factor by user population and operational burden

At scale, factor choice should be aligned to population and recovery model. Workforce users usually need a balance of adoption and supportability, contractors may need simpler enrollment and faster offboarding, and administrators or sensitive-role users generally merit a stricter standard than the rest of the population.

Where help desk capacity is limited, the hidden cost is often recovery, not enrollment. Push and SMS can create more reset and reassignment pressure if users change phones frequently or lose access to the original device. Physical keys reduce some attack paths but increase logistics, stock management, and exception handling when a key is forgotten or damaged.

If the environment includes remote access, privileged tools, or high-value internal systems, the factor should be chosen to minimise reliance on shared human judgement during authentication. That usually means limiting SMS and considering stronger, phishing-resistant options for the accounts most likely to be targeted.

Risk and Threat Considerations

Different MFA factors fail in different ways, and those failure modes matter more than the marketing label. The main security question is not whether a factor is better than passwords alone, but whether it can resist the attack paths most likely in your environment, including phishing, prompt bombing, telecom compromise, and recovery abuse.

Failure mechanism: Push MFA can be defeated by repeated approval requests, TOTP can be stolen through real-time phishing, SMS can be diverted through SIM swap or phone-number compromise, and physical keys can still be undermined if recovery and enrollment processes are weak.

Impact: If the chosen factor is easy to bypass or reset, attackers gain a path to account takeover without needing to break the password directly. That turns the MFA programme into a partial control that may still leave privileged accounts, support channels, and downstream systems exposed.

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 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	MFA factor selection hinges on authenticator assurance and phishing resistance.
Recommendation — Choose authenticators by required assurance level and prefer phishing-resistant methods for sensitive accounts.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Workforce MFA rollout is directly about authenticating organizational users.
	IA-5 — Authenticator Management	Scale MFA depends on enrollment, storage, reset, and replacement of authenticators.
Recommendation — Apply multi-factor authentication for organizational users and align factor strength to account risk. Manage authenticator lifecycle tightly, including issuance, rotation, recovery, and revocation.
CIS Controls v8	CIS-5 — Account Management	Choosing MFA at scale affects account onboarding, recovery, and access control operations.
Recommendation — Standardize account and authenticator management so stronger factors remain supportable at scale.
OWASP Non-Human Identity Top 10	NHI-04 — Insecure Authentication	Push, TOTP, SMS, and keys are competing authentication methods with different bypass risks.
Recommendation — Prefer stronger authentication methods and remove weak fallback paths that enable account takeover.

Practitioner Guidance

What to prioritise: Use phishing resistance and blast radius as the primary decision criteria for high-value accounts, then use convenience and supportability to decide where lower-assurance factors are acceptable. A factor that is easy to deploy but easy to abuse is usually the wrong default for privileged or externally reachable users.

What to verify: Test the full lifecycle, including enrollment, replacement, lost-device recovery, and help desk resets. Many MFA programmes fail at the recovery layer, where attackers can exploit weaker identity checks to rebind a factor more easily than they can bypass the factor itself.

Practitioner takeaway: Roll out the strongest factor where the account’s impact justifies it, then standardise the recovery process so the organisation does not weaken the control while trying to support it.