Organisations should prefer phishing-resistant authentication for high-value accounts, especially where account takeover would expose files, admin consoles, or customer data. Security keys based on public key cryptography reduce exposure to malware, phishing, and man-in-the-middle attacks because the secret never leaves the device. They also lower reliance on shared infrastructure like mobile networks, which can be a weak point in account recovery and interception scenarios.
Why stronger MFA means changing the authentication model, not just the second factor
Moving beyond SMS or app codes is really a move from shared-secret style login to phishing-resistant authentication. The practical shift is that the authenticator must be bound to the legitimate site or service, not just typed into whatever prompt an attacker can fake. That changes how you think about enrollment, recovery, device binding, and help desk processes.
For high-value accounts, the strongest options are usually security keys or passkeys that use public key cryptography. The private key stays on the device, so there is no reusable code to steal or relay. That makes the control materially stronger against phishing, malware, and adversary-in-the-middle attacks than one-time codes delivered by SMS or authenticator apps.
It also changes the failure model. With SMS or TOTP, the weakness is often the code itself, the channel that carries it, or the user being tricked into entering it. With phishing-resistant methods, the main risks move to device loss, enrollment abuse, recovery abuse, and whether the organisation has designed step-up and fallback paths safely.
Where SMS and app codes still fail in practice
SMS codes can be intercepted, redirected, or defeated through SIM swap and recovery-channel abuse. App codes are better than SMS, but they still rely on the user entering a short-lived secret that can be phished, relayed, or harvested in real time. NHIMG’s MFA Guide is a useful reference for comparing those bypass patterns against phishing-resistant methods.
For organisations, the larger issue is not only the second factor, but the entire account recovery path. If a help desk can reset MFA too easily, or if legacy exceptions remain for remote access and admin consoles, attackers will target those routes instead of the primary login prompt. That is why account takeover frequently succeeds through the weakest fallback, not the strongest factor.
Real incidents show the same pattern: once an attacker can obtain a valid session, coerce an MFA reset, or abuse a legacy account, the original second factor no longer matters. Practical migration planning should therefore treat legacy MFA as a transition state, not a long-term control for privileged or sensitive access. The organisation should be able to say which accounts are still allowed to use weaker methods and why.
What a safe migration to phishing-resistant sign-in looks like
A strong rollout usually starts with the highest-risk populations: administrators, finance teams, developers, support staff, and any user whose account can reach production systems or sensitive data. The Workforce Identity Security Guide is directly relevant here because it ties phishing-resistant MFA to lifecycle, recovery, and session-theft concerns, not just sign-in methods.
Good migration design also means keeping the recovery path as strong as the primary path. If users can enroll a security key but later recover access through weak SMS verification, the control only looks strong on paper. The same applies to admin exemptions, temporary bypasses, and self-service reset workflows that were built for convenience before modern phishing threats became routine.
For many organisations, NIST SP 800-63 Digital Identity Guidelines provides the clearest external baseline for authenticator assurance, phishing-resistant authentication, and recovery expectations. In practice, that means the organisation should align stronger methods to higher-assurance access decisions instead of treating all accounts as if they need the same factor strength.
Risk and Threat Considerations
The main risk in keeping SMS or app codes is that attackers do not need to break cryptography, they only need to intercept, phish, relay, or socially engineer the code path. Once that path exists for high-value accounts, the organisation’s real exposure is account takeover, session theft, and abuse of privileged access.
Failure mechanism: Weak fallback recovery, MFA fatigue, real-time phishing, or SIM-based interception allows the attacker to satisfy the second factor while never proving possession of the legitimate device or user context.
Impact: The attacker can reach admin consoles, file stores, email, or customer data, and may then pivot into resets, impersonation, or deeper privilege abuse if the same account can approve access or change recovery settings.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers phishing-resistant authenticators, assurance levels, and recovery choices for stronger sign-in. |
| Recommendation — Use phishing-resistant authenticators and align recovery rules to the required assurance level. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Organizational accounts need stronger authentication when compromise would expose high-value assets. |
| IA-5 — Authenticator Management | Covers authenticator lifecycle, issuance, rotation, and handling of weaker fallback methods. | |
| Recommendation — Require stronger authentication for organizational users accessing sensitive systems. Manage authenticators so recovery, replacement, and revocation do not weaken access assurance. | ||
| CIS Controls v8 | 5 — Account Management | Account security depends on controlling enrollment, resets, exceptions, and privileged access paths. |
| Recommendation — Tighten account and reset governance for users with elevated access. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Directly addresses secure handling of authentication data and methods during MFA changes. |
| Recommendation — Protect authentication information and restrict weaker fallback channels. | ||
Practitioner Guidance
What to prioritise: Move the strongest methods first to privileged users and accounts that can trigger broad blast radius, then remove legacy MFA exceptions from those same paths. If a login can reach production, treat weak MFA as a temporary exception that needs an owner and a sunset date.
What to verify: Confirm that enrollment, recovery, and help desk workflows are at least as hard to abuse as the primary login. If a user can bypass phishing-resistant sign-in with a simple reset call or alternate channel, the control is not yet trustworthy.
Common mistake: Treating “we have MFA” as a finished outcome. The stronger question is whether the organisation can resist phishing, session theft, and recovery abuse for the accounts that matter most.
Practitioner takeaway: The migration is successful only when the weakest alternate path is removed from the accounts that create the most damage, because attackers will target recovery and fallback before they try to defeat the strongest factor.
Related resources from NHI Mgmt Group
- When does multi-factor authentication still leave organisations exposed to account takeover?
- Why do password and SMS-based factors leave organisations exposed even when multi-factor authentication is enabled?
- Why do multi-factor authentication and biometrics still leave gaps in account security?
- What breaks when multi-factor authentication still relies on SMS codes or push approvals?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
