Passkeys in banking show where phishing-resistant IAM pays off

At a glance

What this is: This case study shows a credit union moving members to passkeys and reporting early adoption gains, including more than half of authentications using passkeys.

Why it matters: It matters because IAM teams responsible for human identity can see how phishing-resistant authentication changes both security posture and user experience when password-based logins and MFA friction are already failing.

👉 Read Authsignal's case study on First Credit Union's passkey rollout

Context

Passkeys replace reusable passwords with phishing-resistant cryptographic authentication, which changes the control problem from secret memorisation to device-bound verification. In consumer banking, that matters because account takeover risk and login friction often sit in the same workflow, and First Credit Union was trying to address both at once across mobile and web channels.

The broader identity governance issue is not whether passkeys are fashionable, but whether organisations can make stronger authentication usable enough to be adopted at scale. For IAM teams, this is a human identity problem first, then a platform integration problem, because users will not absorb a control that slows them down or breaks across devices.

The case is typical of modern financial services programmes that have outgrown password-only and app-push MFA patterns. It is also representative of the operational questions that arise when a standards-based authentication change has to work across existing systems rather than in a greenfield app.

Key questions

Q: How should banks roll out passkeys without breaking existing customer login flows?

A: Banks should start with the full authentication journey, not just the credential itself. That means mapping enrolment, device change, account recovery, and support-assisted exceptions before launch. The goal is to ensure passkeys fit existing mobile and browser workflows without forcing users back to passwords or weaker fallback methods.

Q: When do passkeys reduce risk more than they increase user friction?

A: Passkeys reduce risk when they replace password-based or OTP-driven authentication in flows that are heavily exposed to phishing and account takeover. They increase friction when recovery is clumsy, device changes are poorly handled, or unsupported fallback options remain in place. The right decision is to measure both assurance and journey completion.

Q: What do organisations get wrong about passwordless authentication?

A: They often assume that enabling passkeys automatically solves identity risk. In practice, the weakest points move into enrolment, recovery, and help desk processes. If those paths are not governed tightly, the organisation preserves a phishing-resistant login while reintroducing risk through administrative exception handling.

Q: How do teams know whether a passkey programme is actually working?

A: Look for sustained enrolment, high successful-authentication rates, and low reliance on passwords or backup factors. Then check whether recovery cases remain rare and controlled. A passkey programme is working when users adopt it willingly and the identity team can prove that exceptions do not become the normal path.

Technical breakdown

Why passkeys change the authentication trust model

Passkeys use public key cryptography so the private key stays on the user’s device or synced credential store, while the server only verifies a signed assertion. That means there is no shared secret to phish, replay, or reuse across sites. In practice, the security gain comes from binding authentication to the origin and device context, which removes a large class of credential theft attacks that target passwords and OTP flows. The remaining governance question is whether the organisation can support registration, recovery, and device changes without reintroducing weaker fallback paths.

Practical implication: treat fallback authentication and account recovery as part of the control design, because that is where passkey programmes often lose their phishing resistance.

Cross-device passkey adoption and user experience

Passkey adoption depends on whether the credential can move with the user across phones, tablets, and browsers without creating confusing enrolment steps. Synced passkeys help reduce friction, but they also shift trust into the platform ecosystem that manages the credential. That makes user experience and security inseparable: if registration, sign-in prompts, or recovery flows are awkward, users revert to passwords or alternate factors. First Credit Union’s result suggests that adoption improves when the control is embedded into the existing journey rather than presented as an extra security step.

Practical implication: map every login and recovery path before rollout, then remove any step that forces users back to passwords or unsupported second factors.

FIDO-certified deployment and banking system integration

A FIDO-certified passkey deployment is not just about enabling WebAuthn. It also requires the identity layer, app surfaces, and downstream banking workflows to recognise the new authentication state consistently. That usually means handling device enrolment, session management, and step-up checks without breaking customer flows. In regulated environments, the control has to fit within existing access policies and audit expectations, especially where multiple channels such as mobile and browser access the same account. The architecture succeeds only when authentication strength and application integration stay aligned.

Practical implication: verify that your session handling, step-up logic, and customer support workflows all understand passkey state before expanding enrollment.

NHI Mgmt Group analysis

Passkey adoption is now a human IAM governance problem, not just an authentication upgrade. The security value of passkeys is clear, but the organisational work shifts into enrolment, recovery, device lifecycle, and exception handling. Once a programme reaches real adoption, the question is no longer whether the technology can authenticate users, but whether the identity team can govern the full lifecycle without weakening the phishing-resistant posture. Practitioners should treat passkeys as a policy and operating model change, not a feature toggle.

Password friction and MFA fatigue are still the real blockers to stronger customer authentication. First Credit Union’s case shows that users will move when the alternative is easier and more trustworthy, not merely more secure on paper. That is a useful reminder for IAM programmes that keep layering factors onto a broken login experience. If authentication design does not reduce friction, users will route around it or resist adoption, and governance outcomes will suffer.

Standards-based authentication wins when integration debt is managed deliberately. Passkeys can only scale when existing mobile, browser, and banking workflows can interpret the credential state consistently. That makes integration discipline, not marketing around passwordless, the deciding factor for deployment quality. For identity teams, the lesson is to evaluate whether the surrounding application estate can actually absorb a new authenticator class without creating hidden fallback paths.

Device-bound authentication changes the attack surface, but it does not eliminate identity operations risk. The weak point moves from password theft to enrolment abuse, recovery weakness, and account support workflows. That is why passkey programmes need governance around who can rebind a credential, when recovery is allowed, and how support staff verify identity under exception conditions. Practitioners should measure the control by its recovery integrity, not only by login success rates.

Phishing-resistant auth is becoming a baseline expectation in consumer identity programmes. Banking customers increasingly expect simple sign-in without the security trade-offs that came with passwords and OTPs. That does not make passkeys universal by default, but it does mean password-centric estates will face growing pressure to justify their risk and usability model. IAM leads should use this shift to reassess where legacy authentication is still tolerated without a business reason.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, showing that control design still depends heavily on user behaviour.
• For adjacent identity work, see Ultimate Guide to NHIs , The NHI Market for how governance expands beyond human authentication.

What this signals

Passkey programmes are becoming a test of whether identity teams can reduce friction without weakening assurance. The operational challenge is not the cryptography, it is the governance around recovery, fallback, and support exceptions. Teams that separate authentication design from lifecycle operations will miss the point and create new holes where passwords used to be.

Customer identity teams should expect passkeys to shift investment from login hardening to journey engineering. That means more attention to device change flows, support scripts, and policy decisions about when an account can be rebound. If those paths are not designed carefully, adoption gains can mask a brittle control surface.

For broader identity lifecycle context, see Ultimate Guide to NHIs , The NHI Market and use the same governance discipline when credentials belong to people, services, or machine workloads.

For practitioners

• Map every fallback path before rollout Inventory password resets, backup factors, and account recovery steps so they do not silently undo the phishing-resistant properties of passkeys.
• Test cross-device enrolment and recovery journeys Validate mobile, browser, and support-assisted flows end to end, including cases where users change phones, lose access, or move between platforms.
• Align passkey state with session and step-up policy Make sure applications can recognise registered, enrolled, and recovered passkey states consistently before extending the programme across more banking channels.
• Measure adoption alongside exception handling Track enrolment, successful sign-in, fallback use, and recovery outcomes together so the programme does not optimise for volume while weakening assurance.

Key takeaways

• Passkeys can materially improve consumer authentication, but only if the surrounding recovery and fallback paths are governed as tightly as sign-in.
• The reported adoption results show that users will move to phishing-resistant authentication when the experience is simpler than passwords and app-based MFA.
• IAM teams should treat passkey rollout as an operating model change, with explicit controls for enrolment, device changes, exception handling, and assurance measurement.

Key terms

• Passkey: A passkey is a phishing-resistant authenticator that uses public key cryptography instead of a reusable password. The private key remains on the user’s device or synced credential store, while the service verifies a signed challenge, reducing exposure to credential theft and replay attacks.
• Phishing-Resistant Authentication: Phishing-resistant authentication is a sign-in method that cannot be easily captured and replayed by an attacker through fake login pages or social engineering. It typically relies on origin-bound cryptographic proof, which makes the authentication event tied to the genuine service rather than a lookalike site.
• Fallback Authentication Path: A fallback authentication path is an alternate way to regain access when the primary method fails, such as password reset, backup codes, or help desk verification. In passkey programmes, fallback paths are often where assurance is weakened, so they must be governed as carefully as the main login flow.
• Customer Identity Journey: A customer identity journey is the full sequence of enrolment, login, recovery, device change, and support interactions that shape how a person authenticates over time. For passkey programmes, it is the operational surface where security and usability either reinforce each other or collide.

What's in the full article

Authsignal's full case study covers the operational detail this post intentionally leaves for the source:

• Step-by-step deployment sequence for FIDO-certified passkeys across a banking environment
• Member adoption metrics and the rollout lessons that shaped the programme
• Implementation details on how the passkey experience fit with existing customer channels
• The practical considerations behind secure enrolment and support-assisted recovery

👉 Authsignal's full case study covers the deployment steps, adoption results, and implementation lessons in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.