Passkeys vs Passwords and 2FA: Which Login Method Is Safer—and What Can Still Go Wrong?

For most people, a properly implemented passkey is safer than a password, including a password supplemented by SMS, email or authenticator-app codes. Passkeys resist conventional phishing, cannot be reused across unrelated services and leave the website holding a public key rather than the private authentication key. The UK National Cyber Security Centre recommends choosing passkeys where available and assesses them as at least as secure as two-step verification paired with the strongest password.

Passkeys do not secure everything around the login. A stolen unlocked device or session token may expose an account, synchronized credentials make the provider account and its recovery process important, and a weak fallback can bypass a strong primary credential. For mainstream accounts, a synchronized passkey is usually the practical choice; administrators and people facing targeted attacks should consider separately stored, device-bound hardware keys.

What changes when a password is replaced?

A password is a shared secret that can be typed, copied or disclosed. A passkey instead uses a public-private key pair associated with one account at one relying party: the service stores the public key, while an authenticator protects the private key. MDN’s passkey documentation describes how the authenticator signs a server challenge and the service verifies the resulting assertion with its public key.

The relying party may require user verification before the authenticator uses the credential, commonly through a device PIN or biometric. Biometric processing remains local to the device rather than being sent to the service, according to the FIDO Alliance’s passkey guidance. Not every authenticator supports user verification, so administrators should verify the properties they require rather than assuming the label “passkey” guarantees the same local controls everywhere.

Because the authenticator generates the credential, users cannot choose a short or easily guessed passkey. It also creates a separate credential for each relying party, eliminating cross-site reuse. A password manager can generate unique, strong passwords, but those passwords remain transferable secrets that a malicious page may capture.

Why passkeys outperform passwords and code-based 2FA

Passkeys have their clearest advantage against phishing. The browser and authenticator enforce the relying-party scope, so a lookalike domain cannot request a credential created for the legitimate domain. By contrast, an attacker-in-the-middle can relay a password and a one-time code to the real service while the victim believes they are signing in to a familiar page.

Passkeys also remove the reusable secret required for credential stuffing. Stealing a credential associated with one relying party does not produce a credential that can be tested against other services. If attackers copy a service’s passkey records, they obtain public keys rather than the private keys required to sign new challenges; MDN’s security analysis notes that attackers able to modify the database might still compromise accounts by inserting fraudulent credentials.

Password plus 2FA remains considerably safer than a reused password alone, especially when no passkey option exists. However, SMS, email, time-based codes and approval notifications are not equivalent to origin-bound FIDO authentication. The NCSC’s credential comparison classifies traditional multifactor methods as vulnerable to attacker-in-the-middle phishing and explains how repeated approval prompts can produce a fatigue attack.

A threat-model comparison

The right choice depends on the failure you are trying to prevent. These outcomes assume a correct service implementation and, for the passkey scenarios, an authenticator that requires suitable user verification.

• Phishing: Password-only login is directly exposed. SMS, email and authenticator-app codes can be relayed with the password. An origin-bound passkey or FIDO security key prevents the lookalike site from requesting the legitimate credential.
• Credential stuffing: Reused passwords make cross-service attacks possible. A second factor may stop a completed login, but it does not make the exposed password unique. Passkeys remove the reusable credential from this attack path.
• Service database breach: Password hashes may be attacked offline, with the outcome depending on password quality and server-side protection. A passkey database contains public keys, but a broader compromise that permits changes to credentials, sessions or application logic can still expose accounts.
• Stolen unlocked device: Any accessible authenticated session may already grant account access. Use of a passkey depends on the authenticator’s local protections and the service’s user-verification policy; a thief who knows a weak device PIN may be able to satisfy those controls.
• Provider-account takeover: Synced passkeys may become available on devices enrolled through the same credential provider. The provider’s authentication, device-enrollment and recovery controls therefore become part of the security boundary.
• Recovery failure: Sync can preserve credentials after one device is lost, while a sole device-bound credential may disappear with its authenticator. Conversely, an email, SMS or support recovery route may provide an easier way around the primary login.

These are not contradictions to the conclusion that passkeys are generally safer. They distinguish protection delivered by the authentication protocol from the security of devices, sessions, credential providers and recovery decisions surrounding it.

Synchronized and device-bound passkeys solve different problems

Synchronized passkeys prioritize availability. A credential provider can make them available on trusted devices and restore them after device replacement. FIDO distinguishes credentials synchronized through a cloud service from device-bound passkeys that remain on one authenticator, as explained in its definitions of passkey storage.

Synchronization does not remove the passkey’s phishing resistance at the website, but it concentrates some risk in the provider account. The NCSC’s 2026 technical paper says the Apple, Google and Microsoft first-party synchronization systems it reviewed in 2025 required two-factor authentication for passkey storage and supported phishing-resistant authentication themselves. The same paper cautions that FIDO2 does not prescribe minimum security requirements for every synchronization implementation.

Device-bound credentials prioritize isolation and control. A credential held by a non-synchronizing authenticator or hardware security key is not exposed through remote takeover of a synchronization account. The trade-off is availability: if that authenticator is lost or destroyed, the credential cannot be restored from a cloud copy.

The approaches can be combined. You might use a synchronized passkey for routine access and register a hardware key kept elsewhere as an independent backup. An organization might allow synchronized passkeys for ordinary accounts while requiring managed device-bound credentials for privileged roles.

Plan for device loss before it happens

Losing one phone need not mean losing every passkey. If credentials were synchronized to another trusted device, you may still have direct access; otherwise, restoration depends on securely recovering the provider account. A device-bound credential offers no equivalent restoration unless another authenticator was registered in advance.

Registering multiple passkeys for one account is a resilience measure, not the unsafe reuse associated with passwords. MDN’s guidance on lost authenticators recommends supporting an everyday passkey and a separate roaming authenticator kept safely as backup. Store the backup separately so the same theft, lost bag or local incident does not remove both authenticators.

After losing a device, remove its registered credential from important accounts where that control exists, revoke its active sessions and remove the device from the credential-provider account. Deleting a private key from a device is not necessarily the same as invalidating the corresponding public key at the service, so account-side revocation matters.

Passkeys do not protect an authenticated session

Web services generally issue a session token after authentication so users do not have to present their credential on every request. The OWASP Session Management Cheat Sheet explains that this token temporarily carries the authority of the strongest authentication method used; capturing a valid token can therefore enable impersonation without presenting the password or passkey again.

This keeps malware, malicious browser extensions, cross-site scripting and physical access to unlocked devices in the threat model. Services should protect session cookies, enforce appropriate expiration, expose session-management controls and request fresh authentication for sensitive changes. Users should update devices and browsers, remove unnecessary extensions, lock devices promptly and revoke unfamiliar sessions.

Changing a password or deleting a passkey does not automatically prove that every existing session has ended. When responding to suspected compromise, revoke sessions as a separate action wherever the service provides that option.

When hardware security keys remain useful

A hardware security key can hold a device-bound FIDO credential outside your everyday phone and synchronization account. The FIDO Alliance’s security-key guidance says these keys can serve as recovery credentials when access to all devices containing synchronized passkeys has been lost. They can also meet environments that need assurance that only one copy of a cryptographic key exists.

This added isolation is useful for administrators and people likely to face targeted phishing, provider-account attacks or device compromise. It brings operational work: compatible keys must be acquired, registered and available when required. For critical access, use more than one registered authenticator and keep the backup in a separate secure location.

A hardware key may be the passwordless credential or a phishing-resistant second factor after a password, depending on the service. The second configuration retains the password’s management burden, but the hardware factor can prevent a captured password from completing a remote login.

Recommendations for consumers, administrators and high-risk users

Consumers: Prefer a synchronized passkey from a credential provider whose account you can protect and recover securely. Maintain an independent route into critical email, financial and storage accounts. Where passkeys are unavailable, use a unique password generated by a password manager and the strongest 2FA method the service offers.

Administrators: Treat deployment as an authentication-lifecycle project, not merely a change to the login screen. Support multiple authenticators, make registered credentials identifiable, protect enrollment and removal as sensitive actions, offer prompt revocation and audit every fallback. Recovery should provide assurance comparable to the primary login instead of silently reducing a passkey-protected account to email or SMS alone.

High-risk users: Register at least two phishing-resistant credentials and keep one device-bound hardware key separately. Protect the passkey-provider and primary email accounts to the same standard, minimize weaker fallbacks where possible, and maintain a recovery inventory without storing authenticator PINs beside the devices.

Choose the recovery design before removing fallbacks

Begin with your most consequential account and determine how you would regain access after losing every everyday device. Strengthen any provider, email address or phone number on which that answer depends, then add a second authenticator before removing a working fallback.

1. Enable a passkey and verify that it works on your usual device.
2. Add a separate backup passkey or hardware security key if the service supports multiple credentials.
3. Review the authentication, enrolled devices and recovery settings of the credential provider.
4. Identify accounts that still permit password, SMS, email or support-assisted recovery and secure those dependencies.
5. Review registered credentials and active sessions after replacing, selling or losing a device.

The practical target is a phishing-resistant primary login, a separately controlled recovery credential and a recovery process that does not undo the protection of either one.