Quick reference
The shortest usable answer
| Situation | Use this | Why | Gotcha |
|---|---|---|---|
| Most personal accounts | Synced passkey in Apple, Google, Microsoft, or a password manager | Phishing-resistant and low friction for daily use | Recovery is now the critical design problem |
| Email, bank, cloud root | Passkey plus a second enrollment path and offline recovery codes | If one device dies, you still need a way back in | Do not delete the password fallback before testing recovery |
| Admin or high-risk account | Physical security key or device-bound passkey, plus a backup key | Hardware-backed possession control is harder to phish | One key only is a self-lockout plan |
| Work or school account | Use the organization-approved passkey or security key path | Policy may restrict which authenticators you can register | Managed devices can block consumer-style recovery paths |
| Family shared admin | Shared password or passkey group with explicit owners | Recovery and succession become understandable | Every shared credential expands the trust boundary |
| Legacy account with no passkeys | TOTP app, then security key if offered, then remove SMS fallback | Improves phishing resistance over SMS or push-only | TOTP is still phishable if you type it into a fake site |
Mental model
What passkeys and hardware keys actually are
| Term | Definition | Concrete example | Gotcha / when not to use |
|---|---|---|---|
| Passkey | A FIDO credential that replaces typing a password with a cryptographic sign-in ceremony. | Unlock Gmail with Face ID or a device PIN instead of typing a password. | It is not a typed secret, so password-manager habits do not map 1:1. |
| Synced passkey | A passkey copied into a sync fabric and available on multiple signed-in devices. | An iPhone passkey available on a Mac through iCloud Keychain. | Convenient, but recovery and sync-fabric security matter more than device theft. |
| Device-bound passkey | A passkey that stays on one physical authenticator, often a security key. | A YubiKey stored in a drawer and used only for admin accounts. | Harder to lose through cloud sync, but you must plan for hardware failure. |
| Hardware security key | A dedicated token that performs the private-key operation locally when you touch or insert it. | USB-C plus NFC key used on a laptop and a phone. | Do not keep the only key on the same ring as your everyday keys. |
| WebAuthn | The browser API that creates and uses scoped public-key credentials for a relying party. | A site asks the browser to create a passkey during signup. | Credentials are bound to the site/origin, so fake login pages cannot reuse them. |
| Phishing resistance | The authenticator will not complete the sign-in on an impostor site. | A passkey refuses to sign in to a lookalike domain. | Push approvals and OTPs are often phishable, so do not rank them together. |
| Recovery code | A one-time offline fallback the service issues for account recovery. | Print ten backup codes and store them in a safe or sealed envelope. | They are a last resort, not a second daily login method. |
| Authenticator | The device or software that proves possession of the credential during sign-in. | Phone, laptop, password manager, or security key. | Biometric unlock is local verification, not the server's identity proof. |
Source-backed rule: the FIDO Alliance describes passkeys as FIDO credentials that can be synced or device-bound, and WebAuthn scopes credentials to the relying party/origin. NIST Rev. 4 recognizes syncable authenticators if the sync fabric is protected with AAL2-equivalent MFA.
Comparison table
What to use, and what you are giving up
| Method | Strength | Weakness | Best fit | Decision note |
|---|---|---|---|---|
| SMS code | Better than password-only if nothing else exists | Phishable, SIM-swap risk, number-change recovery risk | Temporary stopgap only | Use only to get to something better |
| Email OTP | Cheap and widely supported | Email account takeover becomes account takeover everywhere | Low-sensitivity sites | Do not treat it as recovery-grade protection |
| TOTP app | Offline code generation beats SMS | Still phishable if typed into a fake site | Legacy services that lack passkeys | Good fallback, not ideal primary auth |
| Push approval | Easy to use | Fatigue attacks and weak phishing resistance | User convenience at low risk | Prefer number matching only if no passkey exists |
| Synced passkey | Phishing-resistant and easy to recover across your devices | Depends on sync fabric and account recovery hygiene | Most personal accounts | The default choice for normal users |
| Hardware key passkey | Non-exportable local key on a dedicated token | Can be lost, damaged, or left home | Admin roots, sensitive accounts, travel reserve | Best when you can keep a backup key offline |
| Smart card / PIV | Enterprise-managed credential with mature policy control | More admin overhead and less consumer-friendly | Corporate fleets and regulated environments | Use when your organization already manages it |
Platform playbooks
How the major ecosystems behave in practice
| Platform | What it does | Useful detail | Operational note |
|---|---|---|---|
| Apple | iCloud Keychain syncs passwords and passkeys with end-to-end encryption. | Shared password groups let trusted contacts share passwords and passkeys. | Good for family or multi-device Apple households, but turning iCloud Keychain off changes what remains local. |
| Passkeys work as a password alternative and can be used with Google Account sign-in. | Google says passkeys are more secure against phishing and do not remove existing recovery factors. | Good default for Android and Chrome; still keep recovery paths because passkeys do not erase old ones. | |
| Google Password Manager | Stores and syncs passkeys across Android and Chrome on signed-in devices. | Cross-device use relies on the same Google account, screen lock, and a Google Password Manager PIN on first setup. | Great for mixed-device users who want one cloud-backed passkey vault. |
| Microsoft | Passkeys can be saved to a device, a synced credential manager, Windows Hello, a phone, or a security key. | Work and school accounts depend on organization support and policy. | Strong for Windows fleets, but managed accounts may restrict which registration options appear. |
| YubiKey / security key | Physical FIDO2/U2F authenticator with USB and NFC options on common models. | Yubico positions security keys as useful with Google, Microsoft, password managers, and many other services. | Best when you want a discrete offline recovery or admin key. |
| YubiKey PIN | Many FIDO2 flows ask for a local PIN before a key can be used. | Yubico says FIDO2 PINs are not set at the factory. | Set the PIN during enrollment so the first loss test is not the first time you think about it. |
Decision guidance
Use the right authentication mix for the threat in front of you
| Profile | Start with | Add next | Do not stop at |
|---|---|---|---|
| Ordinary user | Synced passkey on phone and laptop | Offline recovery codes | Password plus SMS only |
| Family admin | Shared passkey or shared password group for the household root | Backup device and sealed recovery copy | A single person holding the only recovery route |
| Developer | Passkey or security key on GitHub, cloud, and domain registrar | Second key off-site | Push approvals for all critical sign-ins |
| Public figure / high-value target | Device-bound security key for root accounts | Separate travel key and offline recovery | Cloud-only recovery with no local backup |
| Small business admin | Organization-approved security key or managed passkey | Documented recovery and ownership handoff | Consumer-only recovery assumptions |
| Managed work/school user | Whatever the IT policy allows | Ask for a phishing-resistant option at AAL2+ if not already present | Shadow IT accounts that bypass policy and lose auditability |
Practical reading of the standards: NIST Rev. 4 recognizes syncable authenticators when access to the sync fabric is protected by AAL2-equivalent MFA, while AAL3 still requires a non-exportable private key with phishing resistance. That is why a synced passkey is a normal choice for most people, but a hardware key still matters for the accounts that can reset everything else.
Recovery and lockout
What to keep when the phone is gone or the key is missing
| Scenario | What to have | What to do | Failure mode |
|---|---|---|---|
| Lost phone | Second device, backup security key, or synced credential manager | Sign in from the alternate path, revoke the lost device, then re-enroll the new phone | If the phone was the only passkey, you are now in account recovery |
| Lost hardware key | Spare key in a different location and offline recovery codes | Use the spare, remove the missing key, and update your inventory | If the missing key was the only key, the service now owns your schedule |
| New laptop or browser | Platform sync or an additional authenticator | Sign in, verify the device, and confirm the passkey is present before deleting the old browser profile | Windows Hello-only storage does not roam if the device is reinstalled |
| Family / shared admin | Shared group, known owner, and documented successor | Make sure one trusted person can restore access if the owner is unavailable | No documented owner means the account becomes a legal and social problem, not a technical one |
| Work or school account | IT-approved recovery flow and policy-aware device | Follow the organization path and keep your personal backup separate | Consumer recovery tricks often fail in managed environments |
| Travel / theft / disaster | Off-site backup key or recovery codes | Assume you have only what is in your pocket, then verify what still works | Backups in the same bag are not backups |
Common mistakes
The failures that make passkeys look worse than they are
- One key only: a single hardware key is an outage waiting to happen. Keep a backup key or another enrolled device in a separate place.
- Primary and backup together: a spare key on the same ring, in the same wallet, or in the same laptop bag is not a spare.
- Deleting the password too early: remove the fallback only after you have logged in from a fresh device and proven the recovery path.
- Leaving SMS in place forever: passkeys are the upgrade. SMS is the thing to retire once the new path is stable.
- Confusing local unlock with identity: Face ID, Touch ID, fingerprint, or PIN unlocks the authenticator locally; it is not a free-floating server identity.
- Treating push and OTP as the same as phishing-resistant auth: they are not. They may reduce friction, but a fake site can still trick the user.
- Ignoring org policy: work or school accounts can restrict what you can save, where you can save it, and how you recover it.
- Not testing recovery: a recovery plan that has never been used is a rumor, not a plan.
Related
Pages that sit next to this one
Primary sources