Are Passkeys Phishing Resistant? What Each Login Method Stops

Passkeys are phishing resistant: a fake login page cannot collect anything that works on the real site. That is one attack out of several, and every login method stops some and walks into others. A password falls to a fake page, an SMS code to a SIM swap, an authenticator code to a page that passes it on in time, and malware already on the device can get around all of them.

A password or a code is something a fooled person can hand over. A passkey holds a key that signs only for the site it was made for, so a fooled person has nothing to hand over.

What each login method stops

The password column assumes one memorable or reused password. The manager column assumes a unique random password for every site.

A manager fills a login only on the address saved with it, so a lookalike domain gets nothing automatically, but a password pasted in by hand defeats that. On an infected device no method is safe: a keylogger (software that records keystrokes) reads a typed password, and a stolen session cookie, the token a site gives your browser after sign-in, works whatever login produced it.

Password hashing, salt and credential stuffing

A site should never store your password, only a hash of it: a one-way scramble that can be recomputed but not reversed. A salt, a random value stored beside each hash, makes two accounts with the same password produce different hashes, which defeats precomputed lookup tables. Good schemes are also deliberately slow. A leaked table still lets an attacker guess offline at their own pace, and the passwords people choose most often fall first.

Composition rules do not change that. P@ssw0rd has a capital, a digit and a symbol, and it appears in leaked-password data more than six million times. Current standards no longer ask sites to demand mixed character types. They ask them to reject passwords already known from leaks and to accept long ones, with 15 characters as the floor when a password is the only factor.

The same example in a Short:

Credential stuffing is how leaks get used. Attackers take email and password pairs from one breach and try them, automatically, on other sites. It works only where a password was reused.

Why SMS codes and authenticator apps still get phished

An SMS code travels over the phone network, and a SIM swap puts it in the wrong hands: the attacker persuades your carrier to move your number to a SIM they hold, and every text, codes included, goes to them. That makes SMS the weakest of the common second steps. Microsoft starts retiring SMS and voice codes in Entra ID, its work and school sign-in, in February 2027.

An authenticator app avoids the carrier. It computes a short code on the phone from a secret shared with the site and the current time, in 30-second steps by default, so a SIM swap never touches the code. The weakness is that the code knows nothing about where you type it. A fake page asks for the password, then for the code, and forwards both to the real site before the code expires. Any code a person reads and types can be relayed like this, whether it arrived by text or came from an app.

Are passkeys phishing resistant? What the browser checks

Creating a passkey makes your device generate a key pair for that one site. The private key never goes to the site: it stays in the device's protected storage or in a credential manager. The site keeps the public key, which can verify a signature but cannot make one. At sign-in the site sends a fresh random challenge, so a recorded answer is useless the second time, which is how a replay attack is defeated. You unlock the key with a fingerprint, face or PIN, and the device signs two things: the challenge and the web address of the page making the request. The browser fills in that address itself, not the page and not you.

A page on another domain cannot even request the real site's passkey: the browser compares the domain being asked for with the page's own address and refuses a mismatch, and the real site would turn down a response that was signed for another address.

The fingerprint or face stays on the device. The site receives a signed response and a flag saying the user was verified.

The catch: recovery, fallbacks and the device itself

• Adding a passkey does not remove the password or the SMS code from an account unless you do. A phishing page can claim that passkeys are unavailable and offer those instead, and the weaker method is then phished as before. A Microsoft account can drop its password altogether.
• Synced passkeys come back when you sign in to the Apple or Google account, or to a manager such as 1Password or Bitwarden, from a new device and pass its checks, so that account becomes the thing to protect. Apple's keychain recovery needs the Apple Account password, an SMS reply and a device passcode. A device-bound passkey, on a security key for example, is gone with the device, which is why a second one should be registered.
• A passkey protects the sign-in, not the computer. Attacks published in August 2026 let malware already running on a Windows PC take over accounts protected by Google-synced passkeys in Chrome and extract all of them.
• The lock screen is part of the trust: anyone who can unlock the device can use its passkeys, so create them only on devices that are yours. On a computer that is not yours, scan the QR code it displays and approve on your phone; the passkey stays there.
• Portability is still uneven. A synced passkey lives in one provider's vault, and moving it between managers needs a shared format. The Credential Exchange Format is a proposed standard and iOS 26 can export to apps that support it, but the transfer protocol is still a working draft.

Sync, device-bound keys and each platform's recovery are covered in the full passkey guide.

What to do today

1. Add a passkey first to the accounts that can reset all the others: your main email address and the Microsoft, Apple or Google account you use most. Game accounts follow, since PlayStation, Nintendo and Roblox let you sign in with one.
2. Create each passkey on a device you own, then add a second one on another device or a hardware security key and test it before changing anything else.
3. Remove the fallbacks the site lets you remove, the password and the SMS code, and keep the recovery codes offline.
4. For sites without passkeys, give each account its own long random password from a manager or from the password generator on packet.guru, which makes strong random passwords locally in your browser. Use an authenticator app for the second step instead of SMS.
5. Look up your email addresses in Have I Been Pwned and replace the password of any site you still use that shows up in a breach.