Security Key vs Authenticator App: What NIST Actually Says About Phishing

Most comparisons of these two options come down to convenience against security, with a vague claim that keys are "more secure". There is a more precise answer, and it is written down in a standard.

The sentence that settles the phishing question

NIST SP 800-63B, section 5.2.5, is direct about it. Authenticators that involve the manual entry of an authenticator output, such as out-of-band and OTP authenticators, shall not be considered verifier impersonation-resistant, because the manual entry does not bind the authenticator output to the specific session being authenticated.

The same section explains the attack rather than leaving it implicit: in a machine-in-the-middle attack, an impostor verifier could replay the OTP authenticator output to the real verifier and successfully authenticate.

That is the whole mechanism. Your six-digit code is correct. It is simply correct everywhere, including on a page that only looks like your bank.

Why binding is the actual difference

The standard defines verifier impersonation resistance as establishing an authenticated protected channel with the verifier, then strongly and irreversibly binding a channel identifier to the authenticator output, for example by signing the two values together with a private key.

Read that against what each method physically does.

An authenticator app generates a number from a shared secret and a clock. It never learns which site you are on. You are the transport layer, and you can be misdirected.

A security key signs a challenge together with the identity of the session. The FIDO Alliance describes passkeys as using standard public key cryptography techniques to provide phishing-resistant authentication. There is no number for you to read out, and therefore nothing for an attacker to relay.

What the attack looks like from your side

The abstraction hides how ordinary this is, so it is worth walking through.

You receive a message about your account. The link goes to a page that renders correctly, because the attacker's server is fetching the real page and passing it through. You enter your password. The attacker's server submits it to the real site immediately. The real site asks for a second factor, so the fake page asks you for it too.

You open your app and read out six digits. The attacker's server enters them on the real site within the same thirty-second window. The real site sees a valid password and a valid code, and issues a session. The attacker now holds that session.

Notice what never happened. Nothing was cracked, no secret was stolen from your phone, and your app behaved exactly as designed. The code was genuine. It was simply used somewhere you did not intend, and neither you nor the app had any way to notice, because the code carries no information about its destination.

Repeat the same sequence with a security key and it stops at the second factor. The key does not produce a number for you to relay. It signs a response tied to the site actually asking, so the attacker's server receives something that only works on its own domain, which is worthless to it.

Where a key does not help either

Being precise about the limits matters as much as the strengths, because a key is not a general-purpose shield.

It does not protect a session already issued. If malware on your machine steals a session cookie after you have logged in legitimately, the login step is behind you and the key is no longer involved.

It does not protect the recovery path. An account that can be reset by email or by a support agent is only as strong as that path. This is precisely why the email account is the first one to protect, and why account recovery questions remain a soft target.

It does not protect what a compromised device sees. If the endpoint is fully compromised, the attacker is inside the authenticated session with you.

It does not cover services that do not support it. This is the practical limit for most people, and the reason a key is an addition to an authenticator app rather than a replacement for it.

The nuance most comparisons drop

Here is where a lot of security writing overshoots, so it is worth stating plainly.

Verifier impersonation resistance is required only at AAL3 in NIST's framework. At AAL1 and AAL2 it is not mandated. A TOTP app is therefore a conforming second factor for a very large share of ordinary accounts, and it remains a major improvement over SMS codes or over no second factor at all.

So the honest framing is not "apps are broken". It is that apps have one specific weakness, real-time phishing, and that this weakness is structural rather than a flaw in any particular app. No update to your authenticator app will fix it, because the gap is in the manual entry step itself.

Choosing without overthinking it

The decision follows from what an attacker gets if a given account falls.

Use a security key where a compromise is unrecoverable. Your email account first, because it is the password reset path for everything else. Then your password manager. Then anything financial that supports keys.

Keep the app for breadth. Most services still do not support security keys. An authenticator app on those accounts is far better than nothing, and it costs nothing.

Do not run a single key with no fallback. Register a second one, or keep recovery codes printed and stored offline. Losing your only key is a self-inflicted lockout, and it is a more common failure than being phished.

If you are deciding which key to buy, we compare the current models in our hardware security key comparison.

Side by side

The last two rows are the ones people underestimate. The dominant real-world risk with an app is being tricked into using it correctly at the wrong moment. The dominant real-world risk with a key is losing it after registering only one.

The short version

The phishing question is not a matter of opinion. NIST states that OTP authenticators cannot be considered verifier-impersonation-resistant, and explains why: manual entry does not bind the code to the session. A security key signs the session itself, so there is nothing to relay.

But the requirement applies at AAL3, not everywhere. An authenticator app remains a legitimate second factor for most accounts. Put keys where a loss would be unrecoverable, keep the app for the long tail, and make sure you have a way back in.

The definitions and requirements described here are taken from NIST Special Publication 800-63B, and the characterisation of passkeys from the FIDO Alliance's own material, both checked at the time of writing. Standards are revised; verify against the current text before relying on a specific clause. Commercial links carry the rel="sponsored nofollow" attribute; an affiliate commission may apply at no extra cost to you.