Start by identifying where the organisation still depends on phishable factors such as SMS OTP, TOTP, push approval, or email codes. Then prioritise the accounts and applications where a single compromised session would create the largest operational or financial impact. The first move is to reduce reliance on fallback paths, not to add more prompts.
Where to start when MFA is still the default
The first step is not “add another MFA prompt.” It is to map which sign-in paths still depend on factors that attackers can phish, relay, fatigue, or intercept, then rank the accounts and applications by the damage a single compromised session could cause. That usually exposes where fallback authentication and account recovery are doing more security work than the primary control.
Teams should treat traditional MFA as a stopgap unless they understand where it is still the best available control. In many environments, the real risk is not the presence of MFA itself, but the combination of legacy factors, permissive recovery, and high-value sessions that can be hijacked even when a login technically succeeds.
That is why phishing-resistant sign-in is the real target state, and why the transition should start with the weakest paths first. NIST SP 800-63 Digital Identity Guidelines is a useful reference point for authenticator strength and phishing-resistant approaches, while Passwordless and Passkeys Guide explains how passkeys and FIDO2 change the default from “approve a login” to “prove possession of a bound authenticator.”
Why fallback paths matter more than extra prompts
Fallback paths are where default MFA often loses most of its value. SMS OTP, TOTP, push approval, email codes, and help-desk resets can all become the practical bypass route even when the front-door login looks well defended. If those paths remain easy to abuse, the organisation has not really reduced phishing exposure, it has moved it into recovery and exception handling.
This is also why account priority matters. A lower-risk population can tolerate a slower migration, but a privileged admin, finance approver, remote access user, or SaaS operator with broad session authority should move first. The first control improvement should shrink the number of places where a stolen password plus a social-engineered second factor can still produce a live session.
Recent breach patterns reinforce the point. Incidents such as Microsoft Midnight Blizzard breach, Uber breach 2022, and Twilio 0ktapus breach 2022 all show that attackers commonly aim for the weakest human or recovery path, not the nominally stronger login screen.
How to choose the first migration wave
Start with the applications where compromise would create the largest blast radius. That usually means admin portals, VPN and remote access, email, identity admin consoles, finance or payments workflows, source control, and systems that can mint tokens or secrets for other services. If one successful login can unlock many downstream systems, it should be ahead of low-impact, low-privilege accounts.
Then separate user populations by the method of authentication they can realistically support. Some users can move directly to passkeys or hardware-backed sign-in, while others may need a staged transition because of device constraints, shared environments, or recovery requirements. The right first move is not a universal mandate, but a sequence that removes the most exploitable fallback first.
That sequencing is easier to justify when you connect it to known session and credential abuse patterns. CitrixBleed exploitation 2023 shows why session protection matters even when MFA is present, and Change Healthcare breach 2024 is a reminder that a single remote-access path without MFA can still produce outsized impact.
Risk and Threat Considerations
Traditional MFA is often defeated by the route around it rather than the factor itself. Phishing, push fatigue, code relay, session theft, and weak recovery flows can turn a “protected” account into a practical single-point compromise, especially when the account has broad application reach or can create new credentials, tokens, or sessions.
Failure mechanism: An attacker captures a password, relays a code, abuses a push prompt, or hijacks an existing session, then uses the resulting access to reach higher-value systems through trusted login state or overprivileged account permissions.
Impact: A single compromised session can lead to data theft, financial fraud, lateral movement, or a wider incident if the account can administer other identities, issue tokens, or reach sensitive back-office systems.
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, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Sets authenticator strength and phishing-resistant sign-in expectations for MFA migration. |
| Recommendation — Use phishing-resistant authenticators for the highest-risk sign-in paths first. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers authentication for workforce accounts using stronger sign-in controls. |
| IA-5 — Authenticator Management | Addresses lifecycle and handling of authenticators, tokens, and fallback credentials. | |
| AC-6 — Least Privilege | Prioritisation depends on limiting damage from accounts with excessive reach. | |
| Recommendation — Strengthen organizational-user authentication on accounts with the largest blast radius. Reduce reliance on weak fallback authenticators and rotate exposed credentials promptly. Restrict high-impact accounts to the minimum access needed before expanding MFA coverage. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Supports identifying and remediating the highest-risk access paths first. |
| Recommendation — Review and tighten the most powerful access paths before broadening login changes. | ||
| OWASP ASVS | V6 — Authentication | The question is about choosing stronger login controls and reducing weak factors. |
| V7 — Session Management | Session compromise is a key reason MFA alone is not enough. | |
| Recommendation — Prefer phishing-resistant authentication for the most sensitive applications and users. Harden session handling so a captured session cannot outlive the control. | ||
Practitioner Guidance
What to prioritise: Move first on accounts where a successful login can create disproportionate loss, especially administrators, remote-access users, and anyone who can reset other users or mint downstream access. If the account can be used to recover other accounts or approve high-risk actions, it belongs in the first wave.
What to verify: Check which flows still accept SMS, TOTP, push approval, email codes, or manual help-desk recovery as a valid path to access. Also verify whether step-up prompts are actually protecting the transaction, or merely adding friction before the same risky session continues.
Decision rule: If the current login path can be phished or socially engineered, use the migration to reduce fallback exposure first and introduce phishing-resistant sign-in where the blast radius is highest; do not wait for a perfect enterprise-wide rollout before fixing the most exposed accounts.
Practitioner takeaway: The right first step is to shrink the number of accounts that can be turned into a live session through a weak fallback, because that is where traditional MFA most often fails in practice.
Related resources from NHI Mgmt Group
- How should security teams implement MFA at the first desktop login without creating user friction?
- What should security teams do first when password resets are still used as a primary control?
- What is the difference between identity-first security and traditional login-based access control?
- What should security teams do first when default passwords are still present on privileged accounts and edge devices?