How should banks evaluate passkeys as a replacement for passwords in customer authentication programs?

Banks should evaluate passkeys as part of a broader shift toward phishing resistant authentication, not as a standalone convenience feature. The core question is whether the organisation can reduce password dependency while preserving strong identity proofing, device binding, and recovery controls. A successful rollout should lower fraud risk, improve user experience, and fit into existing authentication and assurance workflows.

What banks should actually test before replacing passwords

Banks should evaluate passkeys as an authentication upgrade, not as a simple swap for a password field. The real test is whether the new flow improves phishing resistance, reduces account takeover exposure, and still supports strong proofing, safe device binding, and recovery paths for customers who change phones, lose access, or use multiple devices.

That makes the decision less about user convenience and more about whether the bank can preserve assurance across enrollment, sign-in, step-up authentication, and fallback. A passkey program that looks strong in the happy path can still fail if recovery is weak, if help desk processes can be socially engineered, or if the bank cannot distinguish legitimate device changes from takeover attempts.

For a customer program, the most important design question is whether passkeys are being introduced inside an existing CIAM and fraud model or as a disconnected feature. NHIMG’s Customer IAM (CIAM) Guide is useful here because customer authentication, account recovery, and takeover resistance need to be evaluated together, not separately.

How passkeys change the bank’s risk model

Passkeys can remove reusable passwords from the attack path, which is a major improvement against phishing and credential stuffing. They also reduce dependence on memorised secrets, which means banks can shift some risk from secret theft to device compromise, enrollment abuse, and recovery abuse. That is a better trade-off only if the bank can manage device binding and lifecycle controls with discipline.

The practical change is that attackers have fewer easy entry points, but the remaining ones matter more. If a criminal can still hijack account recovery, enroll a new device through weak verification, or exploit a compromised session, the program may improve surface security without materially lowering fraud. This is why passkeys are best judged as part of the full authentication system, not as a standalone control.

NHIMG’s Passwordless and Passkeys Guide is a useful companion for the control choices behind phishing-resistant sign-in, while the NIST SP 800-63 Digital Identity Guidelines provide the assurance framing banks typically need when they evaluate authenticators, enrollment, and recovery.

Passkeys also change the bank’s dependence on the customer device. That can be a strength if the device is bound well and the authenticator is protected, but it creates concentration risk if the program assumes every customer has a stable, modern device and a reliable recovery channel. Banks should expect mixed device portfolios, lost-device events, and users who rely on shared or secondary devices.

Where passkey programs usually fail in practice

The most common failure is treating passkey enrollment as the finish line. In reality, the attack surface shifts to account recovery, support workflows, and exception handling. If help desk staff can reset access too easily, or if a bank allows high-risk recovery paths after minimal verification, the password has been removed but the takeover problem remains.

Another failure mode is overestimating the protection provided by a single phishing-resistant factor. Passkeys are strong against many phishing flows, but banks still need to think about session theft, device compromise, malware on the endpoint, and fraud in downstream banking actions. A stronger sign-in method does not automatically secure every step that follows authentication.

The other issue is operational: rollout friction can push customers, agents, and support teams into unsafe shortcuts. Banks should expect higher failure rates at enrollment if the UX is not clear, if device onboarding is inconsistent across platforms, or if the bank does not have a clean path for lost access. NHIMG’s Workforce Identity Security Guide is not customer-focused, but its coverage of passkeys, account recovery, and help desk reset abuse is relevant to the same failure pattern: recovery is often the weakest link.

Banks should also avoid assuming that passkeys eliminate all forms of phishing-like abuse. Social engineering can move upstream into device enrollment, recovery support, or consent-style prompts, which means the bank still needs monitoring for unusual authentication events and unusual changes in trusted devices.

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 SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Passkeys, assurance levels, enrollment and recovery are central to customer authentication.
Recommendation — Use AAL and authenticator guidance to assess phishing resistance, enrollment strength and recovery risk.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Authentication assurance and access control are central to replacing passwords with passkeys.
Recommendation — Apply IA-2 to require strong authentication and controlled sign-in paths for sensitive access.
ISO/IEC 27001:2022	A.5.15 — Access control	Banks must govern access decisions and authentication methods as part of customer access design.
Recommendation — Define access-control requirements for passwordless sign-in, recovery and exception handling.
OWASP ASVS	V6 — Authentication	Passkey evaluation depends on authentication assurance, enrollment and recovery requirements.
Recommendation — Use V6 to verify authentication strength, recovery flow and phishing resistance.
CIS Controls v8	CIS-5 — Account Management	Customer authentication programs depend on lifecycle control of accounts and recovery paths.
Recommendation — Harden account enrollment, recovery and deprovisioning workflows that support passkeys.

Practitioner Guidance

What to prioritise: Evaluate passkeys first on fraud reduction and recovery integrity, not on login convenience. If the recovery path is weaker than the password flow you are replacing, the program is not ready.

What to verify: Test whether a customer can lose a device, recover access safely, and remain resistant to social engineering. Verify that step-up authentication still works for high-risk actions and that support staff cannot bypass the intended assurance level too easily.

Decision rule: If passkeys materially improve phishing resistance but weaken recovery, treat the rollout as partial and limit it to lower-risk cohorts or use cases until the exception model is hardened.

What good looks like: Customers can sign in without passwords, recover access through strong controls, and complete high-risk banking actions without creating a new soft spot in the help desk or enrollment process.

Practitioner takeaway: Passkeys are a strong replacement for passwords only when the bank replaces password risk with a better end-to-end assurance model, not when it simply swaps one login mechanism for another.