A hardware security key is a small device, usually on a keyring, that you plug into a USB port or tap against your phone to prove it is you. People who recommend them tend to do so strongly, and the people selling them more strongly still. So it is worth being precise about what a key does that an authenticator app cannot, what it costs you in money and in failure modes, and which of your accounts actually warrant one.
One thing up front, because this is our blog: KeyNesta is an authenticator app. This post is partly about the accounts where a key beats it.
What a security key actually is
A security key is a tiny computer that does one job: public-key cryptography on your behalf. When you register it with a site, it creates a key pair for that site and hands over only the public half. When you sign in, the site sends a challenge, you touch the key to approve, and the key signs the challenge with a private key that never leaves it. That is the same FIDO2 and WebAuthn mechanism as a passkey; a security key is, in effect, a passkey that lives on a device you can hold, which is why the standards call it a device-bound authenticator. The mechanism is explained step by step in passkeys vs authenticator apps.
Keys come in two tiers, and the difference matters for this comparison. A FIDO-only key such as Yubico's Security Key NFC does WebAuthn and nothing else, and lists at $29. A full key such as the YubiKey 5 NFC, listed at $58, also holds other credential types, including the TOTP and HOTP secrets an authenticator app would normally keep. On those keys the secret sits in the key's secure element and the code is calculated by the key, with an optional setting that makes each code wait for a touch (Yubico Authenticator guide). You still need a companion app on the phone or computer to show the code, but the phone never holds the secret.
Where the key wins
Phishing. This is the whole case, and it is a strong one. A six-digit code can be typed into a lookalike site and relayed to the real one inside its 30-second window. A key cannot be fooled that way, because each credential is bound to the site that created it and the browser refuses to use it anywhere else. NIST's current guidelines put it bluntly: authenticators that involve manually entering an output "SHALL NOT be considered phishing-resistant", and that includes every code-based app, ours included (NIST SP 800-63B-4). Cryptographic authenticators such as security keys are the ones that qualify. CISA's guidance for organisations says the same and calls FIDO/WebAuthn the only widely available phishing-resistant method (CISA fact sheet).
Nothing on the phone to steal. If your phone is compromised, an authenticator app's secrets are on it. A key's private keys are not exportable by design, which is why NIST's highest assurance level, AAL3, requires a device-bound authenticator and a synced passkey cannot reach it. A full key extends the same protection to your TOTP secrets, because they live in the key rather than in an app's storage.
It does not depend on anything. No battery, no network, no operating system update, no app store. A key from several years ago still works today. It also has no clock, which quietly removes the most common failure an authenticator app has: a device a minute out of step produces codes every service refuses, and that is the first thing 2FA code not working sends you to check. A key either touches or it does not.
For a small set of accounts, those three properties are worth paying for. Google built its Advanced Protection Program, aimed at "users with high visibility and sensitive information from targeted online attacks", around exactly this: enrolment requires a security key or a passkey, and signing in requires one too.
Where the app wins
Coverage. Most services that offer any second factor offer TOTP. Far fewer accept a security key, and the gap is widest exactly where it hurts: smaller banks, payroll and HR systems, hosting panels, registrars, older forums, the admin side of almost everything. 2fa.directory lists what each service supports; the pattern is that the big consumer platforms accept keys and the long tail does not. For those accounts the app is not the weaker choice. It is the only choice above SMS.
Services treat the key as an add-on. Even where keys are accepted, they are often layered on top of codes rather than replacing them. GitHub, for example, lets you register a security key only after 2FA is already enabled with an authenticator app or SMS, and recommends the app with keys as the backup (GitHub docs). If the code path stays open beside the key, it needs to stay strong, which brings the app back into the picture on the very accounts the key was bought for.
A key cannot be backed up, so you need two. The property that makes a key phishing-resistant, a private key that cannot leave the device, is the same property that means losing the device loses the credential. Yubico's own advice is to buy a spare and register it at the same time as the first, to avoid "a lengthy recovery and identity verification process to regain access to each account" (Yubico). Apple makes the spare mandatory: security keys on an Apple Account require at least two, and the support page warns that if you lose all your trusted devices and keys "you could be locked out of your account permanently" (Apple Support). So the real price of the full-featured route is two keys, around $116 at list, plus the discipline to keep the second one somewhere safe and to register it on every new account.
Capacity. A key holds a fixed number of credentials. On the YubiKey 5 series that is 25 passkeys and 32 TOTP accounts on firmware before 5.7, and 100 and 64 on 5.7 and later (Yubico firmware overview). Generous for a handful of important accounts; a ceiling for someone who has enabled 2FA everywhere and holds a couple of hundred. An app has no such limit.
Recovery is a feature you can design. Because an app's secrets are data, they can be exported, encrypted and restored. That is a weakness against a compromised phone and a strength against a lost one, and for most people the lost phone is the far more likely event. How that plays out with and without a backup is in lost your phone? how to recover your 2FA codes.
The setup that uses both well
The comparison is not app or key. It is which accounts get which, and most people land in the same place.
- Decide whether you have key-worthy accounts. The test is not how much you value the account but whether someone might come for you specifically: your primary email, your password manager, a domain registrar, a cloud or hosting console, an exchange or brokerage, anything that controls money or other logins. If a phished code on that account would be a disaster rather than a nuisance, it earns a key.
- If yes, buy two keys and register both at once, on every account that accepts them, starting with email. Keep the spare off your keyring. If none of your accounts clears that bar, an authenticator app plus unique passwords is a sound setup, and the money is better spent elsewhere.
- Keep the app for everything else, which is most things. Wherever a site offers codes and no key, the app is the strongest option on the table.
- Where a site keeps a code path open beside the key, make it an app code, not a text message. The reasons are in authenticator app vs SMS.
- Save every service's recovery codes somewhere that is neither the phone nor the keyring.
- Back up the app. The accounts that only offer codes are the ones a lost phone hurts most. Encrypted 2FA backup and sync covers how to do that without handing the secrets to anyone.
If you are tempted to put the codes in your password manager instead of a separate app, that trade-off has its own post: should your 2FA codes live in your password manager?
Takeaway
A hardware security key is the strongest second factor you can buy, and the only common one that cannot be phished. It is also a physical object with a fixed capacity, no backup, a price that doubles once you buy the spare you genuinely need, and support from a minority of the services you use. Put keys on the few accounts where a targeted attack is realistic, and keep an authenticator app for the many that only offer codes. Neither replaces the other; they cover different accounts.
Where KeyNesta fits
KeyNesta is the app in that setup. It holds the TOTP and HOTP codes for the long tail of accounts, organised into vaults, spaces and groups 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 or talk to security keys; for the accounts that earn a key, use the key. The features page lists what is built and what is not, authenticator for multiple accounts shows how the organisation works at scale, and TOTP vs HOTP explains the codes themselves. The web app at app.keynesta.com needs no sign-up.