Password security guide
Password vs Passkey
Passwords are shared secrets that can be copied. Passkeys use public-key credentials bound to the legitimate service origin, reducing phishing and reuse risk.
How passwords and passkeys differ
| Property | Password | Passkey |
|---|---|---|
| Server stores | Password verifier, usually a salted hash | Public key and credential metadata |
| User presents | Shared secret | Signature created by a private key |
| Phishing | Can be entered on the wrong site | Bound to the registered site origin |
| Reuse | User can reuse the same value | Unique credential per service |
| Recovery | Service reset process | Credential provider sync, another passkey or service recovery |
How a passkey sign-in works
The device or credential manager creates a public and private key pair for the service. The service stores the public key. During sign-in it sends a challenge, and the authenticator signs it after local user verification such as a device PIN, fingerprint or face check. The private key is not sent to the website.
WebAuthn binds the ceremony to the relying-party identifier and origin, which is why a lookalike phishing domain cannot request a valid signature for the real site.
Why passkeys resist common password attacks
There is no password to guess, reuse or submit through credential stuffing. A breached service database does not contain the private keys needed to sign in. Origin binding makes conventional phishing substantially harder.
Passkeys do not protect an already unlocked hostile device, a compromised account recovery channel or every form of social engineering.
Synced and device-bound passkeys
Some passkeys sync through a credential manager so they are available across a user’s devices. Others live on a physical security key or specific device. Sync improves usability and recovery; device-bound credentials can provide stronger hardware and organizational control.
Understand where credentials are stored, how the provider account is protected and how you will sign in after losing a device.
Privacy and account-linking considerations
Passkey protocols are designed so services receive public-key credentials, not biometric data. Biometrics are normally processed locally by the device. A synced credential provider may know account and synchronization metadata according to its architecture and policy.
Use official platform documentation to evaluate sync, export, sharing and recovery behavior.
Recovery is part of passkey security
Enroll more than one safe sign-in or recovery method before removing a password. For important accounts, consider a second device or hardware key where supported. Protect the email, phone and provider account used for recovery.
A passkey can improve daily sign-in while a weak recovery flow remains the easiest route for an attacker.
Should you remove the password?
Some services permit fully passwordless accounts; others retain a password as fallback. Remove it only after confirming passkey access on the devices you need and recording the recovery process. A dormant weak password can remain an attack path if the service still accepts it.
When passwords remain necessary
Passkey support is not universal, and organizational or legacy systems may still require passwords. Continue using unique generated values and MFA. Migration is not all or nothing: adopt passkeys on high-value supported accounts while maintaining sound password practices elsewhere.
Passkey adoption checklist
- Create the passkey from the official account settings.
- Verify the credential provider and target domain.
- Test sign-in on another authorized device.
- Add a backup credential or documented recovery method.
- Remove obsolete devices and sign-in methods.
- Protect the provider account and device screen lock.
Passkeys as an MFA method
A passkey may provide multifactor authentication when possession of the credential is combined with local user verification. Services can implement passkeys differently and may retain another recovery path. Compare authenticators, backup codes and phishing resistance in the two-factor authentication guide.
Cross-device sign-in and QR flows
A passkey on a nearby phone can sometimes authorize sign-in on another device through a QR and proximity flow. Read the prompt carefully and verify the destination domain. Bluetooth may be used to establish proximity, not to send the private key to the other device.
On a public or borrowed computer, avoid saving a new credential to that machine. Use the nearby-device option and sign out completely afterward.
A gradual migration plan
- Start with a high-value service that supports passkeys and clear recovery.
- Create the credential on a trusted provider or hardware key.
- Test another authorized device.
- Add a backup method.
- Review the account credential list.
- Remove a weak password only if the service and recovery plan make that safe.
What happens during registration and authentication?
During registration, the authenticator creates a key pair and the service associates the public key with the account. During authentication, the browser and authenticator verify the relying party and sign a fresh challenge. The signature proves control of the private key without revealing it.
User verification such as a device PIN or biometric unlocks use of the credential locally. The service does not normally receive the biometric template. This distinction is important when evaluating privacy claims.
Passkey provider security
A synced passkey depends on the credential-provider account, device enrollment and recovery process. Protect that account with strong authentication and review its connected devices. Understand whether credentials can be exported or shared, how end-to-end encryption works and what happens after losing every device.
A hardware security key can reduce provider dependence, but it creates physical backup and inventory responsibilities. Important accounts should have more than one authorized route.