Should you allow multiple passkeys per user account?

Should Banks allow multiple Passkeys per User Account?#

Yes. In line with FIDO Alliance guidance and WebAuthn best practices, banks should allow multiple passkeys per user account and let users log in with any active passkey registered to that account.

This is one of the most common policy questions banks face when deploying passkeys and the answer has direct impact on security posture, user experience and operational cost.

Why Passkeys are not like Passwords#

A password is a shared secret. Keeping older ones valid is risky because a leaked secret can be exploited by anyone. That's why only the most recent password works.

A passkey is a public-key credential. Adding a passkey means adding another approved authenticator to the account, not rotating a secret. The private key never leaves the user's device (or credential manager), so having multiple passkeys does not increase the attack surface.

WebAuthn explicitly recommends allowing and encouraging users to register multiple credentials to avoid lockouts if a device is lost.

The real Security Risk: unauthorized Passkey Creation#

The main risk is not that multiple passkeys exist. It's that an attacker creates an unauthorized passkey (e.g. using phished credentials or a hijacked session to enroll their own device). That's why passkey creation should be protected more strictly than passkey login.

Recommended Safeguards for Passkey Creation#

• Step-up / re-authentication right before adding a new passkey (fresh biometric check, trusted device verification, risk-based challenge).
• excludeCredentials to prevent duplicate passkeys on the same authenticator and reduce user confusion.
• Passkey management UX that lets users list, rename and remove passkeys so stale credentials don't linger.
• WebAuthn Signal API to proactively clean deleted passkeys from client credential managers.

Why a "one Passkey only" Policy hurts in Production#

Consumers live in a multi-device world. Passkeys are not automatically available everywhere. Different OS ecosystems (iOS, Android, Windows, macOS) and different credential managers mean a single passkey rarely covers all devices a user needs.

Restricting to one passkey creates:

• Authentication dead-ends when users sign in from a different device.
• Higher fallback usage (passwords, OTPs) that undermines the passkey rollout.
• Increased support and recovery burden from locked-out users.
• Lower overall passkey adoption as users hit friction early and disengage.

Passkey Intelligence data shows a meaningful share of users attempt sign-in from a different device within months. That's exactly when a one-passkey policy becomes painful. Japanese banking deployments have demonstrated these exact limitations in production.

Recommended Passkey Policy for Banks#

A pragmatic, security-first policy that works at scale:

1. Allow Multiple Passkeys per Account#

Let users register passkeys on every device they use. This maximizes coverage and minimizes fallback.

2. Treat Passkey Creation as a High-Risk Event#

Apply step-up authentication, trusted device policies and risk-based checks before any new passkey is enrolled. This prevents unauthorized passkey addition (the actual threat vector).

3. Apply Risk-Based Rules for sensitive Actions#

Allow any active passkey for everyday login, but require a device-bound security key (e.g. a YubiKey) for high-risk operations:

• Adding another passkey
• Changing recovery methods
• Large value transfers
• Modifying account settings

This approach maps well to risk segmentation and lets banks layer synced passkeys for convenience with device-bound passkeys for high-assurance actions.

Synced Passkeys + device-bound Security Keys: A Combined Approach#

For consumer banking use cases, combining synced passkeys for everyday login with device-bound security keys as backups or step-up authenticators provides the best of both worlds:

• Synced passkeys cover multi-device convenience across ecosystems.
• Device-bound hardware security keys provide a non-phishable, non-syncable second factor for high-risk actions.
• YubiKey logistics can be supported at scale for large banking deployments.

In shared or managed device environments - e.g. branch terminals, kiosks or family tablets - multiple passkeys per account become even more important. A single synced passkey tied to one user's iCloud Keychain is useless on a shared workstation. Device-bound keys let each authorized user authenticate on the same hardware without exposing credentials across accounts.

Conclusion#

Banks should allow multiple passkeys per account, protect passkey creation as a high-risk event, and use risk segmentation to layer security for sensitive operations. This approach follows FIDO guidance, handles the multi-device reality, and addresses the real threat - unauthorized passkey enrollment - rather than restricting legitimate users.