Passkeys vs Passwords: Which Attacks Each One Stops, and Which Neither Does

Against phishing, reused passwords and a breached database, a passkey is the stronger credential, and three things remain that a passkey does not fix: a weak cloud or sync account, a fallback sign-in that still accepts a password, and malware on the device. The comparison of passkeys vs passwords below sets eight attacks against three ways of signing in, and marks the cells where the sources read are silent.

The FIDO Alliance describes a passkey as “an authentication credential based on FIDO standards”, held on a device or a hardware key and used with the same unlock the person already uses on that device. A password is a shared secret, known to the person and held by the service. A passkey is built the other way round: according to the Canadian Centre for Cyber Security, what a service stores, and therefore what an attacker can take from it, is a public key.

This article is general information. It is written to the sources as they stood in September 2026 (NIST, the UK National Cyber Security Centre, the Canadian Centre for Cyber Security, the FIDO Alliance, myGov and Scamwatch) and names no product.

The comparison by attack

Each cell states only what a cited source says. Where no source speaks to a cell, the cell says so. That gap is part of the finding: the cited sources describe what a passkey does far more fully than they describe what a password with a texted code does.

Three readings follow from the table. First, the passkey column is the only one in which phishing, reuse and a breached database are each answered by the design of the credential, and not by the vigilance of the person using it. Second, the texted code is exposed at two points: a code typed by hand is not phishing-resistant under NIST, and a SIM swap sends the code to the scammer, according to Scamwatch. Third, the last three rows of the passkey column carry caveats, and those caveats come from a national cyber security agency and not from any vendor.

Take a hypothetical person who signs in to a service with a password and a texted code, and is offered a passkey. Reading the first and fourth rows, the change removes two exposures at once. A fake sign-in page can no longer collect something the attacker can replay, because on NIST’s definition a code typed by hand is not phishing-resistant and a passkey does not rely on the person’s vigilance. And a SIM swap no longer redirects a code, because no code is sent. The change leaves three other rows exactly as they were: the cloud account, the fallback and the device. The gain is real, and it is partial.

What the table excludes is as important. It says nothing about convenience, cost or the number of services that offer a passkey, because none of the sources read supplies a figure for any of them.

Why a passkey resists phishing and breaches

The first reason is structural. The FIDO Alliance says passkeys involve no shared secrets and are “unique per app/website/service”. A service therefore holds nothing that can be replayed at another service. The Canadian Centre for Cyber Security draws the consequence for breaches: a breach of a website does not inherently result in the compromise of user credentials, because what an attacker obtains is a public key. The FIDO Alliance draws the matching consequence for reuse, naming phishing and credential stuffing as attacks that exist “due to the prevalence of password reuse”. A credential that cannot be reused cannot be stuffed into other sites.

The second reason is a matter of definition. NIST SP 800-63B-4, finalised in July 2025, defines phishing resistance as the protocol preventing disclosure of the authentication secret “without relying on the vigilance of the claimant” (section 3.2.5). It states that output a person enters by hand, which covers out-of-band codes and one-time passwords, “SHALL NOT be considered phishing-resistant”, and it does not treat passwords as phishing-resistant either (section 3.1.1). It also requires services to offer at least one phishing-resistant option at its second authenticator assurance level (section 2.2.2). These are requirements on services, and they describe a property and not a product.

The UK National Cyber Security Centre puts the same property in plain terms: passkeys are “resistant to phishing, as they can’t be intercepted, reused or stolen like passwords”. Scamwatch supplies the threat side of the ledger. It lists phishing, data breaches and social media as ways scammers collect information, names reused and easily guessed passwords as a weakness, and describes SIM swapping as a route by which SMS codes and one-time PINs reach the scammer. The Scamwatch page does not mention passkeys, so it is evidence about the attacks and not about the remedy.

What a passkey does not fix

A passkey removes certain attacks. It does not remove the account around it. The Canadian Centre for Cyber Security, in guidance dated April 2026, lists what remains, and the list has three parts.

1. A weak cloud account. A synced passkey lives in a cloud or sync account, and the Canadian Centre says a cloud account with weak security, or a weak way of proving who owns it, makes a synced passkey easier to obtain.
2. A fallback sign-in. Where a service lets a person fall back to a password or another factor, the Canadian Centre says this “weakens security”. A passkey that sits beside an open password route is only as strong as that route.
3. Malware and session attacks. The Canadian Centre lists session hijacking, malware that triggers the web authentication API, and cross-site request forgery as remaining risks.

The fallback is the item a person can check for themselves. When a service offers a passkey, the useful question is whether the old password sign-in remains beside it, and whether that password is as well protected as the passkey. The Canadian Centre’s point is that where a fallback remains it weakens security. A passkey in front of an open password route has moved the weak point and has not removed it.

Take a hypothetical person who sets up a passkey on a phone, with the passkey synced to a cloud account protected only by a short, reused password. The credential is strong, but the route to it is not, and that is the case the Canadian Centre describes.

NIST adds a limit from the other direction. Its standard says syncable authenticators “SHALL NOT” be used at the highest assurance level (section 2.3.2), because a syncable private key has to be exportable. That is a statement about high-assurance settings and not about personal accounts, and nothing in the sources read says a synced passkey is unsafe for personal use.

What each statement excludes: the Canadian Centre describes risks. It does not rank them, give their frequency or say how often any of them occurs, and none of the other sources gives a number either. A reader should not infer from the list that the risks are common, or that they are rare.

If you lose the phone

A lost phone is the practical test of any credential, because a passkey is something a person holds and not something a person remembers. The sources agree on the broad answer.

The FIDO Alliance says synced passkeys can be restored to a new device through the provider, that passkeys can be backed up, and that a FIDO security key can act as a recovery credential. The UK NCSC says the credential manager makes a backup of the passkeys. myGov, on a page updated on 24 August 2026, separates the two types. A synced passkey is saved to a password manager and available on all devices that use that manager. A non-synced passkey is saved on a physical security key or a device and is not shared. The page advises creating more than one passkey if a security key is used, and notes that a password may still be needed for some settings and for recovery.

Where recovery has to start, the FIDO position is that the service treats it as normal account recovery. The procedure belongs to each provider and each service, and none of the sources describes one that this article could repeat. What the sources do support is a short checklist, with no product named.

1. Create a second passkey, on a second device or a security key, where the service allows it.
2. Set up the provider’s own recovery option before it is needed.
3. Treat an unlocked phone as the weak point. A passkey is used the way the device is unlocked, on FIDO’s description, so a strong lock on the device matters.

Take a hypothetical household in which one adult has a single non-synced passkey on one phone, and the phone is lost. On myGov’s description, a non-synced passkey is not shared, so it exists on no other device, and a password may be needed to recover. A second passkey created earlier would give that adult a second route in.

There is one caution on recovery. In the Canadian Centre’s terms, a fallback weakens security, and the same logic would apply to a recovery route that is weaker than the passkey it replaces, although the sources read do not say so directly. What this excludes: no source gives a recovery time, a success rate or the steps for any named provider.

Where you still need a password

Not every service offers a passkey. The UK NCSC says that where passkeys are not available, a person should use strong passwords, for example from a password manager, and turn on two-step verification. The Canadian Centre likewise recommends multi-factor authentication for high-value services where passkeys are unavailable.

NIST SP 800-63B-4 (section 3.1.1.2) sets the rules for the service side, and they run against some folk wisdom. Single-factor passwords should be at least 15 characters long. Services shall not impose composition rules, such as a required symbol. They shall not require periodic changes, although a change is still required on evidence of compromise. For the reader, the practical reading is that length and uniqueness matter more than complexity: a long, unique password beats a short, tricky one. That is a reading of the standard’s rules and not a rule NIST states for individuals. The rules are written for the organisations that run sign-in systems, and a person cannot enforce them. They do show what the standard treats as good practice: a service that insists on composition rules or forced periodic changes is asking for things the standard says services shall not require.

A password that stays in use is also the fallback the Canadian Centre warns about. Where a service lets a passkey account fall back to a password, that password should be as strong as the passkey it sits beside.

What this leaves out

This comparison names no product and compares no vendors. It makes no claim about speed, none about how many services support passkeys, and none about any specific breach. It does not rate the strength of any particular password manager or cloud account. The Scamwatch page is treated as evidence about attacks only. A cell that reads “not covered by the sources read” is a gap, not a claim of safety.

Passkeys First, Passwords as the Backup

Where a service offers a passkey, use it for personal accounts, because it takes phishing and password reuse out of play as ways in and leaves no shared secret in a breached database. Then keep the rest of the chain strong: a second passkey or a recovery route, a strong lock on the phone, and a long unique password wherever a password remains. A passkey is only as good as the account, the fallback and the device around it.

Sources: NIST, SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, July 2025 (https://pages.nist.gov/800-63-4/sp800-63b.html); UK National Cyber Security Centre, Passkeys: what you need to know (https://www.ncsc.gov.uk/information/passkeys-what-you-need-to-know); Canadian Centre for Cyber Security, Cyber security considerations for passkeys, ITSAP.30.033, April 2026 (https://www.cyber.gc.ca/en/guidance/cyber-security-considerations-passkeys-itsap30033); FIDO Alliance, Passkeys (https://fidoalliance.org/passkeys/); myGov, Use passkeys, updated 24 August 2026 (https://my.gov.au/en/about/help/mygov-website/sign-in-to-mygov/use-passkeys); Scamwatch, Account or identity takeover scams (https://www.scamwatch.gov.au/types-of-scams/account-or-identity-takeover-scams)