Tobias Reithmeier

Blog

Passkeys Instead of Passwords: State of Play and Pitfalls

Schematic comparison: password login with phishing risk and reused passwords versus passkey login with a key pair that verifies the domain
Own schematic illustration: with a passkey, the secret never leaves the device

The password is dying. It is taking longer than the yearly announcements promise, but by now you can see it happen. Since May 2025, Microsoft has been creating new accounts without a password by default, Apple and Google have integrated passkeys deep into their systems, and major services from Amazon to PayPal support passwordless login. So what can passkeys really do, and where are the pitfalls when you switch?

Why passkeys are genuinely better

A passkey is a cryptographic key pair: the private key stays on your device (or in your password manager), the service only knows the public one. At login, your device proves possession of the private key with a signature, which you release via Face ID, Touch ID or the device PIN. That has three tangible advantages:

  • Nothing to steal: the server stores no secret that could leak in a data breach
  • Nothing to phish: the passkey is bound to the domain. A deceptively real fake login page simply never receives a valid signature, so the attack class I described in the post on Telegram fraud bots and 2FA runs into a wall
  • Faster: Microsoft measures passkey logins as eight times faster than password plus MFA

Pitfall 1: the recovery question

The most uncomfortable question comes before the first passkey: what happens if all devices are gone? Synced passkeys hang off your cloud account (iCloud Keychain, Google Password Manager, 1Password and co.), which makes that account the master key. Lose it or get locked out, and in the worst case you lose everything at once. The answer is redundancy: register a second passkey on an independent device or hardware key for important services, and set up the cloud account's recovery paths (recovery key, recovery contacts) before the emergency.

Pitfall 2: moving between ecosystems

Passkeys started life as island solutions. If you collected them in iCloud Keychain, the only way to get them to Google was to re-enroll at every single service. The FIDO Alliance is working on the fix. The Credential Exchange Format (CXF) was approved as a Proposed Standard in August 2025, with the accompanying transfer protocol CXP following. In practice, though, the two sides are not level: Apple shipped export and import with iOS/macOS 26, while Google has pledged support but still offers no export path in its password manager. If you have the choice today, a platform-neutral password manager as your passkey store minimizes the lock-in risk.

Pitfall 3: the password stays on as a backdoor

The transition has a weak point that is easy to overlook. At most services, the passkey supplements the password instead of replacing it. As long as the old password lives on as a fallback, the account remains exactly as phishable as before, because the attacker simply clicks "sign in with password". The switch only becomes consistent once you remove the password at the service (where possible, e.g. at Microsoft) or set it to a long random monster from your password manager and keep 2FA enabled. A passkey in addition is convenience; it only becomes security once the weakest login path is hardened.

The pragmatic migration plan

  1. Start with the crown jewels: your email account (the master key to everything), Apple/Google/Microsoft account, banking, the password manager itself
  2. Set up two paths per important service: a synced passkey plus a second device or hardware key
  3. Test recovery before you need it: walk through once how you'd get back in without your main device
  4. Harden password fallbacks: wherever the password has to stay, use a random password plus 2FA
  5. Stay with your everyday device: passkeys shine where biometrics are available anyway, and the rest follows with time

Conclusion

Passkeys solve the internet's biggest security problem, stolen and phished passwords, in a way that is technically elegant and fit for daily use. The pitfalls of 2026 are not design flaws but transition problems: recovery wants planning, portability is only half finished, and the password fallback remains the open flank. Switch with a plan (most important accounts first, redundancy built in, fallbacks hardened), and you get logins today that are faster and safer. The password won't go out with a bang. It will go account by account.

Sources