What happens when people use MFA but still trust login requests from a fake email or text message?

Attackers can steer users into approving access, entering credentials on a lookalike site, or revealing one time codes. In practice, MFA only helps if the factor is resistant to phishing and the user verifies the request source. Without that combination, the attacker can still convert a convincing message into an authenticated session.

Why Phishing Still Works Even When MFA Is Enabled

MFA reduces the value of a stolen password, but it does not automatically stop a user from being manipulated into approving a login or handing over a one time code. The real weakness is often not the authentication mechanism itself, but the trust decision made by the person receiving the fake email or text message. When the request looks legitimate, attackers can turn a supposed safety control into a route to an authenticated session.

This is why phishing resistant factors matter more than MFA in the abstract. A push prompt, SMS code, or one time password can still be abused if the user is persuaded to disclose it or if the login flow does not bind the request to the real origin. The user sees a familiar brand, a plausible sender, and an urgent reason to act, while the attacker relies on speed and confusion rather than technical sophistication.

In practice, many compromises start with a message that looks routine until the user has already granted access or entered a code into a counterfeit page.

How the Attack Works in Practice

These attacks usually begin with a message that creates urgency: a password reset, a missed delivery, an account alert, or an invoice notice. The email or text links to a lookalike site, or it instructs the user to read out, paste, or approve a code. Once the user interacts, the attacker can capture credentials, intercept the one time code, or trigger a fraudulent approval and complete the sign in.

The important distinction is that MFA only helps when the second factor cannot be socially engineered away. If the factor is a reusable code, a push notification, or any approval that is not strongly tied to the actual login context, the attacker can often relay the challenge in real time. That is why current guidance increasingly prefers phishing resistant authentication such as passkeys, hardware backed factors, or FIDO based flows that bind the factor to the legitimate origin.

Teams should also pay attention to the surrounding control environment. A strong MFA method is weakened when:

users are trained to approve prompts without checking details,
login pages are not visually distinctive enough to spot lookalikes,
SMS or email is used as a fallback for sensitive access, or
the organisation does not monitor impossible travel, unusual device enrolment, or repeated MFA failures.

For deeper practitioner context on credential abuse and why exposed or misused authentication material is so valuable to attackers, NHIMG research on the State of Secrets in AppSec is useful background, even though the defensive lesson here is about user trust and authentication flow rather than secrets hygiene alone. Standards guidance from the OWASP Non-Human Identity Top 10 is also relevant where phishing leads to token theft or session abuse in machine and service access paths.

These controls tend to break down in organisations that still rely on SMS, email-based approvals, or generic push confirmations because the login challenge is easy to relay and hard for users to validate in the moment.

Common Failure Modes and Edge Cases

Tighter authentication often adds friction, so organisations have to balance user convenience against the risk of approval fatigue and code interception. The practical problem is that not all MFA methods fail in the same way. Some are vulnerable to social engineering, others to session replay, and some are more resistant because they cryptographically bind the authentication event to the original service.

A common edge case is help desk or recovery flow abuse. If an attacker cannot win the MFA challenge directly, they may shift to account recovery, device re-enrolment, or a support workflow that is less scrutinised than the login screen. Another edge case is adversary-in-the-middle phishing, where the fake page proxies the live session and forwards the challenge in real time. In those cases, the user may think they are helping a normal verification step while the attacker is harvesting a usable session token.

There is no universal standard for user vigilance alone. Best practice is evolving toward phishing resistant methods for high value accounts, clear out-of-band verification rules for login prompts, and tighter controls around recovery. That matters most where the account can reach admin consoles, financial systems, developer platforms, or other privileged services.

For critical accounts, the right question is not whether MFA exists, but whether the factor can survive a convincing fake message without user interpretation becoming the last line of defence.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Phishing-driven login abuse exploits weak access validation and fallback paths.
Recommendation — Harden access workflows and remove weak MFA fallbacks for sensitive accounts.
NIST CSF 2.0	PR.AA-1 — Identity and Access Management	The issue is whether authentication methods resist impersonation and misuse.
	PR.AA-2 — User Authentication	Users are tricked into satisfying authentication steps through fake messages.
Recommendation — Use phishing-resistant authentication for users and privileged accounts. Bind authentication to the real origin and verify login context before granting access.
MITRE ATT&CK	T1566 — Phishing	Fake email or text messages are the initial access mechanism in this scenario.
	T1111 — Multi-Factor Authentication Interception	Attackers relay or capture MFA factors through real-time phishing pages.
Recommendation — Detect and disrupt phishing lures that solicit credentials or MFA approvals. Block MFA interception by adopting resistant factors and monitoring relay patterns.

Practitioner Guidance

What to prioritise: Prioritise phishing resistant MFA for any account that can alter sensitive data, approve transactions, or reach privileged systems. If the factor can be relayed through a fake message, treat it as partially effective rather than fully trusted.

What to verify: Verify whether your authentication flow binds the login attempt to the real origin and the real device, and whether users can complete access by approving a prompt they do not understand. If yes, the control is weaker than the policy suggests.

Decision rule: If a user can be induced to read out a code, approve an unexpected prompt, or sign in through a link from email or text, require a stronger factor and remove high-risk fallback paths from privileged access.

Practitioner takeaway: MFA is only a speed bump when the attacker can borrow the user’s trust; the control becomes materially stronger only when the factor itself resists phishing and the login source is independently verifiable.