Passkeys vs Passwords: Phishing Resistance Wins, but Recovery Still Matters

For an account that supports them, a synced passkey is generally the better default than a strong, unique password plus code or push MFA when phishing is the main concern. The UK NCSC’s comparison of personal accounts finds FIDO2 resistant to the adversary-in-the-middle phishing that can defeat traditional MFA.

The choice still depends on what happens outside the normal sign-in. Someone who can unlock your device, gain access to the account that synchronizes your passkeys, or abuse a weak recovery route may still reach the account. Losing access to your only device can also make getting back in harder. Those dependencies matter for consumers and for small businesses choosing how staff sign in.

What changes at sign-in

A strong password works best when it is unique to one service: a breach elsewhere then gives an attacker no matching password to try. A code or push approval adds a separate barrier. In a live phishing attack, however, a fake site can collect the password and relay a code, or induce the user to approve a sign-in request. The attacker needs the second factor at that moment, but the factor is still transferable through the deceptive flow.

A passkey uses a private key held by an authenticator and a matching public key held by the service. The FIDO Alliance’s deployment guidance explains that the authenticator answers a cryptographic challenge scoped to the service’s domain; a fingerprint, face scan or PIN can unlock the credential locally. The website receives no reusable password, and an ordinary lookalike domain cannot obtain a response valid for the real one.

Here, “password plus MFA” means a unique password paired with a conventional code or push approval. A password paired with a FIDO2 security key has phishing-resistant properties of its own and belongs in a different comparison. Likewise, adding a passkey to an account does not necessarily remove every older sign-in option.

How the main threats compare

The methods differ most sharply when an attacker controls what appears to be the sign-in page. For other threats, the condition of the device, the way credentials are stored and the service’s fallback rules can matter as much as the credential itself.

• Phishing: A fake page can harvest a password, while a live relay can capture a code or elicit a push approval. A passkey is tied to the legitimate service’s domain, blocking that ordinary fake-page route. This is resistance to a particular attack on authentication, not a guarantee that every part of the account is safe.
• Credential stuffing: A unique password prevents a password stolen from another service from working here, and MFA can block an attempted login with a stolen password. A passkey removes the reusable password from this service’s sign-in altogether. If a password route remains active, that route still needs protection.
• Device compromise: Malware, a malicious browser extension or a person who knows the device PIN can threaten either arrangement. A passkey protects the exchange with the service; it cannot make a compromised browser or an already open account session trustworthy.
• Recovery: Both methods may depend on a separate proof of account ownership after a loss. If a service accepts a link sent to a compromised email account, or allows a weaker fallback, an attacker may pursue that route instead of attacking the main credential.
• Synchronization: A synced passkey can remain available on another enrolled device. A synced password manager can provide a similar availability benefit for passwords. In either case, access and recovery at the credential provider become part of the account’s security.

Where phishing resistance ends

The domain binding defeats the familiar attack of copying a login page and collecting whatever the user types. It does not protect a device whose authenticator or browser trust settings an attacker has already altered. In published FIDO2 attack experiments, researchers generated attacker-known keys with a modified local authenticator and, separately, manipulated a browser’s certificate trust store to relay a valid challenge. Both demonstrations required control beyond sending a victim a deceptive link; the researchers concluded that passkeys substantially raise the attacker’s effort.

Fallback sign-in is a more routine boundary. If a service lets someone choose a password after a passkey prompt, the account still has a password-based path. If support staff or an automated recovery flow will issue a replacement credential on weaker evidence, the strength of the usual sign-in does not extend automatically to that decision. For an important account, the relevant question is which routes remain available to a legitimate owner and to an impostor.

Device loss and account recovery

With a synced passkey, losing one phone need not mean losing the credential: another enrolled device may still have it, or the owner may restore access through the passkey provider. If that phone was the only enrolled device, restoration depends on the provider’s recovery process. A credential confined to a single device or hardware security key has a different failure mode; without a registered backup, the owner may have to recover access separately at each service.

Recovery carries both an availability risk and an impersonation risk. A strict process may delay the rightful owner after device loss, while a weak one may admit an attacker. For a consumer, an accessible second device and a secure way back into the provider account reduce the chance of being stranded. For a small business, the choice also involves who may restore an employee’s access, what evidence they require and whether a lost credential can be revoked.

The provider and the remaining password

Sync makes passkeys easier to keep through a device change, but it places trust in the provider account and its recovery rules. Protecting that account with phishing-resistant sign-in matters because it may control the route to restoring credentials. Provider designs vary, so a passkey stored in one credential manager does not imply that every manager applies the same safeguards. The same question arises when a password manager synchronizes passwords or authentication codes.

Service-level settings vary too. Google Account Help explains that creating a passkey makes passkey-first sign-in the default while password sign-in remains available, and it describes how to remove a passkey associated with a lost device. That example shows why the active fallback and lost-device controls belong in the decision alongside the usual sign-in method.

Which option makes sense?

Choose a passkey where the service supports it and you can maintain secure access to your devices, credential provider and recovery route. Its clear advantage over a unique password plus conventional code or push MFA is that a convincing fake login page cannot simply collect and reuse the credential. That advantage is strongest when the service’s remaining sign-in and recovery paths are protected to a comparable standard.

Where a passkey is unavailable, a unique password with MFA remains a sound practical choice. The decision is especially sensitive for an account that controls other accounts, such as primary email or a credential manager: losing access there can disrupt recovery elsewhere, while an attacker who gains access may be able to use those same recovery paths.