A passkey authenticates with a private-key signature, while the login service holds the public key. Synced passkeys can transfer encrypted credentials between devices; device-bound passkeys do not sync. MFA depends on required user verification, and device, sync-account and recovery protections still matter.
The private key is not sent to the login service
FIDO2/WebAuthn uses a key pair. The login service receives the public key and later verifies a signature; it does not receive the private key. Synced passkeys may synchronize encrypted credentials through a provider, whereas device-bound passkeys remain on their authenticator. Protect the sync account and recovery process as well as the device.
Password
you and the server share one secret. stolen if the server leaks or you type it into a fake site
Passkey
A leaked public key alone cannot create the private-key signature needed to sign in.
"The server has only the public key" is what matters. A public key is, by definition, fine to publish, so even if the database leaks, it can't be used to log in on its own (the opposite premise from password storage → what hashing is).
How it differs from password + SMS
Password + SMS code
- The shared secret (password) can leak / chains via reuse
- Type it into a fake site and the code is relayed too
- Tends to rely on "I can spot the fake"
Passkey
- A leaked public key alone cannot create the private-key signature needed to sign in.
- The signature is bound to the domain = won't complete on a fake site
- Blocks the fake site by design, even if the user doesn't notice
Adversary-in-the-middle phishing (AiTM) relays the correct code along with everything else, even if you carefully enter it (→ what phishing is). Because a passkey's signature is tied to the domain, that route is closed off in principle.
Passkey vs 2FA vs hardware security key
A passkey gets described both as "a kind of 2FA" and as "a password replacement," so the terms are easy to mix up. Side by side by role:
| Passkey | Password + one-time password | Hardware security key | |
|---|---|---|---|
| What you use to log in | domain-bound signature; PIN or biometrics when user verification is required | A memorized string + a code (often 6 digits) | A private key inside a USB/NFC key + PIN or touch |
| What the server stores | A public key | A password hash (plus the code-generating secret for authenticator apps) | A public key |
| If you use it on a fake site | The signature won't complete | Both password and code can be relayed | The signature won't complete |
| If you lose the device | Synced passkeys work on another device | Needs authenticator migration or recovery codes | A spare key or another supported recovery method may be needed |
| Best for | Almost all personal use | Services without passkey support | Admin accounts, high-risk people |
A FIDO2-capable hardware security key can store a device-bound passkey without cloud synchronization. A backup key or another supported recovery method helps avoid lockout. what 2FA is / what a one-time password (OTP) is.
Synced passkeys and device-bound passkeys
Passkeys come in two kinds depending on where they're stored.
- Synced passkeys: stored in iCloud Keychain, Google Password Manager, or a password manager app, and usable on your other devices signed in to the same account. Losing one device is less likely to lock you out
- Device-bound passkeys: kept only inside the device that created them, such as a hardware security key. Since they don't sync, you control exactly where they live
NIST SP 800-63B-4 (July 2025) permits syncable authenticators at AAL2 only when the relevant requirements are met, including user verification and protection of the sync fabric. AAL3 requires non-exportable keys and additional controls; a non-syncing key alone does not establish compliance. Choose according to the required assurance, device and sync-account security, and recovery conditions.
Weak points that remain after adding a passkey
Even if the passkey itself resists fake sites, an account is only as strong as its weakest way in.
- Password login is still enabled: on many services, adding a passkey leaves password and SMS-code login in place. A fake site will ask for that remaining method instead of the passkey
- Weak recovery: if account recovery only takes an SMS or the registered email, that becomes the way in. Protect the recovery email account itself with a passkey too
- Weak device lock: a passkey becomes usable when you unlock the device, so avoid an easy-to-guess screen-lock PIN
A real example: securities account takeovers and mandatory passkeys
In 2025, Japan saw many cases where login IDs and passwords stolen through fake sites posing as securities firms were used to make unauthorized trades in other people's brokerage accounts. Japan's Financial Services Agency (FSA) says on its warning page that phishing-resistant MFA such as passkeys is being made mandatory, and urges users to set it up promptly.
The Japan Securities Dealers Association (JSDA) revised its guideline on preventing unauthorized access in online trading, effective October 15, 2025. It requires firms to implement phishing-resistant MFA (for example, passkey-based or PKI-based authentication) for important actions such as login, withdrawals, and changing the withdrawal bank account, and to make it mandatory by default. Customers without the needed device are to be offered alternative MFA.
Two lessons from this case:
- The industry shifted from "user vigilance" to "design": urging people to spot fake sites didn't stop the losses, so the default became authentication that won't complete on a fake site
- The examples named are passkeys and PKI, not methods where a person reads and types a code: NIST likewise says manually entered one-time passwords can't be phishing-resistant
For concrete steps as a brokerage customer — passkey login and activity notifications — see our article on the unauthorized access at Daiwa Securities' contractor.
How to check your own accounts and services
Check whether your important accounts support passkeys
Look for a "passkey" option in the security settings of your email, password manager, cloud, brokerage and bank, and GitHub accounts. Your password manager's list also shows which services already have a passkey saved.
Register a second device or a spare key
With synced passkeys, confirm they work on another device signed in to the same account. If you use non-syncing hardware keys, register a spare and store it in a different place.
Close the password and SMS side doors
After adding a passkey, check whether you can still log in or recover with only a password or only an SMS code. If there's a setting to skip the password or remove SMS, use it. Store recovery codes somewhere separate, such as your password manager.
If you build the service, check domain verification and recovery
When implementing passkeys (WebAuthn), verify on the server that the signature is scoped to your domain (the RP ID) and origin. Don't write signature verification yourself; use a well-established library. And if a recovery path that needs only SMS remains, that becomes the weak point even after passkeys go live.
This site's view: you don't have to replace everything at once
Passkeys are powerful, but you don't need to go fully passwordless across every account today. Our stance: migrate important accounts first. Add passkeys to the accounts you use to recover or manage your other accounts — email, cloud, your password manager — and set up recovery (register on multiple devices, keep a backup). For services where a password remains, protect them with a password manager and phishing-resistant MFA, then move to passkeys as each service adds support.
Sources (primary)
- FIDO Alliance, "Passkeys" — fidoalliance.org (definition, synced vs device-bound passkeys, phishing resistance)
- W3C, "Web Authentication: An API for accessing Public Key Credentials Level 3" — w3.org (credentials scoped to the RP ID and origin)
- NIST SP 800-63B-4, "Digital Identity Guidelines: Authentication and Authenticator Management" (July 2025) — pages.nist.gov (synced passkeys allowed at AAL2 but not AAL3, what counts as phishing-resistant, biometric matching on the device)
- Japan Securities Dealers Association, revision of the guideline on preventing unauthorized access in online trading (October 15, 2025, Japanese) — jsda.or.jp (PDF)
- Financial Services Agency of Japan, warning on unauthorized access and trading in online brokerage services (Japanese) — fsa.go.jp
- passkeys.dev (guidance for developers implementing passkeys) — passkeys.dev
Read next
- Learn: how to choose a password manager (it also handles storing/syncing passkeys)
- Two-step: choosing MFA the right way (what phishing resistance means) / setting up GitHub 2FA (adding a passkey as a backup)
- How it works: how to store passwords safely / Glossary: what phishing is
- Glossary: what 2FA is / what a one-time password (OTP) is (the methods passkeys are compared with)