Bitwarden passkeys — store, sync, and use FIDO2 credentials
Passkeys are the closest thing the password world has had to a real upgrade in twenty years — phishing-resistant, biometric-unlocked, no shared secret to leak — and Bitwarden has supported storing them since version 2024.6. This page is the practical guide: what a passkey actually is, how Bitwarden stores them, how the sign-in flow works in your browser and on mobile, and where Bitwarden's passkey support still differs from Apple's or Google's defaults.
Bitwarden stores passkeys (FIDO2 credentials) inside your encrypted vault, syncs them across all your devices, and presents them through the browser extension when sites prompt for passkey login. Free tier — no Premium required. Works in Chrome, Edge, Firefox, Brave, and Bitwarden's mobile apps with iOS 17+ / Android 14+.
What a passkey actually is
A passkey is a public-key credential governed by the FIDO2 / WebAuthn standards. When you "create a passkey" for a website, your device generates an asymmetric keypair: the public key is sent to the site (which stores it like it would store a password hash), the private key stays on your device, encrypted at rest. To sign in, the site sends a challenge; your device signs the challenge with the private key; the site verifies the signature with the public key. There's no shared secret to leak, no password to phish, no reuse problem.
Two things follow from this design:
- Phishing resistance is built in. The browser binds the passkey to the exact origin (domain) it was registered with. A phishing site at a lookalike domain cannot present the same passkey because the origin doesn't match — the credential simply doesn't exist for that site as far as your device is concerned.
- The private key never leaves your device or vault. What gets sent over the network on each login is a single-use signed challenge, not the key itself. Even a complete server breach doesn't help the attacker — they got the public key, which is worthless without the private one.
Passkeys don't replace 2FA layered on a password — they replace the password and the second factor in one credential, because the device-binding gives you "something you have" and the biometric/PIN unlock gives you "something you are/know."
Why store passkeys in Bitwarden specifically
The default passkey stores are platform-bound:
- Apple iCloud Keychain — passkeys sync to other Apple devices on the same Apple ID. Don't show up on Android, Windows, or Linux.
- Google Password Manager — passkeys sync to Chrome and Android devices on the same Google account. Don't show up on iOS Safari, Firefox, or non-Chrome browsers.
- Windows Hello — passkeys live on the Windows device. No sync.
If your devices are all Apple, iCloud Keychain works. All Google, Google PM works. Mixed ecosystem — Mac at home, Windows at work, Android phone — and the platform stores stop being practical because each ecosystem only sees its own passkeys. You end up creating duplicate passkeys per device for the same site, which defeats most of the convenience.
Bitwarden is ecosystem-neutral. The same vault holds your passkeys, syncs them across Windows, Mac, Linux, iOS, Android, and every browser, and presents them through a single autofill UI. For a multi-platform user this is the actual differentiator.
Plus passkeys live alongside passwords in Bitwarden — many sites support passkeys for some users and not others, or have a fallback password. Keeping both in the same vault means one tool, one autofill flow, regardless of which credential type the site asks for today.
Where Bitwarden passkeys work
| Platform / browser | Create | Sign in | Notes |
|---|---|---|---|
| Chrome (desktop) | Yes | Yes | Best-supported path |
| Edge (desktop) | Yes | Yes | Same engine as Chrome |
| Firefox (desktop) | Yes | Yes | Stable since FF 122 |
| Brave (desktop) | Yes | Yes | Chromium-based |
| Safari (Mac) | Limited | Yes | Safari prefers iCloud Keychain; Bitwarden as fallback |
| Bitwarden iOS app | Yes (iOS 17+) | Yes | Through Credential Provider extension |
| Bitwarden Android app | Yes (Android 14+) | Yes | Through Credential Manager API |
| iOS Safari | Limited | Yes | Bitwarden registers as a credential provider |
| Android Chrome | Yes | Yes | Credential Manager picks Bitwarden |
The pattern: desktop browsers via the Bitwarden extension are the strongest path. Mobile passkey support is solid on iOS 17+ and Android 14+ — older OS versions don't expose the credential-provider hooks Bitwarden relies on, so you fall back to platform stores.
Creating a passkey
The user flow is simple — most of the work happens in the browser:
- On a passkey-supporting site (Google, GitHub, Microsoft, Amazon, eBay, Best Buy, dozens of others), find the security or sign-in settings and choose "Add passkey" / "Sign in with passkey".
- Browser presents a passkey-creation prompt — Chrome will offer to save in Google Password Manager by default; click "Other devices" or the dropdown to choose Bitwarden.
- Bitwarden extension prompts: vault unlock if locked, then asks which item to attach the passkey to (existing item or new).
- Done. The passkey is saved into the vault item, encrypted, and syncs to your other devices.
Tip: if the browser doesn't show Bitwarden as an option, check that the extension is up to date and the "Use Bitwarden for passkey storage" preference is enabled in extension settings. Chrome occasionally needs a restart to pick up the change.
Signing in with a passkey
Reverse flow:
- Site presents "Sign in with passkey" or detects a passkey-eligible account on the username field.
- Browser surfaces credential picker — Bitwarden's saved passkey for that origin appears.
- Click the passkey, unlock Bitwarden vault if locked, biometric/PIN if required by the site.
- Signed in. No password entry, no TOTP, no anything.
The single round-trip on a passkey login is roughly twice as fast as password + TOTP and dramatically faster than password + email-link 2FA.
Passkeys on iOS and Android
iOS 17 and Android 14 added system-level credential-provider APIs that let third-party apps register as passkey stores. Bitwarden ships those integrations:
- iOS 17+: Settings → Passwords → Password Options → Credential Providers → Bitwarden. Once enabled, Safari, Chrome, and any app that prompts for passkey credentials will surface Bitwarden's vault alongside iCloud Keychain.
- Android 14+: Bitwarden registers as a Credential Manager provider automatically once the app is installed. Settings → Passwords & accounts → Credential providers to verify Bitwarden is enabled.
On older OS versions (iOS 16 and below, Android 13 and below), passkey API hooks aren't available — Bitwarden can store passkeys for use on desktop or in its own app, but system-level autofill into Safari / Chrome won't pick them up. Upgrade if you can.
Cross-device passkey flows (QR-code "hybrid")
Sometimes you need to sign in on a device that doesn't have your vault — a friend's laptop, a kiosk, a temporary work computer. The cross-device passkey flow handles this:
- Site shows a QR code on the login page.
- Scan the QR with your phone (which has Bitwarden installed and your passkey synced).
- Phone confirms the sign-in via Bluetooth proximity check (the phone has to actually be near the laptop).
- Laptop logs you in.
This is the WebAuthn "hybrid" / CTAP2 cross-device flow. Bitwarden mobile apps support it; the laptop does not need Bitwarden installed. Useful for occasional cross-device login without exporting your vault to a strange device.
How passkey sync works
Sync uses the same end-to-end encryption Bitwarden uses for the rest of your vault. The passkey's private key is encrypted client-side with your master-password-derived key, sent to Bitwarden's server as ciphertext, replicated to your other devices, decrypted on each device when you unlock the vault.
Practical implication: there's no separate "enable passkey sync" toggle. If your vault syncs, your passkeys sync. If you self-host on Vaultwarden, passkeys sync within your self-hosted instance the same way other items do.
Recovery if you lose access
The recovery story for passkeys mirrors the recovery story for the rest of the Bitwarden vault: master password → vault → passkeys. Lose the master password without recovery options and the passkeys go too. Three mitigations:
- Set up Emergency Access with at least one trusted contact. They can request vault access after a configurable wait period.
- Keep an encrypted JSON export of your vault as backup — see our export guide. Includes passkeys; restoring re-creates them on a new vault.
- For high-value sites (banking, primary email), keep a hardware security key (YubiKey) as a parallel passkey or backup factor outside Bitwarden. Belt and suspenders.
Most users don't need step three. The first two are enough for normal threat models.
Current limits and gotchas
- Discoverable credentials only. Bitwarden currently stores discoverable (resident) passkeys, where the site asks "do you have a passkey for this account?" Non-discoverable passkeys (older FIDO2 patterns) aren't supported — relevant for a tiny minority of legacy implementations.
- Some sites force-default to platform stores. A handful of high-volume sites — Apple ID, parts of Google's auth flow — strongly prefer iCloud Keychain or Google PM and require manual workarounds to get Bitwarden into the picker. Improving over time.
- Browser extension version matters. Pre-2024.6 Bitwarden extensions don't support passkeys. Pre-2025.x extensions miss some of the cross-device flow polish. Keep extensions auto-updating.
- No passkey export to other managers. The FIDO Alliance has a draft spec for cross-vendor passkey portability (CXF), not yet shipping in any major manager. For now, switching password managers means re-creating passkeys on each site, just like switching from iCloud Keychain to Google PM today.