TL;DR: Financial institutions now need phishing-resistant authentication that works across web, mobile, contact centres, branches, wire approvals, and payment rails, because passwordless web login alone leaves the highest-loss channels exposed, according to Scramble ID. The real control gap is not authentication at the login page but cryptographic identity binding across every customer and employee touchpoint.
At a glance
What this is: This is an analysis of why financial services need phishing-resistant authentication across every customer and employee channel, not only web login.
Why it matters: It matters because IAM and fraud teams have to treat authentication as an omnichannel control that covers human, workforce, and machine-facing paths where losses actually occur.
Context
Financial services authentication is not a single login problem. The real control boundary spans customer web access, mobile apps, call centres, branch interactions, wire approvals, and payment rails, so a design that only hardens the web front end leaves the highest-risk paths outside the trust model.
The governance gap is that legacy authentication patterns still assume the channel is the point of protection. In practice, fraud and account takeover move to the weakest touchpoint, which means identity binding and step-up controls have to follow the transaction, not stop at sign-in.
Key questions
Q: What breaks when authentication is not phishing-resistant?
A: The trust boundary between the user and the system becomes easy to impersonate. Attackers can collect credentials through fake login pages or reuse stolen passwords to enter accounts, which then undermines downstream controls such as access reviews, monitoring, and conditional access.
Q: Why do knowledge-based questions fail as a banking authentication control?
A: Because the answers are often available from breach data, social engineering, or publicly available records, so they do not reliably distinguish the real customer from an impersonator. They may still support low-risk read-only help, but they should not anchor sensitive actions, account changes, or wire approvals.
Q: How do banks know if accessible authentication is actually working?
A: Look for completion rates across user groups, support-assisted sign-in volume, exception requests, and the number of flows that fail under assistive technology testing. If one browser, device, or access mode consistently produces failures, the control is not robust enough for production use.
Q: What is the difference between identity verification and transaction approval?
A: Identity verification answers who or what appears to be asking. Transaction approval answers whether the action should happen. Fraud often works when organisations collapse those two steps into one, allowing a convincing identity signal to trigger an irreversible business outcome without separate control over the decision itself.
Technical breakdown
Phishing-resistant authentication across banking channels
Phishing-resistant authentication means the credential cannot be replayed by a phishing proxy or man-in-the-middle because it is cryptographically bound to the relying party. In financial services, that property only matters if the same binding works across web, mobile, contact centre, branch, and high-risk transaction flows. A passkey on the website does not protect a wire approval or a call-centre reset unless the same identity proof carries through the workflow. The technical challenge is therefore channel consistency, not simply stronger factors.
Practical implication: map every banking channel to the same phishing-resistant trust standard, not just the primary login path.
Cryptographic caller verification and transaction step-up
Call-centre authentication fails when knowledge-based questions stand in for identity. Knowledge factors are easy to harvest, reuse, and script against, so they do not stop impersonation when fraudsters call a bank or a customer. A stronger model uses a device-held cryptographic authenticator to verify the caller before any sensitive action, then applies separate step-up at wire or payment authorization. This separates identity proof from transaction approval and stops a verified session from becoming a blank cheque.
Practical implication: replace KBA as the trust anchor and reserve step-up controls for the transaction itself.
Device-bound credentials and verifier-impersonation-resistant audit trails
The article’s deeper point is that phishing resistance is not only about login ceremony. When a bank binds each customer and employee to a device-held cryptographic credential, the resulting audit trail can show who verified, where the verification occurred, and whether the relying party was legitimate. That matters because regulators and auditors increasingly care about evidence that survives replay, vishing, and delegated approval abuse. In other words, the authentication event becomes a verifiable control record, not just a session token.
Practical implication: preserve authentication evidence that proves the verifier and the action path, not just the sign-in result.
Threat narrative
Attacker objective: The attacker wants to turn a trusted authentication event into authorised money movement, account access, or operational privilege without triggering the bank’s highest-assurance controls.
- Entry begins with credential phishing, credential stuffing, SIM swap, or vishing against customers and bank staff.
- Credential access is then converted into account takeover, caller impersonation, or privileged workforce access through weak trust paths such as SMS or KBA.
- Escalation happens when the attacker uses the verified session to request wires, payment changes, or customer-data actions.
- Impact is realised as authorised fraud, wire loss, or fraudulent account changes that look legitimate in the audit trail.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.
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
Omnichannel authentication is now the real baseline, not web passwordless. Financial institutions do not lose money only at the login page, so a web-only passkey deployment leaves the most lucrative fraud paths untouched. The authentication control has to travel with the customer or employee across call centres, branches, wires, and payment rails. Practitioners should treat channel coverage as the core governance question.
Knowledge-based authentication has stopped being a defensible trust anchor. SSN, date of birth, and transaction history are all weak proofs once fraudsters can harvest them from breach data, social engineering, or synthetic identity workflows. The issue is not just that KBA is outdated, but that it produces a false sense of identity certainty in exactly the channels where vishing and authorised fraud succeed. Teams should reclassify KBA as fallback-only, not primary assurance.
Cryptographic identity binding creates a stronger audit story than factor count alone. Banks do not just need more factors, they need evidence that the verifier, device, and action are tied together in a way that survives replay and impersonation. That is why verifier-impersonation resistance matters for FFIEC, NYDFS Part 500, PCI DSS v4.0.1, and PSD2 SCA scrutiny. The practitioner takeaway is that auditability is part of the control, not a report after the fact.
Named-payee confirmation and dual control are transaction controls, not authentication substitutes. The article makes clear that APP fraud can still succeed even when the customer authenticates correctly. That means organisations must separate identity proof from value transfer approval, especially for wires and high-risk payments. Fraud teams and IAM teams need shared ownership of the decision point where authority becomes irreversible.
From our research library:
- 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure, according to the 2026 Infrastructure Identity Survey.
- U.S. fraud losses are projected to reach $40 billion by 2027.
What this signals
Cryptographic identity binding: banks should expect authentication programmes to shift from channel-specific MFA projects to lifecycle-controlled identity binding across the customer and workforce journey. The operational question is whether recovery, branch verification, and wire authorisation use the same assurance level as sign-in, because otherwise fraud simply relocates to the weakest exception path.
Authentication governance is now a joint IAM and fraud problem. As financial institutions adopt phishing-resistant methods, they also have to redesign fallback, recovery, and approval paths so that a verified session cannot become an unauthorised transfer or an impersonation event.
For practitioners
- Map authentication by channel Inventory every customer and employee touchpoint, including contact centre, branch, wire approval, mobile recovery, and payment rails, then assign a phishing-resistant method to each path.
- Replace KBA as primary trust Move security questions to read-only fallback only and require cryptographic caller verification before any sensitive customer action or account change.
- Bind credentials to devices Issue device-held cryptographic credentials that survive across web and mobile, and make recovery paths use the same assurance level as primary authentication.
- Add step-up at high-risk transactions Require separate cryptographic step-up, dual control, and named-payee confirmation for wire authorisation, new payees, and large transfers.
Key takeaways
- Financial services cannot rely on passwordless web login alone because the real exposure sits in contact centres, branches, wire approvals, and payment workflows.
- The control issue is identity binding across channels, not simply adding more factors at sign-in.
- Banks need separate approval controls for high-value transactions so a legitimate authentication event does not automatically permit money movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | The article centres on phishing-resistant authentication and verifier binding across channels. |
| Recommendation — Apply SP 800-63B to require phishing-resistant authenticators for every high-risk banking channel. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Workforce access and privileged actions are a major part of the article’s authentication model. |
| IA-5 — Authenticator Management | The article stresses credential binding, fallback, and recovery paths that must be managed tightly. | |
| Recommendation — Enforce IA-2 with phishing-resistant MFA for workforce and privileged banking access. Use IA-5 to govern authenticator lifecycle, recovery, and revocation across banking channels. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article ties authentication to transaction approval and access decision quality. |
| Recommendation — Align PR.AA-05 to separate identity proof from authorisation for wires and high-risk actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Device-bound credentials and channel-wide phishing resistance are central non-human identity concerns. |
| Recommendation — Review NHI authentication paths for replayable factors and replace them with cryptographic binding. | ||
Key terms
- Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
- Cryptographic binding: Cryptographic binding links the authenticator to a specific website, application, or verifier so the credential cannot be replayed against a different target. This is the technical property that makes phishing-resistant authentication work. Without it, an MFA flow may still be vulnerable to impersonation even if it uses multiple factors.
- Knowledge-based authentication: A verification method that asks a person to prove identity by answering facts such as past addresses, account details, or other shared information. It is operationally convenient but weak against social engineering, breach data, and impersonation, which is why it performs poorly in high-risk support flows.
- Named-Payee Confirmation: A transaction-control pattern where the customer explicitly verifies the destination payee before authorising a transfer. It does not replace authentication; instead, it adds friction and accountability at the moment money leaves the institution, which is where authorised push payment fraud becomes costly.
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.
Published by the NHIMG editorial team on June 22, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org