What a passkey actually is
A passkey is a pair of cryptographic keys created by your device for one specific website. The private key never leaves the device or the encrypted vault that syncs it; the website only stores the matching public key. When you sign in, the site sends a challenge, your device signs it after a local check such as a fingerprint or PIN, and the signature proves you hold the key.
Because nothing reusable is transmitted, there is no password to steal from the website's database, no code to read out to a caller and nothing useful for an attacker to capture from the network. This is a structural improvement rather than an incremental one.
Why passkeys defeat phishing
A passkey is bound to the exact domain that created it. If a convincing copy of your bank's site asks you to sign in, your device simply has no key for that domain and will not offer one. The attack fails without you needing to spot anything.
That is the essential difference from one-time codes. Modern phishing kits act as a live relay: they show you the real site, pass your code straight through and steal the resulting session. A passkey cannot be relayed because the signature is tied to the real origin.
Where your passkeys are stored
Passkeys can live in your platform account (Apple, Google or Microsoft), in a password manager such as 1Password, NordPass, Proton Pass, Bitwarden or Dashlane, or on a hardware security key. Password managers are usually the best choice for mixed households, because platform-bound passkeys can be awkward when you own an iPhone and a Windows laptop.
Whichever you choose, the vault protecting the passkeys becomes the most important account you own. Use a long unique master password and a strong second factor on it.
What happens if you lose your device
Synced passkeys are recovered by signing back into your password manager or platform account on a new device, which is why recovery planning matters more than the passkey itself. Device-bound passkeys on a hardware key are not recoverable, so register a second key and store it elsewhere.
Before you delete any password, confirm that you can complete the account's recovery path: a verified email address you control, recovery codes stored offline and, where offered, a second registered passkey.
A safe migration order
Start with the accounts that unlock everything else: your email, your password manager and your platform account. Then move to banking, payment services, cloud storage and social accounts. Keep a strong unique password on each account as a fallback until passkey support is clearly mature on every device you use.
Delete the old password only when you have signed in with the passkey at least once on each device and have recovery codes stored somewhere offline.
- Email and password manager first
- Banking, payments and cloud storage next
- Social and shopping accounts last
- Keep recovery codes printed or in an encrypted file
- Remove SMS as a recovery route wherever a stronger option exists
The current limitations
Support is now broad but not universal. Some sites offer passkeys only as a second factor, some enterprise systems still require passwords, and a few services allow a passkey to be bypassed by a weaker recovery route, which limits the real protection gained.
Shared accounts are also imperfect: passkey sharing works well inside a password manager but poorly across different platform ecosystems. For those accounts, a strong shared password with multifactor authentication remains reasonable for now.
Passkeys, password managers and 2FA together
Passkeys do not make password managers obsolete. They make them more valuable, because the manager becomes the portable, cross-platform home for your credentials and passkeys alike, plus secure notes, recovery codes and payment details.
Keep authenticator-app codes for services without passkey support, and prefer them over SMS, which remains vulnerable to SIM-swap fraud and interception.
How adoption looks on each platform
Apple stores passkeys in the iCloud Keychain and syncs them across devices signed into the same Apple Account, with Face ID or Touch ID as the local check. Google keeps them in Google Password Manager on Android and Chrome, and Microsoft uses Windows Hello alongside the Microsoft account. Each works well inside its own ecosystem and less well across ecosystems.
If your household mixes an iPhone with a Windows laptop, or Android with a Mac, a cross-platform password manager avoids the situation where a passkey exists on one device and cannot be reached from another. Test signing in on every device you regularly use before you rely on the passkey alone.
Passkeys at work and on shared computers
Workplace accounts often add conditional access rules, managed devices and administrator recovery, which changes the calculation. Registering a passkey on a personal phone for a work account is usually fine, but registering one on a shared or public computer is not, because anyone with local access may be able to use it.
For shared machines, sign in with a password and a code and sign out completely afterwards, or use a hardware security key you carry with you and remove when you leave.
Common mistakes to avoid
The three failures we see most often are deleting the password before testing the passkey on a second device, storing recovery codes inside the same account they protect, and leaving a weak SMS recovery route active that an attacker can use to bypass the passkey entirely.
Fix all three at once: test, store the codes separately, and remove weak recovery routes from any account that offers a better option.
