TOTP vs passkeys: which second factor actually belongs on your accounts?

The 60-second answer

Passkeys (or hardware security keys) are the stronger factor — they are cryptographically bound to the real website, so a fake lookalike page simply can’t collect them, and no shared secret sits on the service’s servers. TOTP is the most portable factor — one Base32 secret generates correct codes in any authenticator app, any browser, any device, offline, on shared machines, on hardware your passkeys will never reach. SMS is neither — see our SIM-swap article for why it belongs last.

The honest ranking for security is: hardware key ≥ passkey > TOTP ≫ SMS. The honest ranking for portability inverts it: TOTP > synced passkeys > hardware keys ≫ SMS. Most people need both halves, which is why the right long-term answer is mixing, not replacing (see the setup that beats choosing).

How each factor works

TOTP (RFC 6238) is a shared-secret design. At enrollment the service gives you a random secret once; every 30 seconds both sides independently compute the HMAC of the current time-step under that secret and compare results. No network traffic, no device pairing — just a secret and a clock. The full walkthrough is in our What is 2FA guide.

Passkeys (WebAuthn/FIDO2) are asymmetric. At registration the service receives only your public key; the private half stays on your device (or in your platform’s end-to-end-encrypted passkey sync). At sign-in the site sends a challenge that only the private key can answer — and the browser refuses to release a signature unless the domain matches the one the key was created for. That origin binding is what makes them phishing-resistant by construction.

Hardware keys are passkeys in a physical body (FIDO2 over USB/NFC), with the private key held in a secure element and gate-kept by a physical touch. A synced passkey inherits almost all of the same math; a hardware key adds device independence — it works on borrowed machines where none of your platform accounts are signed in.

What each buys you — and costs you

• Phishing resistance. Passkeys and hardware keys win outright: a phishing domain gets no key, ever. TOTP can be phished — a live code typed into a fake page inside its 30-second window is still one working login. SMS loses hardest: codes are collected wholesale by whatever network path the attacker impersonates.
• Portability. TOTP wins: one Base32 string reproduces identical codes in a phone app, a browser tab, a shared support machine, or an offline laptop. A passkey is deliberately pinned to its platform; a hardware key pins to your pocket.
• Server-side copy. TOTP enrollment leaves a copy of the secret on the service’s servers. Passkeys don’t — the server keeps only a public key. For threat models that include a future breach of the service itself, that asymmetry matters.
• Recovery & lock-in. TOTP’s secret is yours to back up as text — in a password-manager vault — so the factor survives any single device dying. Passkey recovery runs through your platform account (Apple/Google/password-manager) or a backup hardware key; lose both ends of a non-synced setup and the enrollment is gone with it.
• Shared/CI machines. Passkeys on a shared workstation tie sign-ins to that machine’s profile. A TOTP slot in a browser private window comes and goes cleanly — close it, nothing lingers.

When TOTP still wins

• Your phone died, broke, or was sold — you need codes on whatever you have.
• You sign in on consoles, VMs, jump boxes, or CI boxes where passkeys can’t live.
• You browse across multiple machines without a shared platform account.
• You want one factor you can audit end-to-end: the math is public, the secret is a string you can hold in an encrypted vault, and the network traffic is zero.
• A service simply doesn’t support passkeys yet — which is still most of the web’s long tail.

When passkeys (or hardware keys) win

• High-value consumer accounts where phishing modules target users — primary email, banking, crypto, Apple/Google accounts.
• You want a defense that works while asleep and anxious: telling fake sites apart is not your problem anymore.
• Your organization enforces phishing-resistant flows (AWS, GitHub and Google all push this way) — comply where policy asks.
• You carry one hardware key (plus a backup) and want the strongest no-phone-signals factor in the game.

The setup that beats choosing

On the accounts you can, enroll in this order: passkey or hardware key first (the phishing-resistant daily driver), then TOTP as your universal fallback on the services that allow it, then recovery codes printed to your vault. That stack gives you: day-to-day phishing immunity, a portable factor for odd machines and app-less days, and a paper trail of last resort. The Base32 secret from the TOTP enrolment belongs in the same vault — with a local generator like this site it becomes codes on demand anywhere, no app install required.

And keep the SMS line off wherever the service permits a stronger substitute. Where it cannot be avoided entirely, at least know the attack that hits it: SIM swaps, explained plainly.