Passkeys vs. Hardware Security Keys vs. Authenticator Apps: What I Actually Use and Why

I get a version of this question constantly after publishing the password manager comparison: fine, the password manager is sorted, but what about the second factor? Passkeys, hardware security keys, and authenticator apps all get recommended interchangeably in most consumer security advice, and they are not interchangeable — they solve overlapping but genuinely different problems, with different failure modes.

Here’s what I actually run across my own accounts, why, and where each option’s real limitations are — not the marketing description, the actual gaps I’ve hit using all three for years.

Want the home lab build order too? Subscribe and get the Home Cybersecurity Lab Starter Checklist free — plus one new deep-dive article a week, no daily spam.

What Each One Actually Is

Authenticator apps (TOTP) generate a time-based one-time code from a shared secret established when you set up 2FA. This is the oldest and most widely supported method — Google Authenticator, Authy, or your password manager’s built-in TOTP generator all work the same way underneath. The code is generated locally, doesn’t require network access, and is supported by nearly every service that offers 2FA at all.

Hardware security keys (FIDO2/U2F — YubiKey, Google Titan, and similar) use public-key cryptography instead of a shared secret. The private key never leaves the physical device. Authentication happens by touching the key when prompted, and critically, the cryptographic challenge-response is bound to the specific site’s domain — this is what makes hardware keys phishing-resistant in a way TOTP codes fundamentally are not.

Passkeys are FIDO2’s public-key model without a dedicated physical device — the private key lives in your device’s secure enclave (or syncs across devices via your platform’s cloud keychain — iCloud Keychain, Google Password Manager) and authentication happens via biometric or device PIN. Same phishing-resistance property as hardware keys, different key-storage model.

The Phishing-Resistance Distinction That Actually Matters

This is the single most important technical fact in this entire comparison, and it’s the one most consumer advice glosses over: TOTP codes can be phished. A sufficiently convincing fake login page can prompt you for your TOTP code the same way it prompts for your password, relay it to the real site in real time, and complete the login before the code expires. This isn’t theoretical — real-time phishing kits doing exactly this are a documented, active attack pattern.

FIDO2-based authentication (both hardware keys and passkeys) is structurally resistant to this specific attack, because the cryptographic challenge is bound to the actual domain requesting it. A phishing site presenting a fake login form simply cannot complete a FIDO2 challenge-response on your behalf, because the domain binding fails — the key checks which site is actually asking, not just what the page looks like.

This is why, if you’re protecting anything genuinely high-value (your primary email, your password manager’s own account, financial accounts), TOTP is the weakest of the three options despite being the most universally supported. It’s better than no second factor. It is not equivalent to a passkey or hardware key against a targeted phishing attempt.

What I Actually Use, By Account Tier

Highest-value accounts (primary email, password manager master account, domain registrar): A hardware security key, specifically a YubiKey, as the primary method with a second backup key stored separately. I use a physical key rather than a synced passkey for this tier specifically because I want the private key to exist in exactly one place I control, not synced across a cloud keychain I don’t fully control the security boundary of.

Daily-driver accounts (most services I log into regularly): Passkeys where supported. The convenience difference over a hardware key is real — no fumbling for a physical device, works across my devices via platform sync — and the phishing-resistance property is identical to the hardware key for this threat model. The accounts in this tier don’t carry the same catastrophic-failure risk as the highest tier, so the cloud-sync tradeoff is acceptable here in a way it isn’t for email and the password manager itself.

Legacy accounts and services without FIDO2 support: TOTP through my password manager’s built-in generator, which is a meaningful step down from either FIDO2 option but still substantially better than SMS-based 2FA, which has its own well-documented SIM-swap attack surface.

The Real Limitations of Each

Hardware keys: the loss problem. If you lose your only key and haven’t set up a backup method, you can be locked out of accounts in genuinely painful ways. This is not a hypothetical — I know several people who’ve gone through account recovery hell after losing their sole YubiKey. The fix is straightforward (buy two, register both, store them separately) but it’s an extra $50-70 and a setup step most people skip.

Passkeys: the platform lock-in problem. Passkey sync is tied to your platform ecosystem — Apple’s iCloud Keychain, Google’s Password Manager, or a third-party password manager that supports passkey storage. Moving between ecosystems, or wanting a passkey accessible from a device outside your primary ecosystem, is more friction than it should be as of 2026. This is improving as cross-platform passkey standards mature, but it’s not fully solved yet.

Passkeys: the recovery-account risk. Because passkeys often sync via a cloud account, the security of your passkeys is partly bounded by the security of that cloud account itself. If your Apple ID or Google account is compromised, the blast radius potentially includes your synced passkeys — which is exactly why I don’t use synced passkeys for the highest-value tier above.

TOTP: the shared-secret problem. The seed used to generate your codes is a shared secret stored on the service’s servers. A server-side breach that exposes TOTP seeds compromises the second factor for every account using that seed, in a way that isn’t possible with FIDO2’s public-key model — the service only ever stores your public key, which is useless to an attacker without the private key that never left your device.

What Actually Changed My Setup

I ran TOTP-everywhere for years longer than I should have, on the reasoning that “it’s still 2FA, it’s still better than nothing.” What actually moved me to hardware keys for the top tier was reading through a real-time phishing kit’s source code during a work incident review and watching, mechanically, how trivially it defeated TOTP for a compromised account — the code showed the phishing page just relaying whatever the victim typed, including the TOTP code, straight to the real login in real time. That’s the moment “TOTP is basically as good as a hardware key” stopped being a belief I could hold with a straight face.

The two-key backup approach came from nearly getting burned, not actually getting burned. I traveled with a single YubiKey, left it in a hotel room safe I then couldn’t access before checkout, and spent an uncomfortable few hours doing account recovery on accounts I needed for work that day. I bought a second key and registered it as a backup within the week. I’d tell anyone setting this up now to do that step first, not after a scare.

What I’d Tell Someone Starting From Zero

Don’t try to convert every account at once — it’s a genuine time investment and most services make it more tedious than it should be. Start with your primary email and your password manager’s own account specifically, since those two are the accounts that, if compromised, cascade into everything else. Hardware key for those two, with a registered backup key. Passkeys for everything else that supports them. TOTP as the fallback for services that don’t support FIDO2 yet, which is a shrinking but still real category.

Hardware: Search for a YubiKey 5 series on Amazon — buy two and register both as a backup pair, not one.

Sources:

  1. FIDO Alliance, FIDO2/WebAuthn technical specifications — https://fidoalliance.org/
  2. CISA guidance on phishing-resistant MFA — https://www.cisa.gov/
  3. NIST Special Publication 800-63B, digital identity guidelines
Scroll to Top