Why do phishable MFA factors still create account takeover risk?

Why phishable MFA factors still leave takeover risk

Phishable MFA factors reduce risk, but they do not remove it because the attacker only needs one usable path through the authentication workflow. When the second factor can be replayed, intercepted, socially engineered, or approved under pressure, it becomes an access path rather than a barrier. The result is account takeover risk even when the password itself remains unknown.

Attackers focus on the factor that is easiest to exploit in real use, not the strongest factor in theory. That is why phishing, push fatigue, SIM swapping, OTP relay, and help-desk manipulation keep working against otherwise “multi-factor” setups. The weak point is often the human decision point, the recovery path, or the session token issued after successful login, not the first password prompt.

Which MFA weaknesses matter most in practice

Phishable factors are dangerous because they preserve the attacker’s ability to present a believable login flow. If the user can be tricked into entering an OTP into a fake page, approving a push, or reading a code over the phone, the factor has not stopped the attack chain. For a practical control view, compare factor choice and recovery design using NIST SP 800-63 Digital Identity Guidelines, which distinguish weaker authenticators from phishing-resistant ones.

SMS and email OTP are especially fragile because they depend on channels that can be redirected, forwarded, socially engineered, or accessed through a compromised mailbox or SIM. Push approval is also weak when the user can be fatigued into acceptance or is conditioned to approve routine prompts. That is why phishing-resistant methods such as passkeys and security keys change the security outcome materially, as covered in Passwordless and Passkeys Guide and MFA Guide.

Real-world compromise usually succeeds by chaining the weak factor with credential theft, session theft, or recovery abuse. That is why account takeover stories often involve more than one control failure, not just the factor itself. The pattern is visible in cases such as Twilio 0ktapus breach 2022, where SMS phishing harvested access, and Uber breach 2022, where MFA fatigue helped turn valid credentials into internal access.

How attackers turn weak second factors into account takeover

The common failure mode is not “MFA is broken,” but “the factor is bound to the wrong trust assumption.” A phishable factor can validate the wrong login attempt, the wrong device, or the wrong session when the attacker controls the interaction. That is why a stolen password plus a phishable factor often behaves like full access, especially when the application trusts the factor response more than the login context.

Attackers also aim to bypass the login screen entirely by stealing the session after the factor succeeds. In practice, session theft, token replay, and edge-appliance cookie theft can make MFA irrelevant because the attacker enters after authentication has already completed. That is why incidents such as CitrixBleed exploitation 2023 matter to this question, even though the weakness is not limited to one factor type.

Recovery paths are another frequent bypass. If a phishable factor is coupled with weak account recovery, help-desk reset, or legacy fallback channels, the attacker may not need to defeat the primary factor at all. That is why hardening the sign-in method alone is not enough; the surrounding identity flow must resist coercion, replay, and downgrade. NHIMG’s Workforce Identity Security Guide is useful here because it ties phishing-resistant MFA to recovery, federation, and session theft as one control problem.

What good looks like when you want MFA that actually blocks takeover

The control objective is to make successful authentication hard to phish, hard to replay, and hard to approve blindly. In practice that means preferring phishing-resistant authenticators, tightening recovery, and reducing acceptance of legacy OTP paths except where a compensating control is explicit and temporary. The most reliable deployments treat the second factor as a binding between the user, the device, and the session, not as a simple code entry step.

For implementation, the most important test is whether a stolen password can still be converted into a live session through social engineering or channel abuse. If the answer is yes, the factor set is still exposure-bearing. If you need a vendor or architecture view of that decision, IAM and Identity Provider Buyer's Guide helps frame how SSO, phishing-resistant MFA, lifecycle, and recovery belong together.

Practitioner takeaway: The decisive question is not whether MFA exists, but whether an attacker can still obtain a usable session by tricking, pressuring, or replaying the factor and then riding the result into the application.

Related resources from NHI Mgmt Group

• Why does SMS-based MFA still create account takeover risk?
• Why do passwords and phishable MFA factors still create unacceptable risk for enterprise access?
• Why do missing MFA and phishable backup methods still create material account risk?
• Why do repeated MFA prompts create account takeover risk?