Why do bank impersonation scams still succeed even when MFA is enabled?

They succeed when the attacker captures the password and the one-time code in the same live phishing session, then uses weak recovery or reset flows to keep control. MFA that can be relayed or replayed does not stop a well-timed impersonation attack.

Why This Matters for Security Teams

bank impersonation scam still work because the attacker is not trying to “break” MFA in the abstract. They are exploiting the full login and recovery path, including live phishing, session theft, and help-desk or reset abuse. Once a user is coached into approving a prompt or entering a one-time code, the bank’s control is only as strong as the surrounding identity proofing, transaction monitoring, and step-up policy. That is why NIST’s Cybersecurity Framework 2.0 treats identity, detection, and recovery as linked functions, not isolated controls.

For identity teams, the real lesson is that MFA reduces risk but does not eliminate impersonation when the attacker controls the conversation in real time. Social engineering succeeds because the user believes the request is legitimate, and the control often fails after the initial factor is entered. The broader NHI pattern is similar: once an adversary can relay a trusted credential or abuse a weak lifecycle process, short-lived proof becomes long enough to cause harm. NHIMG’s Ultimate Guide to Non-Human Identities shows how often organisations underestimate that lifecycle gap, and the same operational blind spot appears in consumer banking. In practice, many security teams encounter the fraud only after account takeover has already been converted into payment loss or recovery hijack.

How It Works in Practice

The mechanics are usually straightforward. A scammer spoofs the bank, pushes the victim to a fake login page, captures the password, then relays the OTP, push approval, or session token to the real service before the code expires. If the bank still relies on SMS, push fatigue, or weak fallback authentication, the attacker can keep control long enough to change contact details, add a payee, or trigger a password reset. This is why the control question is not “Was MFA enabled?” but “Was the authentication method phishing-resistant, and was the post-authentication path hardened?”

Practitioners should separate authentication from authorization and recovery:

• Use phishing-resistant MFA where possible, such as FIDO2/WebAuthn, rather than OTPs that can be relayed.
• Bind sessions to device, browser, or transaction context so a stolen code is not enough on its own.
• Harden recovery flows with stronger identity proofing, cooling-off periods, and out-of-band alerts.
• Monitor for impossible travel, new device enrollment, payee creation, and contact-detail changes as takeover signals.
• Apply step-up checks only where risk increases, rather than assuming one MFA event covers the whole session.

This also mirrors what NHIMG documents in the Microsoft Midnight Blizzard breach: once an adversary gets a valid foothold, weak surrounding controls and recovery paths determine how far they can go. Current guidance suggests treating authentication as one layer in a larger trust chain, not as a stand-alone shield. These controls tend to break down when SMS or push-based MFA is paired with permissive password reset flows because the attacker only needs one live trust bridge to keep the session alive.

Common Variations and Edge Cases

Tighter MFA often increases user friction and support burden, so organisations must balance fraud reduction against account-access overhead. That tradeoff is real, but current guidance suggests the answer is not to remove MFA; it is to raise assurance where impersonation risk is highest and weaken nothing in the recovery path.

There is no universal standard for this yet, but best practice is evolving toward risk-based authentication, device binding, and phishing-resistant factors for high-value actions. Banks also need to distinguish between login assurance and transaction assurance. A login that was valid ten minutes ago should not automatically authorise adding a new beneficiary, changing the phone number, or approving a wire. The most common edge case is account recovery: if support staff can override strong MFA with only weak knowledge-based checks, the attacker simply bypasses the strongest control by targeting the weakest one.

For practitioners building a durable model, the lesson is to treat every fallback as part of the attack surface. If recovery, contact change, and transaction approval do not meet the same assurance standard as login, the scammer will eventually route around MFA.

Related resources from NHI Mgmt Group

• Why do MFA implementations still fail even when a second factor is enabled?
• Why do help desk impersonation attacks succeed even when MFA is deployed?
• Why do still-valid secrets matter after public disclosure?
• Why do secrets stay dangerous even when they are no longer actively used?