Why MFA is not enough when attackers can talk users through it

Multifactor authentication (MFA) is important, but many widely deployed MFA methods are phishable, many post-authentication artifacts are replayable, and many organizations still leave recovery and enrollment open to social engineering. The NIST, in a recent Special Publication on digital identity guidelines, draws a line between ordinary MFA and phishing-resistant authentication.

Fast Identity Online (FIDO) in the publication explicitly classifies SMS one time pins (OTPs), many app OTPs, and push notifications as phishable. Current campaigns exist where attackers do not ‘break’ MFA so much as walk users through it, proxy it, or harvest value after it succeeds.

Voice phishing makes MFA approval feel legitimate

Voice phishing makes MFA approval feel real because vishing starts, as the survey A deeper look into cybersecurity issues in the wake of Covid-19 notes, when "the attacker calls the target on the phone" and pretends to be part of an "organization with which the victim is affiliated." The login request comes to the user in a conversation already sounding official, normal, and safe.

A case study from Digital Health on hospital phishing says that things like "authority and urgency" affect how people react. A phone call makes both of these things stronger because the attacker can put pressure on the person, answer objections right away, and make them feel like they are taking a risk or not cooperating. Another Wiley paper says that spear phishing often takes advantage of "the intuitive and fallible nature of human decision making." It explains why someone on a live call might see an MFA push, code, or number match as a normal part of the verification process instead of a warning sign.

Well-contextualized phishing can be managed in a routine or automatic manner, particularly when it seems to originate from a trusted source. The phone call gives the attacker legitimacy, the MFA prompt gives them a familiar ritual, and the victim ends up doing the last security step for the attacker while thinking they are proving who the caller is instead of who they are helping.

Why push prompts and OTPs are still phishable

The NIST publication also says authenticators require the user to manually enter an authenticator output, such as OTP, and out-of-band methods, which are not phishing-resistant because the user's code entry is not cryptographically tied to the session being authenticated. An impostor verifier can send outputs to the real verifier.

Google documented UNC6040 guiding victims during voice-phishing calls to disclose credentials and MFA codes and, in some cases, to authorize a malicious Salesforce-connected app. Microsoft’s current phishing-resistant MFA guidance likewise says SMS codes, email OTPs, and push notifications are becoming less effective because attackers exploit social engineering, man-in-the-middle tactics, and fatigue. Microsoft describes number matching as an improvement to regular push notifications, rather than as a method to reduce the likelihood of phishing attempts through push notifications.

We still do not know the public cross-vendor failure rates for push and OTP phishing in a way easy to compare, but we do know which way they are going. The previously mentioned sources all agree that these methods are still useful against password reuse and basic takeover, but they are still vulnerable when the user can be manipulated.

As the study Susceptibility to Spear-Phishing Emails: Effects of Internet User Demographics and Email Content notes, “Susceptibility to phishing, including spear-phishing (a more targeted variation of phishing, where usually the victim is addressed by name)...”, it takes advantage of how people make decisions that are easy to make mistakes with, and vishing adds trust, urgency, and conversational pressure. The attacks are mitigated through the following means:

• Prioritize phishing-resistant methods for admins and high-risk users first: passkeys, FIDO2 security keys, Windows Hello for Business, or equivalent verifier-bound methods.
• Reduce reliance on fallback by removing SMS and weak OTP options where possible and by treating push-number-matching as an interim control, not an end state.
• Harden user decision points with clear app context, suspicious-prompt reporting, and training specifically about voice-guided approvals and fake support calls.

Adversary-in-the-middle kits bypass MFA by stealing the session

Adversary-in-the-middle attacks break MFA by going after the session instead of the second factor itself. In a reverse-proxy setup, the phishing kit is between the victim and the real service. The victim gives real login information to the fake page, which the proxy sends to the real site right away. The phishing page then forwards the real MFA challenge back to the user, which the real site had sent.

After the user finishes MFA, the attacker takes the session cookie or token and uses it again. Microsoft's advice says the kit "closely mimicked legitimate authentication processes" while stealing credentials and session tokens. It could also get around SMS codes, one-time passcodes, and push notifications.

Microsoft notes that in October 2025, it stopped more than 13 million harmful emails connected to Tycoon2FA. One operational consequence is especially necessary for defender states: some session tokens for browser-based applications are controlled by the application and can't be directly revoked by the identity provider. The response needs to include fixes on both the IdP and application sides.

The weak point is often recovery, enrollment, or help-desk support

The cleanest way around a strong login is often not to attack the login at all. NIST’s 2025 guidance warns that when recovery is human-assisted, social engineering attacks pose risks, and it explicitly says one authentication factor must not be leveraged to obtain an authenticator of a different type. The same document warns against authenticators creating social-engineering risk for third parties, such as customer service agents, flags the risk of fraudulent authenticator binding, and requires notifications for events such as authenticator binding and account recovery so subscribers can detect fraud. The NIST treats recovery and enrollment as part of the authentication surface, not as administrative side processes.

Peer-reviewed Frontiers in Psychology study helps explain why those workflows remain vulnerable. The study noted, “Social engineering cyberattacks are a kind of psychological attack that exploits weaknesses in human cognitive functions.” Phishing can impersonate an ITS help desk to pressure users into handing over credentials. Social engineering attacks commonly exploit authority and distraction, and persuasive messages using authority are among the most effective. It is especially effective when “human cognition is affected by cognitive workload, which depends on task demand and the operator in question.” Recovery and enrollment are therefore exposed, as once a caller sounds legitimate, urgent, and procedural, the reset process itself can become the bypass.

Why MFA is not the only solution

Paubox is a good solution because MFA only protects the sign-in event. Many modern attacks work before or after the sign-in event, using phishing emails to get a user to click, reply, approve a prompt, or give up a session that the attacker can use again after authentication.

Paubox fills the gap at the message level. Its current inbound security stack uses AI to analyze the sender's behavior, tone, and context, along with sender validation, reputation checks, and attachment, link, and QR-code scanning. Suspicious mail can stop a user from ever making a bad authentication decision. Paubox also excels at stopping attacks that MFA struggles with, such as display-name spoofing, lookalike-domain messages, and impersonating someone with a compromised account.

Paubox ExecProtect and ExecProtect+ put emails pretending to be protected internal names in quarantine and can automatically protect internal senders.

See also: HIPAA Compliant Email: The Definitive Guide (2026 Update)

FAQs

What is FIDO?

FIDO is a set of authentication standards from the Fast Identity Online Alliance designed to reduce reliance on passwords by using stronger login methods such as security keys, biometrics, and device-based authentication.

Does HIPAA require MFA?

It is not expressly covered under the current HIPAA Security Rule. The current rule requires covered entities and business associates to implement person or entity authentication procedures and other reasonable safeguards for electronic protect health information (ePHI), but it does not name MFA as a universal, standalone mandate.

Can an organization be HIPAA compliant without MFA?

Possibly under the current rule, but that does not make skipping MFA a low-risk decision.

Does MFA alone satisfy HIPAA?

No. The Security Rule requires administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of ePHI.