Passkeys vs Password Managers: Which Accounts Go Passkey and Which Stay Vaulted

Passkeys and password managers are often framed as rivals, but in a real organisation they solve different problems and most estates need both for years. A passkey replaces a shared secret with a key pair bound to one website, which removes phishing and server-side credential theft for that account. A password manager stores the secrets that still exist: passwords for systems without passkey support, shared team logins, recovery codes, and in many cases the passkeys themselves. The practical question is not which one wins, but which accounts move to passkeys, which stay vaulted, and whether each passkey should be synced or device-bound. This guide is for identity and IT teams planning that split. For plain-language background, see the Passkeys for Everyone Guide and the Password Managers Explained for Everyone Guide; this page does not repeat them.

Key takeaways

• They are layers, not alternatives. A password manager is often the passkey provider, so the decision is which credential type each account uses and where that credential lives.
• Passkeys remove phishing; vaults only reduce it. Autofill refuses to fill on the wrong site, but a user can still copy and paste a password into a fake page. A passkey cannot be presented to the wrong origin at all.
• Synced and device-bound passkeys carry different risks. NIST SP 800-63B-4 limits syncable authenticators to AAL2, because syncing means the key can be exported; AAL3 needs a non-exportable key.
• The vault becomes the crown jewel. Once a manager holds passkeys, passwords and recovery codes, the account protecting it needs the strongest authentication you have, ideally a device-bound passkey or security key.
• Machine credentials never fit passkeys. API keys, service account secrets and deploy keys belong in a secrets manager with workload identity, not in a human vault and not in a passkey.

What each one actually is

A passkey is a FIDO credential: a public and private key pair created by an authenticator for one relying party (RP). The website stores only the public key. At sign-in the authenticator signs a challenge, after verifying the user locally with a biometric, PIN or device unlock. The browser scopes the request to the site's origin, so a look-alike domain gets no valid signature. The FIDO Alliance describes passkeys as phishing resistant by design, and notes that this holds whether or not the keys are bound to hardware.

A password manager is an encrypted store of secrets with generation, autofill, sync and breach warnings. It is unlocked by a primary (master) password, a device unlock or both. Its security depends on three things: the encryption of the vault, the strength of the unlock and account authentication, and the integrity of the endpoint where it is open. NIST SP 800-63B-4 requires verifiers to allow password managers and autofill.

The two overlap because modern password managers act as passkey providers. FIDO lists both operating system and browser credential managers and third-party password managers as places where passkeys are stored and synced. One vault may therefore hold an SSO passkey, legacy portal passwords and backup codes: that concentration is the main design issue. For provider-level controls see the Passkey Providers guide.

Side-by-side comparison

The WebAuthn Level 3 specification, a W3C Recommendation of 25 August 2026, formalises the synced versus device-bound split in two authenticator data flags. Backup Eligibility (BE) is set when the credential is created and never changes: a credential with BE set is a multi-device credential, one without it is a single-device credential. Backup State (BS) reports whether the credential is currently backed up, and can change over time. These flags are how a relying party tells the two kinds apart. See WebAuthn vs FIDO2 vs Passkeys.

Threat model for each option

Vaulted passwords

• Phishing and adversary-in-the-middle: autofill helps, because it will not fill on a domain that does not match. But users override it: they open the vault, copy the password and paste it into the fake page. A one-time code typed alongside the password does not help against a real-time proxy. See the AiTM Phishing Guide.
• Server-side breach: the site holds a hash. If the hash is cracked, the password works until it is changed. A unique generated password confines the damage to that site, the core value of a vault against credential stuffing (ATT&CK T1110.004).
• Vault breach: an attacker who copies encrypted vault data can attempt offline guessing of the primary password. The LastPass 2022 breach showed the shape of this risk: vault backups were copied, some fields such as URLs were not encrypted, and weak primary passwords remain exposed to cracking long after the theft. The Password Manager Vault Breach Response Playbook covers response.
• Endpoint compromise: malware on a device with an unlocked vault can read secrets or capture the primary password. ATT&CK tracks this as T1555.005 Password Managers. Infostealers also take session cookies (T1539), which bypass both passwords and passkeys once a session exists.

Synced passkeys

• Phishing: removed for that account. The private key never leaves the authenticator in usable form and the signature is scoped to the origin.
• Server-side breach: removed for that credential. A stolen public key cannot be used to sign in.
• Sync fabric and provider account takeover: this is the new concentration risk. Whoever controls the account that syncs the passkeys can restore them to a device they own. FIDO itself notes that passkeys synced across devices are vulnerable to theft in ways that device-bound passkeys are not. NIST SP 800-63B-4 requires that only the authenticated user can reach their keys in the sync fabric, and that sync fabric access uses AAL2-equivalent multi-factor authentication.
• Sharing: NIST advises agencies to assume that all syncable authenticators may be subject to sharing for public-facing use, because the verifier cannot see how users share them.

Device-bound passkeys

• Phishing and server breach: removed, as for synced passkeys.
• Theft of the credential: the key cannot be exported from a security key or a platform authenticator that keeps it in hardware, so cloning is out of reach. An attacker needs the physical device and the PIN or biometric.
• Device loss: the main risk shifts from compromise to lockout. Without a second registered authenticator, the recovery process becomes the weakest point, and help desk resets are a well-documented social engineering target. See the Account Recovery and Help Desk Security Guide.

Synced or device-bound: choosing per population

NIST SP 800-63B-4 sets the line clearly: syncable authenticators may be used up to AAL2, and AAL3 requires a cryptographic authenticator with a non-exportable private key that provides phishing resistance. At AAL2, verifiers must offer at least one phishing-resistant option, and federal agencies must require phishing-resistant authentication for staff, contractors and partners. For federal enterprise use of synced passkeys, NIST adds that keys sit in sync fabrics with FISMA Moderate protections or equivalent, that devices use MDM or equivalent controls to stop syncing to unauthorised fabrics, and that sync fabric access uses agency-managed accounts. They make a sensible template for regulated enterprises.

To enforce the choice, the relying party (usually your identity provider) can require attestation and allow only listed authenticator models by AAGUID, or inspect the BE flag and reject backup-eligible credentials for privileged groups. NIST says verifiers may use BE to restrict syncable authenticators, but should not rely on BS for public-facing applications. Platform detail is in the Device-Bound Passkeys guide and the Workforce Passkeys in Entra ID and Okta guide.

Rollout decision table: which accounts go passkey, which stay vaulted

Where machine identities fit: secrets that never become passkeys

A passkey is a user authentication ceremony. WebAuthn runs through a browser or platform API, asks for user presence and usually user verification, and binds the credential to a human account at a relying party. Non-human identities authenticate with tokens, client credentials, certificates or federated workload identity, and those belong in a secrets manager or, better, are replaced by short-lived credentials issued at runtime. NIST SP 800-53 IA-5(7) (No Embedded Unencrypted Static Authenticators) is the relevant control.

The common anti-pattern is a cloud access key or production token sitting in an engineer's personal or team password vault. The LastPass case is instructive here as well: the attacker reached cloud storage using access keys and decryption keys held in a DevOps engineer's corporate vault. Moving people to passkeys does nothing for those secrets. Inventory them, move them to a secrets manager, and replace them with workload identity where the platform supports it. See the Password Manager vs Secrets Manager guide and the Secrets Management Guide.

Recovery, sharing and lifecycle

• Recovery is the real authentication strength. If a lost passkey can be replaced by answering questions on a phone call, the account is only as strong as that call. Require identity proofing for reissue of privileged credentials, and require a second registered authenticator before removing the password. The Passkey account recovery guide covers recovery design.
• Sharing changes the model. Password sharing in enterprise vaults is mature and auditable. Passkey sharing exists in some providers but undermines individual accountability. Prefer one credential per person; reserve shared vault items for genuinely shared accounts.
• Joiners and leavers. Passkeys registered at the identity provider are revoked by removing the authenticator from the user object. Offboarding must also cover vault access and shared collection membership, because passkeys and passwords in shared collections outlive the leaver.
• Portability. Moving passkeys between providers has historically been hard. The FIDO Alliance publishes credential exchange specifications covering passwords, passkeys and more; support across providers varies, so plan migrations as re-enrolment unless both providers support the exchange. See the FIDO Credential Exchange Passkey Portability Guide.

Worked scenario: a 2,500-person professional services firm

The firm runs a cloud identity provider with SSO to 140 SaaS apps, a corporate password manager rolled out two years ago, and around 60 supplier portals that only take passwords. A red-team exercise had phished users through an adversary-in-the-middle proxy that captured password and one-time code together.

1. Month 1: the 45 identity, cloud and help desk administrators receive two security keys each. The identity provider policy for the admin group accepts only attested, device-bound authenticators. The password manager tenant admins move to the same keys.
2. Months 2 to 4: all staff enrol a synced passkey for SSO in the corporate provider on managed laptops and phones. Locked-out users enrol with a manager-approved temporary access pass. OTP stays enabled during this phase.
3. Month 5: once 95% of active users have a passkey and at least two devices, OTP and password sign-in are removed for SSO, with a documented exception group that is reviewed monthly.
4. Ongoing: the 60 supplier portals stay vaulted with generated passwords. They are reviewed quarterly for SSO or passkey support. A scan of the vault finds 14 cloud and API tokens in team collections; these move to the secrets manager and are rotated.

How to implement: phased approach

1. Inventory and classify. Export a list of vault items by domain and type. Mark each as federated, passkey-capable, password-only, shared, recovery material or machine secret.
2. Harden the vault first. Protect the password manager account and its admin console with phishing-resistant authentication before you put passkeys in it. Review the primary password policy and turn on breach and reuse reporting. See Securing the password manager (enterprise) itself.
3. Start with privileged accounts. Device-bound passkeys or security keys for administrators, help desk and break-glass accounts, two per person, with attestation enforced.
4. Pilot synced passkeys for SSO. A ring of 100 to 300 users across device types. Measure enrolment and help desk calls first.
5. Remove weaker fallbacks in stages. First block SMS, then OTP, then passwords for the passkey-enrolled population. Keep a monitored exception group rather than leaving fallbacks on for everyone.
6. Move machine secrets out. Migrate tokens and keys found in human vaults to the secrets manager and rotate them.
7. Roll back safely. If a provider outage or bug blocks sign-in, re-enable a time-limited fallback for an affected group through policy, never by turning off phishing-resistant enforcement for administrators.

The Passkey Rollout Guide covers communications and enrolment UX in depth.

Decision guidance and trade-offs

• Passkey by default: wherever the relying party supports it and one person uses the account. Vault where there is no passkey or SSO support, where a shared account allows only one credential, or for recovery material. Device-bound where takeover would be estate-wide or AAL3 is required; synced where lockout cost dominates and AAL2 is enough.
• Small organisations can often rely on the platform or password manager they already have as the passkey provider, with security keys only for the two or three admin accounts. Large organisations need attestation policy, provider allow-lists, managed sync accounts and a recovery process with identity proofing.

Detection and measurement

Log authenticator registration and removal events at the identity provider, sign-in method per session, fallback use (password, OTP, SMS) by passkey-enrolled users, vault admin actions, vault exports and shared collection membership changes. Alert on a passkey registered soon after a password reset, on repeated MFA prompts (ATT&CK T1621, as in the Uber 2022 breach), and on vault exports by non-admins.

• Passkey coverage: share of active workforce users whose SSO sign-ins in the last 30 days were all passkey-based.
• Privileged device-bound coverage: share of admin accounts with two attested device-bound authenticators.
• Fallback rate: share of sign-ins by enrolled users that used a non-phishing-resistant method.
• Vault hygiene: count of reused, weak or breached passwords in the corporate vault, trending down.
• Machine secrets in human vaults: count of API keys, tokens and cloud credentials found in password manager items, target zero.
• Recovery quality: share of passkey reissues that followed the documented identity-proofing process.

Common failure patterns

• Passkey on top, password still underneath. Users enrol a passkey but the password and SMS code still work, so attackers simply use the old path.
• Vault protected by a credential stored in the vault. Recovery codes for the password manager kept inside the password manager leave no way back and no separation.
• Synced passkeys for admins on personal sync accounts. The organisation cannot control or revoke the sync fabric, so a personal account takeover reaches production.
• One device-bound key and no spare. Loss forces a help desk reset, which becomes the attack path.
• Cloud keys in a team vault. Long-lived machine credentials stored like human passwords, as in the LastPass case, turn one endpoint compromise into a cloud compromise.
• Assuming passkeys stop session theft. An infostealer that takes a session cookie bypasses the sign-in method entirely. Pair passkeys with session lifetime limits. See the Infostealer Logs and Session Token Abuse Guide.

Framework mapping

Practitioner checklist

• Classify every vault item as federated, passkey-capable, password-only, shared, recovery or machine secret.
• Protect the password manager account and admin console with phishing-resistant authentication first.
• Issue two device-bound authenticators to every administrator, help desk and break-glass account.
• Enforce attestation or reject backup-eligible credentials for privileged groups at the identity provider.
• Roll out synced passkeys for SSO through pilot rings, then remove OTP, SMS and password fallbacks.
• Keep recovery codes in a restricted collection that a single compromise cannot reach.
• Move every API key, token and cloud credential out of human vaults into a secrets manager and rotate it.
• Require identity proofing for reissue of privileged passkeys.
• Review password-only systems quarterly for SSO or passkey support.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NIST: SP 800-63B-4 Syncable Authenticators
• W3C: Web Authentication Level 3
• FIDO Alliance: Passkeys
• FIDO Alliance: Credential Exchange Specifications
• CISA: Implementing Phishing-Resistant MFA
• NCSC: Use a password manager and passkeys

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Passkeys vs Hardware Security Keys · Phishing-Resistant MFA Guide · Password Manager vs Secrets Manager