Join our Newsletter — 33% off our NHI Course
Home› FAQ› Authentication, Authorisation & Trust› How should security teams balance customer experience and…
Authentication, Authorisation & Trust

How should security teams balance customer experience and phishing resistance in banking?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 13, 2026 Domain: Authentication, Authorisation & Trust

They should remove avoidable friction from low-risk steps while adding strong verification where money or account changes are involved. The goal is not to make every interaction harder, but to concentrate friction at the point where transaction integrity matters most. That gives banks a better balance between usability, fraud resistance and regulatory assurance.

How to reduce friction without weakening phishing resistance

In banking, the practical balance is to keep routine access quick, but make the highest-risk actions prove harder to abuse. That usually means preserving a smooth path for balance checks, statements, and everyday navigation, while stepping up verification for payee changes, new beneficiaries, password resets, device enrollment, and transfer authorisation. The design principle is simple: friction should track blast radius.

That approach matters because phishing resistance is not just a login problem. Attackers often win by steering customers or staff into a moment where a legitimate channel will approve an illegitimate change, so the control needs to interrupt the step that creates financial or account-impacting risk, not every low-value interaction.

Banking teams should also distinguish convenience from trust. If a step does not move money, change recovery options, or alter contact and authentication details, it often does not need the same challenge level as a transaction that can be monetised immediately.

Where stronger verification belongs

The highest-value place for friction is any action that changes who can access the account, where funds can go, or how future approvals will be made. That includes adding a payee, changing device trust, modifying MFA recovery, raising limits, updating phone numbers or email addresses, and initiating first-use payments to a new destination. These are the points where phishing typically turns into loss.

Good controls use stronger verification at those points without forcing the customer to repeat high-friction checks for every session. Step-up controls work best when they are triggered by risk, context, or transaction type, rather than being applied uniformly to all activity. Banks can keep the journey usable while still treating the sensitive step as the real control boundary.

This is also where phishing-resistant authentication matters most. Passwords and one-time codes may still have a role in legacy journeys, but current guidance increasingly favours stronger authenticators and possession-bound factors for high-risk banking actions. NIST SP 800-63 Digital Identity Guidelines gives the clearest public baseline for authenticator assurance and phishing-resistant sign-in.

Designing for usability, fraud loss, and operational reality

The balance is not achieved by choosing either user experience or security. It comes from removing unnecessary prompts, simplifying recovery, and avoiding overuse of alerts while reserving strong checks for the places where account takeover or payment fraud would actually occur. That reduces abandonment without creating an easy path for social engineering.

For banking teams, the important question is whether the control is aligned to the action, not whether it is visible. A customer should not have to fight the interface to check an account, but they should feel meaningful resistance when trying to change the security state or move money to a new destination. That is a better test of control quality than raw login friction.

Phishing resistance also depends on lifecycle decisions outside the login box. Recovery, help desk scripts, device replacement, and exception handling often become the weakest path because attackers target human-assisted override points when direct authentication is hardened. Workforce Identity Security Guide is useful here because it shows how phishing-resistant MFA, passkeys, account recovery, and session theft intersect in real operations. MFA Guide helps teams compare factors and understand where common MFA bypass patterns still appear.

Change Healthcare breach 2024 and 23andMe credential stuffing 2023 are reminders that weak or reused authentication turns convenience into exposure very quickly once access is obtained.

Risk and Threat Considerations

When friction is placed in the wrong part of the journey, it does little to stop phishing but does increase abandonment and support load. The real danger is over-trusting a low-friction sign-in flow while leaving recovery, payee setup, or payment approval too easy to socially engineer.

Failure mechanism: Attackers bypass weak or overused authentication by phishing, session theft, or help desk manipulation, then use legitimate banking flows to approve account changes or transfers.

Impact: The bank absorbs fraud loss, customer trust damage, and higher manual-review costs, while regulators see a control model that failed to protect transaction integrity where it mattered most.

Standards & Framework Alignment

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

NIST SP 800-63, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-63Digital Identity GuidelinesBanking sign-in and step-up auth should follow phishing-resistant assurance guidance.
Recommendation — Adopt phishing-resistant authenticators for sensitive banking actions and step-up events.
NIST CSF 2.0PR.AA-05 — Protective Technology, Authentication StrengthThe topic is about balancing usable access with stronger auth at high-risk actions.
Recommendation — Use stronger authentication for transaction approvals and account changes.
ISO/IEC 27001:2022A.8.5 — Secure authenticationAuthentication strength and recovery controls shape phishing resistance in banking journeys.
Recommendation — Enforce secure authentication for access, recovery, and sensitive state changes.
NIST SP 800-53 Rev 5IA-2 — Identification and Authentication (Organizational Users)Workforce-controlled banking operations depend on strong user authentication.
Recommendation — Require strong identification and authentication for staff-accessed banking systems.
CIS Controls v8CIS-5 — Account ManagementCustomer and staff account lifecycle choices drive abuse at recovery and change points.
Recommendation — Harden account lifecycle and recovery paths that attackers target.

Practitioner Guidance

What to prioritise: Put the strongest controls on first-time payees, recovery changes, and payment authorisation. Keep routine access low friction, but treat any action that changes future trust as a step-up event.

What to verify: Confirm that your strongest challenge is actually bound to the transaction or account state change, not only to the login event. If a phishing kit can still win by steering the customer into a support or recovery path, the model is incomplete.

Common mistake: Teams often over-invest in making sign-in “secure” while leaving password reset, device enrolment, or beneficiary changes easier to abuse than the login itself.

Practitioner takeaway: The right balance is not lower friction everywhere, it is lower friction where failure is cheap and much stronger proof where the customer can cause irreversible financial or account-state change.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org