Passkeys Rollout: The Implementation Decisions Most Teams Get Wrong
Cybersecurity
Passkeys are mainstream in 2026 — Apple, Google, Microsoft all push them by default. Implementing them as a SaaS provider has six decision points where most teams pick the wrong default. Here are the choices that matter.
By Arjun Raghavan, Security & Systems Lead, BIPI · March 20, 2026 · 7 min read
By 2026 passkeys are the default authentication offer on the major operating systems. Apple's Passkeys API, Google's Credential Manager, Microsoft's Authenticator and Windows Hello all push them ahead of passwords. For a SaaS implementing passkey support, the technology is mature, the user mental model is finally landing, and the implementation choices are where most teams introduce friction or weaken the security gain.
Below: six decisions that determine whether your passkey rollout actually improves security and adoption, or just adds another login option that nobody uses.
1. Synced passkeys vs device-bound
Synced passkeys (the default Apple, Google, 1Password, Dashlane all create) are convenient for users — the credential follows them across devices. They are also less restrictive than device-bound credentials; a user with iCloud Keychain enabled can authenticate from any of their Apple devices.
Device-bound passkeys (created via the platform-credential-only flow with attestation) are stronger but cannot recover if the device is lost without an enrolment of a backup device.
For most SaaS, synced passkeys are the right default. Device-bound is the right choice for high-assurance environments (financial admin, government). Pick deliberately. The default API call gives you synced.
2. Username-first vs username-less flow
Two UX patterns. Username-first: user types email, then passkey prompt fires. Username-less: user clicks 'sign in with passkey', the platform shows them which accounts they have credentials for, they pick one.
Username-less is the modern approach and what users now expect. It requires that the credential be stored with the user identifier on the platform side, which the FIDO2 spec supports as a 'discoverable credential'. Most teams default to username-first because their existing login form already has the email field. Migrating to username-less takes one engineering sprint and improves login completion measurably.
3. Account recovery: do not store the password
Most rollouts add passkeys alongside passwords. The user is told 'we recommend passkeys' but the password remains. The password becomes the recovery path and also the weakest link.
Stronger pattern: after passkey enrolment, deprecate the password. Recovery uses a different mechanism — verified email + a one-time code, social-recovery contacts, or hardware-backed recovery codes. The password as a permanent recovery path means an attacker who phishes the password bypasses the passkey entirely.
4. Cross-device sign-in (CDA / hybrid transports)
A user on a desktop can sign in to your service using a passkey on their phone via QR code + Bluetooth. This is the 'hybrid transport' or 'cross-device authentication' (CDA) flow. WebAuthn Level 3 standardised it; all major platforms support it.
Most teams enable CDA without thinking. It is a strong feature for users without passkeys on the current device, but it requires Bluetooth proximity, which is a privacy and threat-model consideration. The flow includes a domain check that prevents most relay attacks; in 2026 we do not see active CDA-relay attacks in the wild.
5. Multiple passkeys per account, not one
Allow users to register multiple passkeys. The phone passkey, the laptop passkey, the YubiKey backup. Some teams limit to one credential per account because their schema was designed that way; this pattern produces lock-out scenarios when the device is lost.
We require at least two passkeys for any account that disables passwords, ideally one synced and one device-bound. UX flow: after first passkey enrolment, prompt 'add a backup device' before the user can disable password sign-in.
6. Audit logging of passkey events
New passkey added. Passkey removed. Passkey-based sign-in from a new device or geolocation. Each event is a security-relevant change to the account's authentication posture. Log them at the same level as password changes. Surface them in the user's security dashboard so they see when something has changed.
Closing
Passkeys are a real upgrade over passwords. The upgrade depends on the implementation choices. Synced passkeys for most users, device-bound for high-assurance, username-less by default, password deprecation after enrolment, multiple passkeys per account, hybrid-transport enabled, audit logging at the same tier as password events. Get those six right and your authentication system is materially harder to phish than the version it replaced.
Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.