Every few weeks another service prompts you to "create a passkey." Meanwhile your authenticator app still holds six-digit codes for dozens of accounts. So which is it: are passkeys replacing 2FA, or do you need both?
Short answer: passkeys are the better login wherever they are offered, and TOTP codes will still be part of your security for years. This is not a versus so much as a division of labor. Here is what each technology actually does, where each one wins, and a practical setup that works today.
What a passkey actually is
A passkey is a cryptographic credential built on public-key cryptography, standardized as WebAuthn/FIDO2. When you create one, your device generates a key pair: the public key goes to the service, the private key stays on your device, protected by Face ID, a fingerprint, or your device PIN. At login, the service sends a challenge and your device signs it. The private key never leaves your hardware, and there is nothing for you to type.
Three properties make passkeys genuinely better than what came before:
- Phishing resistance. A passkey is cryptographically bound to the real domain. A convincing fake site simply cannot trigger it, because the domain does not match.
- Nothing useful to steal in a breach. The server stores only your public key, which cannot be used to log in.
- Platform sync. iCloud Keychain and Google Password Manager sync passkeys across your devices with end-to-end encryption, so losing your phone does not mean losing the credential, at least within one ecosystem.
What TOTP 2FA actually is
Time-based one-time passwords are the codes your authenticator app shows. At setup, you scan a QR code that gives your app a shared secret. Every 30 seconds, the app combines that secret with the current time to produce a six-digit code; the server runs the same math and compares. It works completely offline, it is an open standard, and it runs on any platform in any compatible app (see our full comparison of the best ones).
Its weaknesses, honestly stated: TOTP relies on a shared secret, so the server holds a copy that could leak in a breach. And codes can be phished. A well-made fake login page can ask for your code and relay it to the real site in real time. TOTP raises the bar enormously over a password alone, but it is not phishing-proof.
Passkey vs 2FA, head to head
| Passkey | TOTP 2FA | |
|---|---|---|
| What it replaces | Your password and second factor, in one step | Nothing; it adds a second step to a password |
| Phishing resistance | Strong; bound to the real domain | Partial; codes can be relayed by a fake site |
| Works offline | Yes, signing happens on-device | Yes, codes generate on-device |
| Portability | Synced within an ecosystem; moving between ecosystems is improving but uneven | Fully portable; any app, any platform |
| Service support | Growing fast, still patchy | Near-universal among services that offer 2FA |
| Breach exposure | Server stores only a public key | Server stores the shared secret |
Passkeys win on security. TOTP wins on ubiquity and portability. That is the entire debate in two sentences.
The hybrid reality nobody talks about
Passkey adoption is real but incomplete. The big platforms support them; the long tail of services you actually use, from your utility company to that forum from 2014, mostly does not. And here is the part that matters most: even services that offer passkeys usually keep your password and existing 2FA active in parallel as fallbacks. Your account is only as strong as the weakest login method still enabled on it. Adding a passkey does not let you stop caring about the rest.
The worst fallback to leave active is SMS. Text-message codes are vulnerable to SIM swapping, where an attacker takes over your phone number and receives your codes. If a service lets you remove SMS once a passkey or authenticator app is set up, do it; our guide to defending against SIM swap attacks explains why this matters so much.
TOTP, meanwhile, is your portable escape hatch. It does not care whether you are on an iPhone, an Android phone, or a borrowed laptop. When you switch ecosystems or a passkey sync goes sideways, the boring six-digit code still works.
A practical setup that works today
- Turn on passkeys wherever they are offered. Start with your email account, since it can reset almost everything else.
- Audit the fallbacks. After adding a passkey, check which other sign-in methods remain active. Remove SMS where the service allows it. Never leave SMS as your only second factor anywhere.
- Keep TOTP for everything else, which today is most services. Use an app that survives a lost phone: Authenticator by Vidus6, for example, syncs your codes across iPhone, iPad, Mac, and Android with end-to-end encryption, and a new device only joins after an existing trusted device approves it. It also has setup guides for over 2,000 services if you are enabling 2FA account by account.
- Save your recovery codes. They are the fallback for both worlds when a device dies. Our guide to managing 2FA recovery codes covers where to keep them.
- Do not delete authenticator entries just because you added a passkey. First check whether the code is still an accepted login method on that account. If it is, it needs to stay safe, or be disabled deliberately in the account's security settings.
Will passkeys make authenticator apps obsolete?
Honestly: over time, mostly yes. As passkey support spreads, the number of accounts that need a TOTP code will shrink, and the role of a separate authenticator app will shrink with it. We build an authenticator app and we will say that plainly.
But the transition is slow. Smaller services, enterprise systems, and self-hosted software adopt new authentication standards over years, not months, and TOTP remains the one second factor that is vendor-neutral and works everywhere. For the foreseeable future, a passkey where possible plus TOTP everywhere else is not a compromise; it is simply the correct setup.
FAQ
Is a passkey the same thing as 2FA?
No. 2FA adds a second step on top of a password. A passkey replaces the password, and usually the second step too, because it combines possession of your device with a biometric check in a single action. Many services treat a passkey sign-in as satisfying multi-factor requirements on its own.
Can passkeys be phished?
Not the way codes can. A passkey refuses to work on a lookalike domain, which removes the classic phishing playbook. Attackers respond by targeting what is left: account recovery flows, SMS fallbacks, and support-desk social engineering. Securing those fallbacks is where your attention should go.
Should I delete my authenticator app once I have passkeys?
No. Most of your accounts still rely on a password plus TOTP, and even passkey-enabled services often keep TOTP active as a fallback that needs protecting. Keep the app, back it up properly (our guide to secure 2FA code backup shows how), and revisit the question in a few years.
Use passkeys where you can. Keep TOTP everywhere else, in an app that will survive a lost phone. Never leave SMS as the only fallback. Get those three things right and you are ahead of the overwhelming majority of internet users, whatever the passwordless timeline turns out to be.
