When should organisations prioritise hardware security keys over SMS or app-based second factors?

Prioritise hardware security keys whenever the service supports them and the account protects sensitive personal, business, or administrative access. SMS is a weaker second factor because it can be intercepted or redirected. Authenticator apps are better than SMS, but security keys offer stronger phishing resistance. The best sequencing is to adopt the strongest supported factor first, then reserve weaker methods only where necessary.

Why hardware security keys deserve priority for high-value accounts

Hardware security keys are the strongest practical second factor when a service supports them because they bind the login to a physical authenticator and resist phishing better than codes that can be read, replayed, or redirected. That matters most where the account can reach sensitive personal data, business systems, admin consoles, or privileged workflows. For workforce identity use cases, this is the pattern NHIMG sees most often in real deployments, especially where workforce identity security includes phishing-resistant MFA, passkeys, and recovery controls.

The practical rule is simple: if the service supports a hardware key and the account is worth protecting, the hardware key should be the default first choice. App-based second factors are usually a better fallback than SMS, but they still leave more room for phishing, push fatigue, device compromise, and prompt-based interception than a cryptographic key.

How SMS and app-based factors compare in real authentication flows

SMS is weakest because it depends on the phone number and the carrier path, not just the device in the user’s hand. That creates exposure to interception, SIM swap, number porting abuse, and social engineering against telecom support. App-based one-time codes remove some of that carrier risk, but they are still phishable and can be captured in a live adversary-in-the-middle flow. By contrast, hardware keys are designed to prove origin and resist replay in a way that one-time codes cannot.

The right comparison is not “is the second factor present?” but “can the factor survive a realistic phishing or account takeover attempt?” If the answer needs to be yes, security keys usually win. If the service does not support them, app-based MFA is the next best compromise, but it should be treated as a transitional control rather than an equivalent substitute.

Where the priority decision becomes operational, not theoretical

The prioritisation point changes with the account’s blast radius. Admin access, finance systems, identity providers, support tooling, cloud control planes, and any account that can reset others should be moved to hardware keys first. For lower-impact consumer accounts, the value is still strong, but the urgency may be lower unless the account is reused, highly visible, or a recovery path can unlock more important services.

This is also where recovery design matters. Organisations should not deploy hardware keys without thinking through backup keys, lost-device recovery, shared admin break-glass access, and help desk procedures. A strong factor that is impossible to recover safely often ends up being bypassed in practice, which defeats the purpose.

Risk and Threat Considerations

Weak second factors fail most often at the edges of the login journey: phishing, SIM swap, push fatigue, malicious session reuse, and account recovery abuse. The highest risk is not the password alone, but the combination of a phishable factor with a recovery path that lets an attacker reset access after the initial challenge.

Failure mechanism: SMS can be redirected through telecom abuse, app codes can be captured in real time, and both can be defeated if an attacker convinces a user or support desk to hand over recovery access or approve a fraudulent prompt.

Impact: Account takeover can expose email, payroll, finance, cloud, and admin systems, and can also become a pivot into password resets, token theft, and wider organisational compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Covers stronger user authentication for privileged and workforce accounts.
	IA-5 — Authenticator Management	Addresses lifecycle and protection of authenticators, including keys and fallback methods.
	IA-8 — Identification and Authentication (Non-Organizational Users)	Applies when external or customer accounts need stronger second-factor choices.
Recommendation — Require phishing-resistant authentication for accounts with elevated access. Manage authenticators with secure issuance, backup, rotation, and revocation. Use stronger authentication options for external accounts that protect sensitive access.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication and Access Control	Directly supports choosing stronger authentication for sensitive access paths.
Recommendation — Adopt phishing-resistant authentication for high-value accounts and services.
CIS Controls v8	CIS-6 — Access Control Management	Supports tightening access paths and reducing weak second-factor exposure.
Recommendation — Apply access-control policies that favor stronger authenticators for privileged accounts.
ISO/IEC 27001:2022	A.8.5 — Secure Authentication	Directly covers secure authentication choices such as hardware keys over weaker factors.
Recommendation — Select authentication methods that resist phishing for sensitive systems.

Practitioner Guidance

What to prioritise: Put hardware security keys first on accounts that can materially change business, administrative, or identity state, then expand outward from the most privileged and most exposed users. If a service offers keys and the account matters, treat “optional” as a signal to choose the stronger option, not to defer it.

What to verify: Confirm that recovery is equally strong, because weak fallback paths often become the real attack surface. Backup keys, break-glass procedures, and help desk verification should be tested before broad rollout, especially for administrators and support staff.

Practitioner takeaway: The right question is not whether SMS or app-based MFA is acceptable in the abstract, it is whether the account can afford a phishable factor; for any high-value account, the answer is usually no.