Why do legacy MFA methods still leave organisations exposed to phishing?

Legacy MFA often depends on transferable factors such as SMS codes or push approvals, which attackers can intercept through SIM swapping or man-in-the-middle techniques. Those methods may add friction, but they do not eliminate the phishing pathway. Security teams should judge MFA by resistance to replay and interception, not by whether a second factor exists.

Why This Matters for Security Teams

Legacy MFA still leaves organisations exposed because phishing is not only a password problem. Attackers increasingly target the approval step itself, using real-time proxy phishing, push fatigue, SIM swap abuse, and session replay to capture what a second factor was supposed to protect. That means a user can “pass MFA” while the attacker quietly receives the authenticated session or the approval.

This is why security teams now measure MFA by phishing resistance, replay resistance, and binding to the authentic session, not by whether a second step exists. NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now shows why identity compromise is so often operational rather than theoretical, and the same pattern applies to human authentication flows that can be relayed or coerced. NIST guidance on digital identity makes the same point: some MFA methods are stronger than others, and not all second factors offer equal resistance to phishing.

In practice, many security teams discover MFA weakness only after an attacker has already used a legitimate session to access email, cloud consoles, or admin workflows, rather than through intentional testing of the authentication chain.

How It Works in Practice

Legacy MFA reduces risk, but it does not fully break the phishing kill chain. If a user enters credentials into a fake login page and then approves a prompt or forwards a one-time code, the attacker can often complete the real login in near real time. The underlying problem is that many legacy methods authenticate the user, but do not strongly authenticate the origin of the request or bind the factor to the specific transaction.

Modern guidance increasingly favours phishing-resistant methods such as FIDO2/WebAuthn hardware-backed authenticators, which cryptographically bind authentication to the legitimate domain and reduce replay value. Where policy still allows OTPs, SMS, or push MFA, teams should layer controls that narrow the damage path:

• Prefer phishing-resistant authenticators for privileged users and remote access.
• Require step-up verification for high-risk actions, not just for sign-in.
• Detect impossible travel, anomalous device posture, and unusual prompt patterns.
• Reduce the lifetime of sessions so stolen tokens age out quickly.
• Treat help desk reset flows as part of the attack surface, not a back-office detail.

NIST’s Digital Identity Guidelines are clear that authenticator strength varies, and that verifiers should prefer methods with strong resistance to phishing and replay. For organisations that manage large identity estates, NHI Management Group’s 52 NHI Breaches Analysis is a useful reminder that identity compromise often starts with credential abuse, then expands through trusted access paths. Current practice also supports FIDO Alliance and platform-native passkeys for broad user populations, but rollout still depends on device readiness, recovery design, and legacy application compatibility.

These controls tend to break down in environments that still depend on shared accounts, VDI hops, or SMS-based recovery because the attacker only needs one weak step to regain a usable session.

Common Variations and Edge Cases

Tighter MFA can increase enrolment friction and recovery overhead, so organisations must balance phishing resistance against support burden and user adoption. That tradeoff is real, especially in mixed device fleets, contractor-heavy environments, or global operations where not every user can carry the same authenticator.

Best practice is evolving, but there is no universal standard for every application tier. Some legacy systems cannot support WebAuthn or modern device-bound tokens, which leaves security teams with a pragmatic interim model: enforce phishing-resistant MFA where the risk is highest, then constrain the rest with conditional access, session hardening, and rapid token revocation. The highest-risk edge case is not the ordinary employee login, but privileged access, admin re-authentication, and identity recovery, where a phished factor can be more damaging than a stolen password because it unlocks trusted workflows.

For broader identity resilience, the same lesson appears across NHI security: NHI Mgmt Group’s The 52 NHI Breaches Report and the Ultimate Guide to NHIs both show that trust anchors fail when they are easy to replay, reuse, or socially engineer.

Legacy MFA remains useful as a baseline, but it should not be treated as phishing-proof unless it is paired with resistant authenticators, session controls, and recovery processes that an attacker cannot easily hijack.

Related resources from NHI Mgmt Group

• Why do conventional MFA methods still leave identity risk on the table?
• When does a phishing-resistant login method still leave organisations exposed?
• Why do MFA controls still leave organisations exposed to ransomware?
• Should organisations prioritise phishing-resistant MFA over other identity projects?