Passkeys: The Login That Can't Be Phished

The password is the longest-running unfixed bug in computing. It was a stopgap in the 1960s, a problem in the 1990s, and a liability by the 2010s, and every "fix" since (complexity rules, expiry policies, password managers, SMS codes, TOTP, push prompts) has been a layer on top of a primitive that was wrong to begin with. Each layer added friction and a new failure mode. None of them removed the original one.

Passkeys are the first credible deprecation path. They are not "passwords plus a fingerprint" or "TOTP without the retyping". They are public-key credentials that the server never sees the secret half of, that are bound to the origin the browser tells them about, that require a user-presence gesture, and that, when implemented correctly, let you log in with a tap and nothing else. No password field at all.

This guide explains what a passkey actually is (because the marketing has muddied the water), shows you the deliberate choice between synced passkeys and hardware-bound ones, gets you enrolled on the accounts where it matters most, and is honest about where the ecosystem is still rough.

A passkey is a WebAuthn credential dressed for the consumer market. Same cryptography. Different storage. Pick storage deliberately.

By the end of this guide you will have: an accurate mental model for what a passkey is and what it isn't, a chosen sync substrate (iCloud / Google / 1Password / Bitwarden), passkeys created on your top-priority accounts, hardware keys registered as device-bound recovery passkeys on the accounts that everything else hangs off, and a recovery story you actually trust.

Strip the marketing: a passkey is a WebAuthn credential. The same primitive that powers a YubiKey login, an asymmetric keypair where the private half lives in a secure element and the public half is registered with the website. The only thing that distinguishes "passkey" from the broader WebAuthn family is where that private half is stored, and whether it syncs.

Four properties, each of which fixes a specific class of attack that has worked against passwords for thirty years:

• Origin-bound. The browser tells the authenticator the real domain. The signature is over that domain. A phishing site at paypa1.com gets a signature for paypa1.com, which PayPal will reject. The user cannot make a mistake here, the browser enforces it.
• Public-key, not shared secret. The server stores only the public key. A database breach leaks nothing usable for impersonation. Compare to a password hash, where every breach since 2010 has been a slow-motion credential-stuffing fuel dump.
• User-presence required. Every authentication requires a deliberate gesture, Face ID, Touch ID, fingerprint, PIN, or a hardware tap. Malware running silently cannot mint sessions on its own.
• No transmitted secret. Nothing on the wire that can be replayed, retyped, or intercepted. The signature is over a server-issued challenge that is single-use.

Both kinds of passkey are real. They protect against different things, and the honest answer is to use both, by account category.

Don't sprawl. Pick one sync provider for everyday passkeys and use it consistently. Three honest options in 2026:

GitHub has one of the cleanest passkey flows of any major site. It's a good first enrolment because the prompts are clear, the error messages are useful, and you can test cross-device hybrid login after.

1. STEP 01

   Sign into GitHub on your laptop.

   Go to Settings → Password and authentication → Passkeys → Add a passkey. The browser will show its native passkey prompt, on Mac that's a sheet from the top of Safari/Chrome offering iCloud Keychain; on Windows it's the Windows Hello dialog; in 1Password it's the 1Password browser-extension prompt.

2. STEP 02

   Pick where to save it.

   The OS dialog will list every passkey provider it knows about. Pick your chosen substrate from §04. Authenticate with biometrics or PIN. The passkey is created and synced.

3. STEP 03

   Confirm it synced.

   On your phone, open the password manager / Keychain / Google Password Manager and look for a github.com entry with a passkey icon. It should be there within seconds (iCloud sometimes takes a minute).

4. STEP 04

   Test cross-device sign-in via hybrid.

   Open a private/incognito browser on a different machine and start the GitHub login. Click "use a passkey on another device". A QR code appears. Scan it with your phone, the phone prompts for biometric, and the laptop logs in. No passkey ever leaves the phone; the laptop session is authenticated by proxy over a BLE-confirmed channel.

Passkey support is uneven. Some sites treat passkeys as a primary login factor (the right way); some bolt them on as "additional 2FA" while still requiring a password (mostly theatre). Migrate the first kind first.

Cross-device authentication via QR code is the feature that makes passkeys work in the real world, on a friend's laptop, on a public kiosk, on a fresh OS install. It's defined by the FIDO CTAP 2.2 spec and works the same on every modern OS.

Laptop (no passkey present):
  1. Click "use passkey on another device".
  2. Browser shows a QR code containing a one-time key + BLE handle.

Phone (where the passkey lives):
  3. Camera scans QR. Phone offers to authenticate with the
     matching passkey.
  4. Phone broadcasts a BLE advertisement; laptop sees it.
     This proximity check defeats remote QR phishing, the
     phone and laptop must physically be near each other.
  5. Phone prompts for biometric.

Laptop:
  6. Authenticator on the phone signs the server's challenge,
     tunnels the signature back to the laptop over the BLE-
     established channel.
  7. Browser submits the signature. Server accepts. Logged in.

The passkey itself NEVER leaves the phone.

Synced passkeys move trust to the sync provider. The defence is to register a YubiKey as an additional device-bound passkey on the small set of accounts that everything else depends on.

1. STEP 01

   On Google, GitHub, your password manager, and your primary email, add a YubiKey as an additional passkey.

   Same flow as adding the first passkey, but choose the security key option instead of the platform one. The site will ask the YubiKey to generate a credential. Tap to confirm. Now you have two passkeys on each account: synced for daily use, hardware-bound for recovery.

2. STEP 02

   Add a backup YubiKey too.

   Same rule as the YubiKeys guide: never have only one hardware key. The backup lives in a fireproof safe or a trusted second location. Register it on the same recovery-anchor accounts.

3. STEP 03

   Harden the sync provider itself.

   Your iCloud / Google / Microsoft / 1Password / Bitwarden account should also have hardware-key 2FA enabled. The account that holds your synced passkeys is now the highest-value account you own.

The ecosystem is good enough to commit to. It is not yet good enough to pretend the rough edges aren't there.

• Cross-ecosystem migration is painful. Moving from iCloud Keychain to Google Password Manager to 1Password is not a one-click export. Pick a sync substrate you intend to stay with.
• Recovery flows still fall back to email and SMS. Passkeys protect login. They do not protect account recovery, most sites still let you reset via email, and many still allow SMS as a backup. Harden the recovery vector or the front door doesn't matter.
• Many "passkey support" implementations are 2FA, not primary. On those sites the password remains the real credential and the passkey is a second factor. Check whether you can disable the password after enrolling.
• Shared accounts are awkward. Family streaming logins, shared work accounts, passkeys are per-person by design. Most sync providers don't share them across vaults cleanly. Some workflows still want a password.
• Enterprise SSO support is uneven. Okta and Microsoft Entra are mature. Many smaller SAML providers still don't accept passkeys as a first-class factor. Your employer may force you back into username + push for now.

• FOUNDATION

  YubiKeys & Hardware 2FA →

  The device-bound half of the passkey story.

• EXPOSURE MAP

  Self-OSINT →

  Find the accounts an attacker would target before you migrate them.