Why does two-factor authentication still fail when attackers target the human behind the login?

Two-factor authentication reduces risk, but it does not eliminate social engineering. If an attacker can persuade a user to reveal a one-time code or approve a prompt, the second factor becomes part of the attack. The control works best when paired with user training, device binding, and detection for unusual authentication patterns.

Why the Second Factor Can Become Part of the Attack

Two-factor authentication raises the bar, but it still depends on the user making the right decision at the right moment. If an attacker can manipulate the person into reading out a one-time code, approving a push prompt, or entering credentials into a fake sign-in flow, the factor is no longer a barrier, it becomes the mechanism that completes the compromise.

This is why modern attack chains often focus on trust, urgency, and confusion rather than technical bypass. The control is strongest when the second factor is resistant to real-time phishing and when users are not asked to make security decisions under pressure.

Why Prompt Bombing, Vishing, and Real-Time Phishing Work

Attacks against the human behind the login work because many second-factor methods authenticate the session, not the intent behind it. A one-time code can be relayed in real time, a push request can be fatigue-attacked until the user accepts, and a help desk reset path can be social-engineered into issuing a fresh authenticator or recovery route.

Those failures are not the same as “MFA broken.” They usually mean the attacker gained enough influence over the workflow to turn a valid factor into attacker-controlled access. The practical weakness is usually the combination of human trust, weak recovery steps, and a factor that is easy to replay or approve remotely.

When the login flow allows step-up based only on a code or a simple approval, the attacker can often keep pace with the user and the service. The defense has to break that loop with phishing-resistant authenticators, device binding, and anomaly detection for unusual prompts, geography, device changes, or repeated denials.

Why Stronger Authentication Must Be Paired With Identity Controls

The most reliable way to reduce this failure mode is to make the second factor harder to transfer and easier to verify in context. NIST SP 800-63 Digital Identity Guidelines are useful here because they distinguish stronger authenticators from weaker ones and give practitioners a benchmark for phishing-resistant sign-in.

Operationally, that means preferring passkeys, security keys, or other bound authenticators over reusable codes where the threat model includes social engineering. It also means reducing recovery paths that let an attacker bypass the factor entirely through SMS resets, help desk deception, or account takeover of a backup channel.

Real incidents show the same pattern across different environments. The lesson from Uber Breach and Twilio 0ktapus breach 2022 is that users can be convinced to approve or disclose the very signal meant to protect them. The lesson from Cisco Yanluowang breach 2022 is that fatigue and vishing can defeat a valid second factor when the surrounding process is permissive.

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 CSF 2.0, 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	Phishing-resistant authenticators and assurance levels directly address MFA failure by social engineering.
Recommendation — Prefer phishing-resistant authenticators and bound recovery paths over transferable one-time codes.
NIST CSF 2.0	PR.AA-05 — Multi-factor authentication	The question is about why MFA still fails when attackers manipulate the user, a control implementation issue.
	PR.AA-03 — Remote access is managed	Remote sign-in and recovery paths are common points where social engineering defeats the second factor.
Recommendation — Harden MFA with stronger authenticators and contextual anomaly detection for approval abuse. Restrict remote access flows so recovery and step-up cannot bypass stronger authentication.
CIS Controls v8	5 — Account Management	User authentication, reset, and recovery workflows are central to preventing account takeover via social engineering.
Recommendation — Tighten account lifecycle and recovery processes so attackers cannot use support paths to bypass MFA.
OWASP ASVS	V6 — Authentication	The subject concerns how authentication breaks when factor approval is socially engineered.
Recommendation — Require phishing-resistant authentication and verify recovery paths cannot downgrade assurance.

Practitioner Guidance

What to verify: Check whether your MFA methods are phishing-resistant or merely code-based, and test whether recovery, reset, and help desk workflows can issue access without the same assurance level as the login itself. If they can, the effective control is weaker than the policy says.

What to prioritize: Reduce the number of situations where a user can be convinced to approve something they do not understand. That usually means device binding, stronger authenticator choices, and detection for unusual prompt volume or repeated failed approvals before adding more user prompts.

Practitioner takeaway: Two-factor authentication fails most often when the defender protects the account but not the decision path, so the real control objective is to make the second factor hard to relay, hard to coerce, and easy to challenge when it appears in an unusual pattern.