Passkeys vs Authenticator Apps: Which Login Method Is More Secure?

Passkeys are more phishing-resistant than authenticator apps, according to NIST's digital identity guidelines and the FIDO Alliance, because they use public-key cryptography that's cryptographically bound to the exact site you're signing into, while one-time codes from an app like Google Authenticator or Microsoft Authenticator can still be typed into a fake login page by mistake. For most people, passkeys are also faster day to day since they skip typing a code entirely — you just unlock your device. Authenticator apps remain useful as a backup and for the many services that don't yet support passkeys.

What is a passkey?

A passkey is a credential built on the FIDO Alliance's WebAuthn standard that replaces a username and password entirely. Instead of a shared secret that both you and a server have to protect, a passkey is a public/private key pair: your device holds the private key and never sends it anywhere, while the website only ever stores the public key. You "sign in" by unlocking your device with a fingerprint, face scan, or PIN, which proves you have the private key without ever transmitting it. Apple, Google, and Microsoft all describe this the same way in their own documentation — see Apple's passkey security overview and Google's passkey help page.

Passkeys come in two flavors. Synced passkeys live in a credential manager — iCloud Keychain, Google Password Manager, or a third-party password manager — and are end-to-end encrypted across all of your signed-in devices. Device-bound passkeys, usually stored on a physical security key, never leave that one piece of hardware, which Apple and the FIDO Alliance both describe as the highest-assurance option, at the cost of needing to carry the key with you.

What is an authenticator app?

An authenticator app like Google Authenticator or Microsoft Authenticator generates a Time-based One-Time Password (TOTP): a six-digit code that changes roughly every 30 seconds, derived from a secret key that was shared with the app once, usually by scanning a QR code during setup. You type that code into the website alongside your password as a second factor, proving you still have the device that was originally enrolled. Microsoft's documentation describes a second mode on top of that: passwordless push approval, where you tap "Approve" on a phone notification instead of typing anything, which Microsoft positions as a step toward passwordless sign-in without requiring a full passkey migration.

Google's Authenticator documentation notes the app can generate codes without any internet or mobile connection at all, which makes it useful in places where a push notification or a cross-device Bluetooth handshake for a passkey might not reliably arrive.

Phishing resistance: the biggest practical difference

This is where the two methods genuinely diverge, and it isn't marketing spin — it's codified in the U.S. government's own standard. NIST's SP 800-63-4 digital identity guidelines state plainly that "OTP authentication is not phishing-resistant," and that manually entered codes "SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output" to the specific site and session you're actually on. In practice, that means if you're tricked onto a convincing fake login page, you can still type your authenticator-app code into it, and an attacker relaying that code to the real site in real time can get into your account — the code itself doesn't know or care which site it was typed into.

A passkey can't be phished the same way. Because the cryptographic challenge-response happens automatically and is bound to the real site's exact domain, a lookalike phishing page simply can't complete the handshake — there's no six-digit string for an attacker to capture and relay, because nothing is ever manually typed or transmitted in a form a copycat site could reuse. NIST reserves its top assurance tier (AAL3) for authenticators that meet this binding requirement, and OTP-based methods are explicitly excluded from qualifying for it, no matter how the OTP is delivered. The FIDO Alliance puts it more simply in its own consumer-facing material: passkeys are "phishing resistant and secure by design."

This doesn't mean authenticator apps are weak — they're still dramatically better than SMS codes, which can be intercepted through SIM-swapping attacks, and far better than no second factor at all. It simply means they sit at a different, lower rung on the same ladder: good protection against automated credential-stuffing and basic password reuse, but not against a targeted, well-crafted phishing page.

Setting each one up

Creating a passkey usually takes under a minute once you're in a site's security settings: choose "create a passkey," unlock your device, and you're done — there's no secret to copy down. Google's own setup guidance even warns that a freshly created passkey can take up to seven days before some accounts will accept it as a sign-in option, so it's worth setting one up well before you expect to need it, not in a hurry while locked out of something.

Setting up an authenticator app is a little more involved: you open the app, scan a QR code shown by the website, and the two are then linked by a shared secret baked in at that moment. Google's guidance for its own Authenticator app flags the same multi-day delay — up to seven days before the method is fully trusted for sign-in — and specifically notes that having a passkey or security key already active on the account can speed that waiting period up.

What happens if you lose your phone

With a synced passkey, recovery is designed to be painless. Apple's documentation says passkeys are escrowed in iCloud Keychain and can be recovered using your Apple Account password, your device passcode, and a verification code sent to a trusted phone number — even if every device you own is lost at once, with a limited number of recovery attempts allowed before the escrow record locks for safety. Google's help pages describe the rough equivalent for its own Password Manager: sign in to your Google Account on any other device, and synced passkeys are simply there, available immediately.

Losing a phone with an authenticator app is riskier if you never turned on account sync inside the app. Google's own guidance for Google Authenticator says that without signing into a Google Account inside the app, your codes live only on that one device — if it's lost or wiped, you have to visit every single site you'd enrolled individually and go through each one's separate account-recovery process. Signing into the app with a Google Account does fix this, since codes then restore automatically on a replacement device, but it's an easy step to skip during the original setup, and most people never go back to turn it on afterward.

Where hardware security keys fit in

A physical security key is a third option that sits alongside both of the above, and it's the one NIST singles out for its highest assurance tier. A device-bound passkey stored on a hardware key never syncs anywhere and can't be extracted even if your phone or laptop is compromised, which both the FIDO Alliance and Apple point to as the strongest single option available today. The tradeoff is practical, not technical: you have to physically carry it, and if you lose it without a second key or a synced backup, recovery depends entirely on whatever fallback the individual site offers.

Common mix-ups worth clearing up

People often lump "two-factor authentication" together as one thing, but passkeys and authenticator-app codes aren't interchangeable the way they're sometimes treated in casual conversation. A passkey is designed to be your entire sign-in — it can stand in for both the password and the second factor at once. An authenticator app's TOTP code, by contrast, is almost always a second factor layered on top of a password you still have to remember and type. That's why Google's own account settings show passkeys and 2-Step Verification as related but separate sections, and why turning on a passkey doesn't automatically remove your existing password or your authenticator-app enrollment — Google's documentation is explicit that adding a passkey leaves your other sign-in and recovery methods untouched unless you remove them yourself.

Another common mix-up is treating "authenticator app" and "push notification approval" as the same security level. A basic TOTP code and a tap-to-approve push prompt both come from the same app on the same phone, but NIST's phishing-resistance analysis applies to both the same way: neither one cryptographically binds the approval to the exact site and session the way a passkey's challenge-response does, so an attacker who can get you to approve a push at the wrong moment can still get in. Treat push approval as more convenient than typing a code, not as more secure against targeted phishing.

Which should you actually use?

Use a passkey everywhere one is offered. Major platforms including Google, Apple, and Microsoft accounts, plus a fast-growing list of banks, password managers, and online stores, support them now, and the sign-in experience is simpler for everyday use than typing a code ever was. For anything that doesn't yet offer a passkey, an authenticator app is still far better than SMS codes, and it's worth keeping one installed as your universal fallback regardless of how many accounts have already moved to passkeys. If you want the strongest setup NIST describes for its highest assurance level, pair a passkey with a hardware security key as a backup, rather than leaning on OTP codes alone for your most sensitive accounts.

If you haven't set one up yet, our step-by-step guide to setting up passkeys on iPhone, Android, and Windows walks through the process on each platform, and our passkeys vs. passwords breakdown covers the broader case for dropping passwords entirely, not just the second-factor comparison covered here.

What's next

Passkey support is expanding every month as more sites adopt the FIDO Alliance's WebAuthn standard, and NIST's newest guidelines make phishing-resistant authentication the baseline for high-assurance accounts rather than a nice-to-have add-on. The practical move right now is to turn on a passkey wherever your most important accounts — email, banking, your password manager — already offer one, and keep an authenticator app active as the fallback for everything that hasn't caught up yet. For a deeper primer on how the underlying technology works, see our explainer on how passkeys work.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage