What happens when financial regulators do not require phishing-resistant authentication?

Without clear regulatory pressure, many institutions continue to rely on legacy authentication patterns that are already being abused at scale. That leaves banks exposed to fraud, customer trust erosion, and reputational damage, while the broader financial system absorbs avoidable identity risk. Outcome-based regulation can raise the baseline without prescribing one tool, but doing nothing keeps weak access practices in place.

Why Weak Authentication Standards Become a Systemic Banking Problem

When regulators do not require phishing-resistant authentication, institutions often optimise for convenience, cost, and fast rollout instead of resistance to credential theft. That matters because phishing remains a reliable path into customer accounts, employee portals, and privileged workflows, and legacy factors such as passwords, OTPs, and push approvals can be replayed or coerced. The result is not just isolated account compromise; it is a durable weakness across the sector that raises fraud rates, recovery costs, and supervisory concern.

For financial firms, the issue is less about whether a control exists and more about whether it can survive real attacker tradecraft. Outcome-based expectations can still leave room for strong methods, but when the baseline is unclear, weaker methods tend to persist in production longest. NIST’s NIST SP 800-63 Digital Identity Guidelines are useful here because they distinguish authenticators by assurance and resistance properties rather than by branding alone.

In practice, many security teams discover the weakness only after phishing-driven fraud or account takeover has already been normalised as an acceptable cost of doing business.

How the Failure Shows Up in Day-to-Day Operations

Phishing-resistant authentication changes the attacker’s economics by requiring a factor that is bound to the origin and difficult to replay, such as FIDO-based passkeys or hardware-backed authenticators. Without a mandate, organisations frequently keep mixed estates: legacy workforce login flows, customer journeys with step-up exceptions, and privileged access paths that still accept weaker methods. That creates uneven assurance across channels, which is exactly where attackers look for the easiest bypass.

The operational pattern is predictable. Fraud teams see more account takeover, support teams absorb password-reset and lockout volume, and identity teams are forced to keep tuning exceptions that quietly become the real control. The problem is amplified when one weak channel can bootstrap access to a stronger one, such as an email account that resets banking credentials or an employee portal that approves payment workflows. The NIST framework guidance on identity assurance supports this distinction, while the CIS Controls v8 emphasis on secure authentication and account management reinforces the operational need to remove weak login paths rather than merely monitor them.

Phishing-resistant authentication reduces successful replay, but only if it is enforced on every path that can reach customer funds or sensitive operations.
Legacy methods remain attractive when regulators permit “equivalent” controls without a clear test for phishing resistance.
Exception handling becomes a hidden risk when temporary bypasses are left open for high-value users, third parties, or recovery flows.

NHIMG’s research on NHI lifecycle management shows why this matters beyond human login events: identity controls fail fastest when ownership, rotation, and recovery are inconsistent, and that same pattern appears in authentication governance. When institutions keep fallback paths for convenience, attackers usually find them before compliance teams do.

Where the Real Tradeoffs and Exceptions Sit

Tighter authentication requirements often increase rollout friction, support cost, and user onboarding complexity, so regulators and institutions must balance fraud reduction against operational readiness. That tradeoff is real, but current guidance suggests it should be handled with migration planning rather than indefinite acceptance of weaker methods. The practical question is not whether every user can be moved on day one; it is whether the organisation is shrinking the attack surface or preserving it under a softer label.

There are also edge cases. Some transaction journeys may need layered step-up authentication, and some populations will require recovery alternatives for accessibility or device-loss scenarios. Those exceptions should be narrowly scoped, time-bound, and observable. A control is not truly phishing-resistant if a simple support interaction, SMS reset, or email fallback can defeat it. For supervisory perspective, NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful because it frames accountability, evidencing, and remediation as governance problems, not just technical configuration.

Practitioners should treat this as a measurement problem as much as an implementation problem: if the institution cannot show which populations, workflows, and recovery paths are protected by phishing-resistant methods, then the policy is not yet operating as intended.

Risk and Threat Considerations

When regulators do not require phishing-resistant authentication, the material risk is sector-wide account takeover and fraud persistence. The exposure is not limited to individual users; it extends to customer trust, operational continuity, and the reliability of downstream payment and approval workflows. In a financial context, even a small amount of weakly protected access can create repeated abuse because attackers can industrialise credential theft at scale.

Failure mechanism: Phishing-resistant controls block replay and origin spoofing, but password-based, OTP-based, and push-based flows can still be captured, proxied, approved, or socially engineered. Where regulators leave the standard open-ended, institutions often preserve fallback methods for recovery or legacy compatibility, and those exceptions become the practical path of least resistance for attackers.

Impact: The likely consequence is higher fraud loss, more account takeover, broader incident response burden, and a slower reduction in attack surface across the sector. Over time, weak authentication also undermines supervisory confidence because institutions cannot prove that critical access paths are consistently protected.

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 NIST SP 800-63, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	AAL / authenticator assurance guidance — Digital Identity Guidelines	Defines stronger authenticators and phishing resistance for regulated login assurance.
Recommendation — Adopt phishing-resistant authenticators for high-risk banking journeys and recovery paths.
CIS Controls v8	6 — Access Control Management	Requires limiting account abuse and strengthening authentication paths.
Recommendation — Remove weak authentication methods from sensitive access paths and enforce stronger account controls.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Maps to governance of authentication strength across critical services.
	GV — Governance	Covers policy-setting and oversight when baseline authentication is regulator-driven.
Recommendation — Set measurable authentication requirements for critical workflows and verify they are enforced. Define and monitor authentication policy obligations for regulated business services.
MITRE ATT&CK	T1566 — Phishing	Explains the primary abuse path that weak authentication leaves exposed.
Recommendation — Detect phishing campaigns that target login reuse and recovery workflows.

Practitioner Guidance

What to prioritise: Start with the highest-value paths first: customer funds movement, employee email, privileged administration, and account recovery. Those are the routes where weak authentication creates the largest blast radius and where exceptions should face the toughest review.

What to verify: Do not trust a policy statement until you can verify enforcement on every login entry point, reset flow, and support-assisted recovery path. If any one of those paths still accepts replayable or socially engineered factors, the control is incomplete.

Decision rule: If a fallback method can be used to reach a high-impact account, treat that fallback as part of the core risk surface, not as a minor exception. The right response is to narrow it, instrument it, and retire it on a defined timeline.

Practitioner takeaway: The real test is not whether phishing-resistant authentication exists somewhere in the estate; it is whether the weakest reachable path can still defeat the stronger ones.