Passkeys Explained: Phishing-Resistant Passwordless Login

Passwords have failed slowly and then all at once. People reuse them, attackers phish them, and a single leaked database can unlock accounts across the web. Passkeys are the industry's answer, and unlike most password replacements before them, they are backed by every major platform vendor and are already in your phone and laptop. This guide explains what a passkey actually is, how the login works, why it stops phishing where passwords cannot, and where things stand today.

What a passkey is

A passkey is a pair of cryptographic keys tied to one website or app. When you create a passkey, your device generates two mathematically linked keys. The private key stays on your device, protected by hardware and never shared. The matching public key goes to the website and gets stored on its server.

The public key is not a secret. It can verify a signature, but it cannot create one, and it cannot be reversed into the private key. So even if the website is breached and every public key it holds is stolen, an attacker gains nothing they can log in with. This is the structural difference from passwords. There is no shared secret sitting on the server waiting to be stolen and replayed. For the signing mechanism underneath, see How Digital Signatures Work.

How the login works

The passkey login is a challenge and response, and the whole exchange takes a fraction of a second.

1. You start to sign in. The website sends your device a random challenge, a one-time chunk of data.
2. Your device asks you to confirm with your face, fingerprint, or device PIN. This unlocks the private key locally.
3. The private key signs the challenge, producing a signature.
4. Your device sends the signature back. The website verifies it against your stored public key.
5. If the signature checks out, you are in.

Notice what never crosses the network: the private key and your biometric. The biometric only unlocks the key on your own device; it is not transmitted and the website never sees it. What travels is a signature over a one-time challenge, which is useless to replay because the next login uses a fresh challenge.

The WebAuthn ceremony in detail

The plain description above is accurate, but it hides some machinery worth understanding, because that machinery is exactly what makes the phishing resistance work. WebAuthn defines two ceremonies. Registration creates a passkey, and authentication uses it. Three parties take part in each.

The relying party is the website or app you are signing in to, plus its server. The client is your browser or operating system, which runs the WebAuthn logic and enforces the origin checks. The authenticator is the thing that actually holds the private key: the secure enclave in your phone or laptop, or an external security key. When the authenticator is external, the client talks to it using a companion protocol called CTAP, the Client to Authenticator Protocol, over USB, NFC, or Bluetooth. WebAuthn and CTAP together make up FIDO2.

Registration: creating the passkey

Registration is the ceremony that generates the key pair and hands the public half to the server. It runs roughly like this.

1. The server generates a random challenge and sends it to the client along with the relying party identifier, usually the site's registrable domain, and a user handle that identifies your account without revealing your email.
2. The browser calls the authenticator with a navigator.credentials.create request. Before it does, it records the true origin it is running on and the type of request. This bundle is called the client data.
3. The authenticator asks you to confirm presence and identity with a tap, a fingerprint, or a PIN. This is user verification, and it proves a human is present rather than a script.
4. The authenticator generates a fresh key pair scoped to that relying party identifier, stores the private key, and returns the public key together with a credential identifier and, optionally, an attestation statement.
5. The server stores the public key, the credential identifier, and a signature counter against your account.

The relying party identifier is the anchor for everything that follows. A passkey created for bank.example records bank.example as its scope, and the authenticator will refuse to use it for any other origin. That single rule is the seed of the phishing resistance.

Authentication: using the passkey

Authentication is the ceremony you run every time you log in afterwards.

1. The server sends a fresh random challenge and, optionally, a list of credential identifiers it will accept.
2. The browser calls navigator.credentials.get. It builds the client data again, embedding the real origin, the challenge, and the request type.
3. The client checks that the relying party identifier the site claims actually matches the origin in the address bar. If they do not match, the ceremony stops here and no signature is ever produced.
4. The authenticator verifies you locally, then signs a payload made of two parts joined together: the authenticator data (which includes a hash of the relying party identifier and an incrementing counter) and a hash of the client data.
5. The server verifies the signature with your stored public key, confirms the challenge is the one it issued, confirms the relying party hash matches, and checks that the signature counter has moved forward rather than backward.

Because the client data that gets signed contains the real origin, the server can detect a mismatch even in the rare case that a malicious client tried to lie about it. The origin is not a claim the attacker controls after the fact. It is baked into the signed bytes.

A worked example

Picture signing in to an email provider that you registered a passkey with last month. You type the address of the site and click sign in. The server picks a 32 byte random challenge and sends it down with its relying party identifier. Your browser confirms the identifier matches the domain in the address bar, then prompts you for a fingerprint. The secure enclave releases the private key for that one site, signs the authenticator data and the client data hash, and returns a short blob. The server looks up your public key by the credential identifier, verifies the signature, sees the challenge is fresh and the counter has advanced, and drops a session cookie. The entire round trip is one fingerprint touch and well under a second of computation. At no point did a reusable secret exist that a bystander, a breached database, or a lookalike page could capture.

Why passkeys resist phishing

Phishing works against passwords because a password is a portable secret. If an attacker builds a page that looks like your bank and you type your password in, the attacker now has that secret and can use it on the real site. Nothing about the password knows which site it was meant for.

A passkey does know. When it is created, it is bound to the website's origin, its exact domain. At login, the browser and the authenticator only produce a signature for the origin that owns the passkey. If you land on bank-login.example.com instead of the real bank.example, the passkey for the real domain simply will not fire. There is no matching credential, so there is nothing to hand over.

This is why passkeys are called phishing-resistant. The protection is not a filter that tries to spot fake sites. It is structural: the credential is cryptographically tied to the legitimate domain, and a lookalike domain cannot coax a valid signature out of it. Against the phishing techniques covered in What Is Phishing, that binding removes the entire attack.

Passwords versus passkeys

Property	Password	Passkey
Stored on server	A hash of a shared secret	A public key only
Value if server is breached	High: hashes can be cracked and reused	None: public keys cannot log in
Phishing resistance	None: the secret is portable	Strong: bound to the real domain
Reuse across sites	Common and dangerous	Impossible: each site gets its own key
What you do to log in	Recall and type a string	Confirm with biometric or PIN
Second factor needed	Yes, to be safe	No: the passkey is already multi-factor

The last row is worth dwelling on. A passkey login already combines something you have (the device holding the private key) with something you are or know (the biometric or PIN that unlocks it). That makes it multi-factor by construction, which is why a passkey can replace both the password and the separate second-factor step described in the Two-Factor Authentication Guide.

Synced versus device-bound passkeys

Passkeys come in two flavours, and the difference is about where the private key can live.

Synced passkeys back up and sync through your platform account, such as your Apple, Google, or Microsoft account, usually end-to-end encrypted. The upside is recovery and convenience: lose your phone, and your passkeys are still available on your other devices. The trade-off is that their security now leans on the account that syncs them.

Device-bound passkeys never leave the piece of hardware that created them, typically a physical security key. The upside is the highest assurance, since the key cannot be copied off the device. The trade-off is that there is no automatic recovery, so you register a backup key. For choosing hardware, see Best Hardware Security Keys.

For most people, synced passkeys are the right default. For high-value accounts and administrators, device-bound keys on dedicated hardware raise the bar further.

Where adoption stands

Passkeys are past the pilot stage. Apple, Google, and Microsoft all support them across their operating systems and browsers, and passkeys sync through each vendor's account system. A large and growing list of consumer services, from email providers to retailers to developer platforms, now let you sign in with a passkey. The underlying standards, WebAuthn from the W3C and FIDO2 from the FIDO Alliance, are stable and broadly implemented, which is what lets a passkey created on one platform work through a shared model rather than a proprietary one. For the standard itself, see WebAuthn Explained.

The remaining friction is mostly about the edges: account recovery flows, moving passkeys between ecosystems, and helping users understand a login that no longer involves typing anything. These are being worked on, and none of them undermine the core security gain.

Attackers are adapting too, mostly by targeting the fallback paths rather than the passkey itself. Our Exploit Intelligence dashboard tracks live vulnerabilities in authentication and account-recovery components, so you can see where the real pressure is landing as passwordless login spreads.

What passkeys do not fix

It helps to be precise about the boundary. Passkeys make the login step phishing-resistant, and that is a large gain, but a login is only one part of an account's security. Three areas stay your responsibility.

Account recovery is the big one. Remove the password and the "reset your password" flow no longer exists, so whatever you put in its place, an email link, a recovery code, a support process, becomes the weakest path into the account. Attackers know this and increasingly aim there rather than at the passkey. Design recovery to be as strong as the passkey login it backs up.

Session security is another. Once a passkey logs you in, the session that follows is an ordinary session with an ordinary token, and it can still be stolen through malware or a hijacked cookie. Passkeys protect the front door, not the whole house.

And device trust matters. A synced passkey is only as safe as the platform account it syncs through and the devices that account reaches. Securing that account, ideally with its own strong authentication, is part of the picture rather than an afterthought.

None of this diminishes the core win. It just means passkeys are a strong login, deployed alongside the rest of your account security rather than in place of it.

How passkeys compare to other login methods

Passkeys are one point on a spectrum of ways to prove who you are. Ranking them against the common alternatives makes the trade-offs concrete.

Method	Phishing resistant	Secret on server	Works offline	Main weakness
Password only	No	Hash of a shared secret	Yes	Reuse, cracking, phishing
SMS one-time code	No	The phone number of record	No	SIM swap and interception (MITRE T1111)
Authenticator app (TOTP)	No	A shared seed	Yes	Real-time relay to a fake page
Push approval	Partly	A registration record	No	Approval fatigue (MITRE T1621)
Magic email link	No	Nothing durable	No	Mailbox takeover, link relay
Security key (FIDO U2F)	Yes	A public key	Yes	Carrying and recovery
Passkey (FIDO2)	Yes	A public key	Yes	Recovery flow, account sync trust

The pattern in the table is clear. Every method that keeps a shared secret, whether it is a password, a TOTP seed, or a code sent over the network, can be relayed or replayed by an attacker who tricks the user in real time. A modern phishing kit sits between the victim and the real site, forwards the one-time code the moment it is typed, and steals the resulting session. Passkeys and the U2F security keys they descend from break that pattern because the browser refuses to sign for the wrong origin, so there is no code to forward in the first place.

How passkeys evolved

Passkeys did not appear from nothing. The FIDO Alliance published its first specifications in 2014, one for a passwordless flow and one, called U2F, for a second-factor security key. U2F worked and shipped, mostly as physical keys that you plugged in after typing a password. Its ceiling was adoption: a spare piece of hardware is a hard sell for the average person, and losing it meant a painful recovery.

The next step folded that model into the web platform. WebAuthn became a W3C standard, browsers built it in, and the combination of WebAuthn plus CTAP was named FIDO2. Now any website could invoke a security key or a platform authenticator through a standard browser API, with no plugin.

The final step, the one that produced the word passkey, was making the credential recoverable. Early FIDO credentials were bound to one device, which meant a lost phone was a lost credential. The platform vendors added end to end encrypted sync so a credential could back up to your account and reappear on your other devices. A credential that can move like this is a multi-device credential, and the marketing name for it, agreed across the industry, is passkey. That single change is what took the technology from a security enthusiast's tool to something a phone maker could turn on for a billion people.

Detection and monitoring for defenders

If you run a service, passkeys change what your logs should watch for. Because the login step itself is hard to attack, the useful signals move to the edges of the flow.

• Counter regressions. A signature counter that fails to advance on a device-bound authenticator suggests a cloned or exported credential. Alert on it and consider forcing re-enrolment.
• Recovery path spikes. A surge in password resets, recovery-code use, or support-driven account resets is the sign that attackers have shifted to the fallback rather than the passkey. Rate limit and add friction to recovery, since that is now the weakest door (CWE-640, weak password recovery mechanism).
• New authenticator enrolment. Treat adding a passkey as a sensitive action. Require a fresh user verification, notify the account owner out of band, and log the origin and device details.
• Fallback downgrade attempts. Watch for sessions that skip the passkey and fall back to a password or a one-time code from unusual locations. Attackers who cannot beat the passkey will try to force a weaker method (MITRE T1556, modify authentication process).
• Session anomalies after login. A valid passkey login followed by a session used from a second network or device may indicate a stolen session token rather than a defeated passkey (MITRE T1539, steal web session cookie).

The theme is consistent. Once the front door is a passkey, your monitoring budget belongs on recovery, enrolment, and session handling.

Common misconceptions

A few beliefs about passkeys come up again and again and deserve correcting.

"My fingerprint is sent to the website." It is not. The biometric is a local unlock for the private key and never leaves the device. The site receives a signature, and nothing else.

"If I lose my phone, I lose my accounts." For synced passkeys, the credential is backed up to your platform account and reappears on your other devices, so a lost phone is an inconvenience rather than a lockout, provided you enrolled a backup and can still reach your account.

"A passkey is just a password stored in my browser." A stored password is still a shared secret that can be phished or leaked. A passkey is a private key that never leaves your device and never travels to the server, so there is nothing on the server to steal and nothing to type into a fake page.

"Passkeys mean I no longer need a second factor." The passkey already is two factors, something you have and something you are or know, so a separate second step is redundant for the login itself. The care you used to spend on a second factor now belongs on account recovery.

"Passkeys make my account unhackable." They make the login step phishing-resistant. Session theft, malware on your device, and weak recovery flows remain real, so passkeys are one strong layer among several (CWE-287, improper authentication, covers the login, not the whole account).

Frequently asked questions

Can two people share one passkey? Not cleanly. A passkey is bound to the authenticator that created it and, for synced passkeys, to one person's platform account. Shared access is better handled with separate passkeys per person and role-based access on the service, rather than by copying a credential.

What happens if a website is breached? The attacker gets public keys, which cannot log in and cannot be reversed into private keys. There is no password hash to crack and no secret to replay. The breach still matters for other data the site holds, but your login credential is not exposed (CWE-522, insufficiently protected credentials, is the class of problem passkeys avoid on the server side).

Do passkeys work across different brands of device? Yes, through the shared standard. A passkey created on one platform can be used on another device by scanning a QR code and approving on your phone over a local Bluetooth check, which confirms the two devices are physically near each other. Moving a passkey's storage between ecosystems is still maturing, but using one across devices already works.

Are passkeys safe if my phone is stolen? The thief still needs your biometric or device PIN to unlock the passkey, and modern devices rate limit and lock after failed attempts. Set a strong device unlock and enable remote wipe. The private key sits in secure hardware that resists extraction even with the phone in hand.

Can I still use a password as a backup? You can, and many people keep one during the transition. Be aware that leaving a password enabled preserves a phishable path into the account, so for high-value accounts the goal is to remove or tightly restrict the password once your passkeys and recovery are solid.

Do passkeys require an internet connection? The signing happens locally on your device, so the cryptography itself is offline. You still need connectivity to reach the website and complete the login, the same as any online sign-in.

How is a passkey different from a hardware security key? A hardware security key is one kind of authenticator, usually device-bound, that holds FIDO credentials on a physical token. A passkey is the same underlying credential, more often synced through a platform account and stored in your phone or laptop. A hardware key can hold a passkey, and for the highest assurance many people use both.

Getting started

The practical path is simple. On accounts that offer it, add a passkey from the security settings. Keep the password in place at first as a fallback while you get comfortable, then remove or lock it down once your passkeys and backups are in order. Enrol a second authenticator so a lost device is an inconvenience rather than a lockout. That is most of the work, and it moves your most important accounts onto a login that a phishing page cannot defeat.

Related guides

• WebAuthn Explained
• Two-Factor Authentication Guide
• Best Hardware Security Keys
• What Is Phishing