Passkeys are the first sign-in method in a long time that is both easier and safer than the thing it replaces. You unlock your phone or laptop the way you already do, and you are in. No password to type, no six-digit code to copy, and nothing a phishing site can usefully steal.

So the obvious question for anyone with an authenticator app full of codes: is it on the way out? Partly, over time, for some accounts. Not soon, and not for most of them. Here is why, and how the two fit together in the meantime.

One thing up front, because this is our blog: KeyNesta does not store passkeys today. It is a TOTP and HOTP authenticator. Nothing in the argument below depends on that.

What a passkey actually is

The FIDO Alliance describes a passkey as a sign-in credential based on FIDO standards, stored on your phone, your computer or a hardware security key, that you use with the same gesture that unlocks the device: a fingerprint, your face, or a PIN. Underneath it is the W3C Web Authentication standard, usually called WebAuthn, together with FIDO's protocol for talking to authenticators. The pair is known as FIDO2.

The mechanism is public-key cryptography:

  1. When you create a passkey, your device generates a key pair for that one site. The site keeps the public key. The private key stays with you.
  2. When you sign in, the site sends a challenge. Your device checks that it is really you, locally, then signs the challenge with the private key and sends back the signature.
  3. The site verifies the signature with the public key it stored at registration.

The site never holds a secret it could leak in a breach; a stolen public key cannot sign anyone in. Your fingerprint never leaves your device either. The site only learns that the local check passed.

Why passkeys stop phishing and codes do not

Each passkey is scoped to the site that created it. WebAuthn ties every credential to a relying party identifier, which is in effect the site's domain, and the browser enforces it. If you land on a convincing copy of your bank's login page on a different domain, there is no passkey for that domain, so there is nothing to sign and nothing to steal.

Illustration: a fingerprint key bounces off a lookalike site and fits the real one
A passkey is bound to the real site, so it will not work on a lookalike. A typed code cannot tell the difference.

A six-digit TOTP code has no idea where it is being typed. A phishing page can ask for it and relay it to the real site within the half-minute it is valid. That is why NIST's current guidelines say authenticators that involve manually entering an output, OTP apps included, "SHALL NOT be considered phishing-resistant", while properly configured passkeys are, because each key can only be used with the specific site it was created for (NIST SP 800-63B-4, syncable authenticators). CISA goes further and calls FIDO/WebAuthn "the only widely available phishing-resistant authentication" (CISA fact sheet).

On phishing specifically, passkeys win, and it is not close. If you are still on texted codes, the step before this one is covered in authenticator app vs SMS.

Synced or device-bound

Passkeys come in two kinds. Synced passkeys are copied across your devices by a provider such as iCloud Keychain or Google Password Manager, so a new phone already has them. Device-bound passkeys never leave the device they were created on, which is how a hardware security key works.

The difference shows up at recovery time. Synced passkeys survive a lost phone as long as your provider account survives, which makes that account the thing to protect. NIST allows synced passkeys at its middle assurance level, AAL2, and notes that they cannot meet its highest level, AAL3, because syncing means the key can be exported. Device-bound passkeys are stronger and less forgiving: lose the only key without a spare and you are into account recovery.

Why you still need an authenticator app

Most of your accounts probably do not offer passkeys yet. Support is growing, and the big consumer platforms moved first. But look at the accounts you actually hold: the domain registrar, the hosting panel, the payroll system, the work VPN, the older bank, the game launcher. Many offer TOTP and no passkey. For those, an authenticator app is the strongest option on the table.

A passkey often sits beside your password, not instead of it. Many services add passkeys as one more way in and leave the password working. If the password plus a second factor still signs you in, that path is still open to an attacker, and the second factor guarding it is often a TOTP code. Keep it strong rather than letting it fall back to SMS.

Recovery falls back to something else. When you lose access to your passkeys, the service has to let you in another way: recovery codes, an email link, a second factor you still have, or an identity check. That something else very often includes a TOTP code. An account protected by a passkey but recoverable through SMS is only as strong as the SMS.

Work and admin systems move slowly. Plenty of internal tools, single sign-on setups and infrastructure consoles still enrol TOTP as their second factor. If you run anything, you will be holding codes for years.

How to use both sensibly

  1. Add a passkey wherever it is offered, starting with your email and your most-used accounts. It is the cheapest phishing protection you will ever get.
  2. Keep TOTP switched on where the password still works, so that path is not guarded by SMS alone.
  3. Register more than one passkey where you can, such as a phone and a laptop, or two security keys, so one loss is not a recovery event.
  4. Save every service's recovery codes, and keep them somewhere other than the device that holds your passkeys.
  5. Back up your authenticator. The accounts without passkeys are exactly the ones where a lost phone hurts most. Lost your phone? walks through what happens with and without a backup.

If you keep your codes in a password manager, the trade-offs of that are in a separate post: should your 2FA codes live in your password manager?

Takeaway

Passkeys are better than 2FA codes at the thing codes are worst at, which is phishing. Use them wherever you can. But passkeys are not everywhere yet, many sites keep a password path open beside them, and recovery usually falls back to codes, so an authenticator app stays part of a sound setup for the foreseeable future. The goal is not to pick one. It is to put the strongest available method on each account, and to make sure losing a device does not lock you out of any of them.

Where KeyNesta fits

KeyNesta handles the TOTP and HOTP side of that: the long tail of accounts that offer codes and no passkey. They can be organised into vaults, spaces and groups for when there are hundreds of them, with encrypted backup files and end-to-end encrypted sync so a lost phone is not a lockout. It does not store passkeys; for those, use your platform's passkey manager or a hardware key. The features page lists what is built and what is not, and authenticator for multiple accounts shows how the organisation works at scale. The web app at app.keynesta.com needs no sign-up.