Tag: passkeys

“Turn on two-factor authentication” has been standard security advice for over a decade. “Set up a passkey” is the newer instruction, and it’s starting to replace the old advice rather than sit alongside it. The two aren’t quite the same category of thing: most two-factor authentication (2FA) methods add a second step on top of a password, while a passkey is designed to remove the password entirely. Here’s what each one actually does under the hood, what the FIDO Alliance and NIST say about their relative security, and which one you should set up first — for your own accounts and, if you run a site, for your users.

At a Glance

How Passkeys Actually Work

A passkey is a credential built on FIDO2/WebAuthn, the open authentication standard maintained by the FIDO Alliance. Apple’s own developer documentation describes the mechanism clearly: when you register a passkey with a site, your device generates a unique public/private key pair for that specific account. The public key is sent to the site’s server; Apple explicitly notes this key “isn’t a secret,” so there’s nothing sensitive to steal if the server is breached. The private key never leaves your device. To sign in, the site sends a challenge, your device signs it with the private key after you unlock the device (Face ID, Touch ID, fingerprint, or a screen PIN), and the server verifies the signature against the public key it already has.

That structure is what makes passkeys resistant to phishing by design rather than by user vigilance: a fake look-alike login page has no way to extract a private key that never leaves your device, and a passkey registered for one domain simply will not produce a valid signature for a different, impersonating domain. The FIDO Alliance states this directly — passkeys “use public key cryptography” in a challenge-response protocol and are “always strong and phishing-resistant” compared with passwords, in part because there are no shared secrets stored on the server for an attacker to steal in a database breach. Apple’s documentation separately calls passkeys “highly phishing-resistant” and notes each key pair is generated “securely and uniquely, for every account.” Google describes the same property more plainly in its own help documentation: passkeys offer “stronger protection against threats like phishing,” and unlike a password, a passkey “can’t be shared, copied, written down, or accidentally given to someone else.”

Passkeys can live in different places. Apple devices sync them end-to-end encrypted through iCloud Keychain; Google can register them automatically for Android devices or sync through Google Password Manager; and FIDO2 hardware security keys can hold device-bound passkeys that never sync anywhere. Microsoft Authenticator also supports creating and storing passkeys for Microsoft and third-party accounts. The FIDO Alliance distinguishes between these: device-bound passkeys on a dedicated hardware key offer the highest assurance level, while synced passkeys back themselves up through a password-protected cloud keychain, which the Alliance notes can itself become a target if that account is compromised.

How Two-Factor Authentication Actually Works

Two-factor authentication keeps the password as the first factor and adds a second proof of identity on top of it. The two most common second factors are an SMS/voice one-time code sent to your phone, and a time-based one-time passcode (TOTP) generated by an authenticator app (Google Authenticator, Microsoft Authenticator, Authy, etc.) using the algorithm defined in RFC 6238, which both factors reference.

These two methods are not treated as equally secure, including by the U.S. government’s own digital identity guidelines. NIST Special Publication 800-63B restricts the use of the public switched telephone network (which covers SMS and voice calls) for out-of-band verification, stating specifically that verifiers “SHOULD consider risk indicators” such as a recent SIM change, device swap, or number porting before relying on it — precisely because an attacker who takes over your phone number can intercept the code. TOTP app codes avoid the SIM-swap problem since they’re generated locally on a device rather than delivered over the phone network, but they still rely on you (or an attacker who tricks you) typing the code into whatever page is asking for it. If that page is a real-time phishing proxy sitting between you and the real site, a TOTP code can be captured and relayed within its short validity window just like a password can — the code itself doesn’t know or verify which domain is asking for it. That’s the structural difference from a passkey: a passkey’s cryptographic signature is tied to the requesting domain automatically, while a one-time code is just a string of digits that works wherever it’s typed.

NIST’s framework separately defines Authenticator Assurance Level 3 (AAL3), its highest tier, which requires a hardware-based authenticator and what it calls “verifier impersonation resistance.” A FIDO2 hardware security key is the kind of authenticator built to satisfy that bar; SMS and basic TOTP combinations are not positioned at that level in NIST’s model.

Comparison Table

Which Should You Use?

As an end user: enable a passkey everywhere it’s offered — on Google, Apple, Microsoft, and major financial and shopping accounts that support it — since it removes the password-phishing risk entirely for that login. Where a passkey isn’t offered yet, use a TOTP authenticator app over SMS whenever you have the choice, since it isn’t exposed to SIM-swap attacks. Keep SMS 2FA as a fallback/recovery option rather than your primary second factor if the service allows you to choose.

As a site owner deciding what to support: supporting passkeys via WebAuthn gives your most security-conscious users the strongest available option and, per vendor-reported figures cited by the FIDO Alliance, can reduce sign-in friction (Google has reported roughly a 4x improvement in sign-in success rate with passkeys versus passwords). But don’t drop 2FA to do it — passkey adoption is still growing, device and browser support varies, and account-recovery flows for lost devices need careful design. A pragmatic rollout order is: keep passwords as a baseline, add TOTP-based 2FA as the default second factor, and offer passkeys as the preferred, promoted option for users whose devices support them, with SMS reserved for account recovery rather than as a primary factor.

The Bottom Line

Passkeys and two-factor authentication solve overlapping but different problems. 2FA is a patch on top of passwords that makes stolen credentials less useful on their own; passkeys are a replacement for passwords that removes the shared secret attackers are after in the first place. Both the FIDO Alliance and the platform vendors (Apple, Google) describe passkeys as phishing-resistant by construction, while NIST’s own guidelines flag SMS-delivered codes as the weakest widely used second factor because of SIM-swap risk. If you can only do one thing this year, turning on a passkey wherever it’s available is the higher-leverage move; keeping a TOTP app as your 2FA fallback everywhere else is the second-best option, well ahead of relying on SMS codes alone.

FAQ

Is a passkey a type of two-factor authentication?
Not exactly. A passkey is a single credential that proves both “something you have” (the device) and “something you are/know” (the biometric or PIN that unlocks it), so services like Google count a passkey as satisfying 2-Step Verification on its own rather than needing a separate second factor layered on top.

What happens if I lose the device my passkey is on?
If your passkey synced through a platform keychain (iCloud Keychain, Google Password Manager, etc.), you can usually recover it by signing into that keychain on a new device, subject to that platform’s own recovery process. Apple’s own documentation warns that iCloud Keychain recovery uses a limited number of attempts, after which the keychain is permanently lost, which is why most services still require a backup sign-in method.

Why does NIST treat SMS codes as weaker than an app-based code?
NIST SP 800-63B specifically restricts use of the public switched telephone network for one-time codes and instructs verifiers to weigh risk signals like a recent SIM change or number port before trusting it, because a phone number can be hijacked independently of the account itself. An authenticator app’s code isn’t exposed to that particular attack.

Can passkeys be phished at all?
The FIDO Alliance and platform vendors describe passkeys as resistant to the classic phishing pattern (a fake site capturing a password the user types in) because the cryptographic signature is bound to the real site’s domain. That doesn’t make every part of an account’s security unphishable — account-recovery flows, the device’s own unlock mechanism, and the cloud account syncing the passkey can still be separate targets.

Should a WordPress or small business site bother supporting passkeys yet?
If your site or its login plugin supports WebAuthn, enabling it as an option costs little and benefits your more security-conscious users immediately; just don’t remove existing password/2FA options, since passkey support and adoption are still uneven across browsers and devices.

Sources

• FIDO Alliance: Passkeys
• NIST SP 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management
• Google Account Help: Sign in with a passkey instead of a password
• Apple Platform Support: Use passkeys to sign in to apps and websites
• Microsoft Support: Set up a passkey in Microsoft Authenticator
• RFC 6238: TOTP — Time-Based One-Time Password Algorithm