Phishing-resistant MFA gaps keep small banks exposed to takeover risk

At a glance

What this is: This article argues that phishing-resistant MFA remains incomplete in many small financial institutions because passwords, legacy applications, and uneven coverage still create takeover paths.

Why it matters: IAM and security teams in regulated environments need to treat MFA as a workforce-wide control problem, because partial deployment leaves the same identity attack surface open across NHI, autonomous, and human access paths.

By the numbers:

• 80% of Mastercard’s confirmed data breaches are linked to weak or stolen passwords.
• NYDFS requires MFA for any individual accessing any of its information systems starting November 1st 2025.

Context

Phishing-resistant MFA is a workforce access control problem, not a cloud-only feature problem. In small banks and credit unions, the risk persists when passwords remain the first factor, when older applications cannot support modern sign-in flows, and when MFA coverage stops short of desktops, VPN, and legacy banking systems.

The article’s core point is that partial deployment creates a false sense of coverage. Regulators are tightening expectations, but attackers still look for the oldest and least modernised path into the environment, where password-based authentication and delayed credential reset can still provide a workable entry point.

Key questions

Q: What breaks when workforce MFA still depends on passwords first?

A: Password-first MFA still leaves attackers a phishable secret to steal, replay, or guess before the second factor is even relevant. That means the control reduces risk but does not remove the initial compromise path, especially when legacy systems and inconsistent access flows preserve weak authentication surfaces.

Q: Why do legacy banking applications create phishing-resistant MFA gaps?

A: Older applications may not support modern federation, passwordless flows, or consistent policy enforcement across all access routes. When modern controls are applied only to cloud apps, the legacy estate becomes the easiest place for attackers to look for weaker sign-in paths.

Q: How can security teams tell whether adaptive MFA is working properly?

A: Look for a lower challenge rate on routine sessions, a higher challenge rate on suspicious transactions, and stable or improved conversion. If adaptive MFA is triggering everywhere, it is behaving like blunt MFA. If it rarely triggers on risky actions, the policy is too weak to matter.

Q: Who is accountable when partial MFA deployment leaves regulated access exposed?

A: Identity, security, and application owners share accountability because the failure usually sits at the boundary between policy, legacy architecture, and access operations. In regulated financial environments, that boundary matters because auditors assess whether control coverage matches the actual workforce access model.

Technical breakdown

Why password-first MFA still leaves takeover paths open

Phishing-resistant MFA is designed to reduce credential replay and phishing success, but it does not erase risk if the user still authenticates with a password first. In that model, the password remains the initial secret the attacker wants, and the second factor often becomes a bypass target rather than a primary defence. The problem is especially sharp in workforce environments where email, VPN, and internal applications rely on inconsistent sign-in patterns. A control that depends on a phishable first factor only shifts where the attack lands. Practical implication: treat password-first MFA as risk reduction, not phishing resistance.

Practical implication: move from password-first flows to authentication that removes the phishable initial secret wherever the workforce uses it.

Legacy banking applications create MFA coverage gaps

Older on-premise banking platforms often predate modern federation and passwordless design. That matters because they may not support enterprise SSO, modern token-based flows, or consistent policy enforcement across all access methods. When organisations modernise only cloud apps, they create a split estate where some sessions are protected and others are not. Attackers do not need to defeat the best-protected path if a legacy path still accepts weaker credentials. Practical implication: map which applications cannot yet participate in modern authentication and treat them as active control exceptions, not technical leftovers.

Practical implication: inventory legacy applications that cannot support modern authentication and isolate them as formal exceptions until they can be remediated.

Why universal coverage matters for desktops, VPNs, and regulated access

A phishing-resistant MFA programme fails when it protects one channel but leaves another open. Desktops, VPN access, and remote administration are common pressure points because they are heavily used and often sit outside the most mature identity design. In a regulated financial environment, that creates both takeover exposure and audit pressure, because the control objective is not partial adoption but consistent workforce verification. The article also points to the operational cost of exceptions, including help desk load and remediation drag. Practical implication: define coverage by access path, not by application class alone.

Practical implication: assess authentication coverage by access path so VPN, desktop, and legacy access do not become policy blind spots.

Threat narrative

Attacker objective: The objective is account takeover that yields access to internal systems and sensitive customer or personal data.

1. Entry begins when an attacker obtains or reuses weak workforce credentials and reaches a remote access path such as VPN or a legacy login surface.
2. Credential access becomes viable when passwords, OTP seeds, or other reusable secrets can be captured, replayed, or left in place after a breach or departure.
3. Impact follows when the attacker reaches internal systems and customer data, or when a former employee continues to use valid access after employment ends.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Phishing-resistant MFA is only real when the phishable first factor disappears. If passwords still sit at the front of the authentication flow, the control is compensating for a weak secret rather than replacing it. That leaves the same attacker playbook intact, especially in regulated workforce environments where credential replay remains the easiest path. The practitioner conclusion is simple: the first factor matters as much as the second.

Legacy application support is the real constraint, not policy language. Small institutions can write MFA policy faster than they can modernise older banking applications, and that mismatch is where gaps persist. The problem is not that teams do not value stronger authentication; it is that some core systems cannot enforce it uniformly. The implication is that authentication governance must be architecture-aware, not policy-only.

Coverage gaps are a control design failure, not a user-experience trade-off. When MFA stops at cloud applications but leaves VPNs, desktops, and older on-premise services exposed, attackers simply choose the weakest path. That means authentication assurance has to be measured by the lowest-protected route into the environment. Practitioners should treat uneven coverage as an exposure indicator, not an acceptable exception.

Identity assurance in financial services is moving toward universal verification, not partial hardening. Regulatory pressure from NYDFS, FFIEC-aligned expectations, and audit scrutiny is converging on the same outcome: workforce access must be stronger across every access path. Institutions that maintain password dependence for some systems will keep carrying avoidable takeover risk. The practitioner conclusion is to align governance to end-to-end access paths, not isolated applications.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Coverage, not adoption, is the decisive metric. Financial institutions can claim MFA deployment while still leaving the highest-risk access paths dependent on passwords. The operational question is whether the weakest route into the environment is protected to the same standard as the strongest one.

Legacy systems turn authentication policy into an architecture problem. Once older platforms cannot participate in passwordless or enterprise SSO flows, they define the floor for the whole programme. Security teams should expect those exceptions to persist unless they are governed as a formal remediation backlog.

Phishing-resistant MFA should be measured by attack surface reduction, not by sign-in feature count. If a user can still be phished, replayed, or reauthenticated through a weaker path, the programme has not yet changed the takeover equation.

For practitioners

• Map authentication coverage by access path Inventory every workforce access route, including VPN, desktops, cloud apps, and legacy on-premise systems, and identify where passwords still remain the first factor.
• Classify legacy systems as formal MFA exceptions Document which banking platforms cannot yet support enterprise SSO or passwordless authentication, then track them as named exceptions with owners and remediation dates.
• Remove password dependence from workforce sign-in Prioritise phishing-resistant flows that eliminate reusable passwords for the access paths most exposed to phishing and replay.
• Align controls to regulatory MFA expectations Compare current workforce authentication coverage with NYDFS, FFIEC-aligned, and audit requirements so gaps are visible before an examination or enforcement action.
• Measure the weakest protected route Use the least protected channel, not the best one, as the benchmark for authentication assurance across the environment.

Key takeaways

• Passwords still create takeover risk in small financial institutions when they remain part of the workforce authentication flow.
• The main operational weakness is uneven MFA coverage across VPN, desktops, cloud apps, and legacy banking systems.
• Phishing-resistant MFA only becomes meaningful when every access path is governed to the same assurance level.

Key terms

• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
• Legacy application gap: A mismatch between modern identity controls and older applications that cannot enforce them consistently. In practice, it is not just a technical compatibility issue but a governance gap, because the weaker application becomes the effective floor for the whole authentication programme.
• Authentication Coverage Gap: An authentication coverage gap is the difference between the identity policy an organisation claims to enforce and the platforms or user groups that remain outside that policy. In mixed estates, these gaps often appear first in Linux, legacy systems, or privileged workflows that are harder to modernise.
• Account Takeover: Account takeover is unauthorized use of a legitimate account after an attacker obtains valid access through stolen credentials, tokens, or trusted integrations. The key security problem is that the resulting activity often looks normal to logs and controls, which makes containment and attribution harder than in a forced-entry breach.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.