What Are Passkeys? How They Work, Where They Live, and How You Unlock Them

A passkey lets you sign in with a digital key created for a particular service, instead of typing a password. Once you register a passkey with a supported website or app, you can authorize its use with a device PIN, fingerprint, face recognition, or another supported unlock method.

For example, you might sign in to a shopping website by looking at your phone. Your phone is not sending a picture of your face to the retailer. Face recognition simply authorizes the phone to use a stored key.

Three separate ideas help explain what is happening:

Element	Purpose	Example
Passkey	A key for signing in to a service	A passkey for a shopping website
PIN, fingerprint, or face recognition	Local verification that authorizes use of the key	Your phone’s screen lock or Windows Hello
Storage provider	Keeps and manages the key	A device, security key, or password manager

How is a passkey different from a password?

With a password, you send a secret string for a service to check. If you enter it on a phishing website, an attacker can try using it on the real website.

With a passkey, your device proves that it holds a private key without giving that key to the service.

Comparison	Password	Passkey
Sign-in credential	A string you remember or fill with a password manager	A cryptographic key created for a service
What the service checks	The submitted password, usually against a stored hash	A signature, using a registered public key
What you remember	The password, unless a manager handles it	You do not memorize the passkey; you still need to unlock its device or manager
Phishing resistance	A fake website can steal what you enter	A passkey is scoped to the legitimate service and cannot be used by an unrelated fake domain
Reuse	People can reuse the same string across services	Different services get different keys

Passkeys use FIDO standards. In a web browser, the main interface is called WebAuthn. They are not a proprietary sign-in feature belonging to a single vendor. See the FIDO Alliance’s introduction for the basic concepts.

A passkey uses a pair of related cryptographic keys:

Public key: registered with the service, which uses it to check your proof.
Private key: managed by your device, security key, or password manager, which uses it to create that proof.

The pair is created during registration. At sign-in:

The service sends a fresh, random challenge.
You authorize use of the key with a PIN, fingerprint, face recognition, or another supported method.
Your authenticator uses the private key to sign the challenge and associated information.
The service checks the signature with the registered public key and allows you to sign in.

Think of the signature as proof that you hold the key, rather than a copy of the key. Checking a fresh challenge prevents an old response from simply being replayed.

The browser and service also enforce checks involving the legitimate website’s identity. A lookalike website on an unrelated domain cannot use the real website’s passkey. This is the basis of its phishing resistance. MDN’s WebAuthn documentation explains the protocol in more detail.

A PIN, fingerprint, or face scan is not the passkey

The passkey is the key. Your unlock method authorizes its use.

Unlock method	What it verifies	What goes to the website
PIN	Knowledge of a code set for the device, authenticator, or manager	A signed response, not the PIN itself
Fingerprint	A match against an enrolled fingerprint	A signed response, not your fingerprint data
Face recognition	A match against an enrolled face	A signed response, not your face data

Your fingerprint does not become a website password. Depending on the device and provider, a PIN may be available when biometrics cannot be used.

A device PIN is checked locally, typically with protections such as attempt limits. That makes its role different from a password sent to a website. It still needs to remain private: someone who steals your device and knows its PIN may be able to use your passkeys.

Also, seeing a Windows Hello prompt does not tell you where the passkey lives. Windows Hello can authorize access to a password manager as well as a key stored directly on the PC. The unlock method and the storage location are separate choices.

Why are passkeys useful?

Resistance to phishing: binding authentication to the legitimate service helps defeat fake sign-in websites that steal passwords or verification codes.
Less typing and memorization: you can use a familiar device unlock method instead of entering a website password.
No password reuse: a key created for one service does not sign you in to another service.
No sign-in private key stored by the website: stealing the public key alone does not let an attacker generate your signatures.

Passkeys primarily protect authentication. They do not prevent every threat, such as malware on your device, theft of an existing signed-in session, or vulnerabilities in a service.

Where does a passkey live?

When creating a passkey, pay attention to where you save it, as well as which account it belongs to. There are two main storage models.

Device-bound passkeys

A device-bound passkey keeps its private key on a particular device or authenticator. It is not copied or synced to other devices.

Example	Where the key lives	What that means
A passkey saved directly to Windows Hello	The individual Windows PC	It does not automatically sync to another PC; loss or OS reinstallation requires another way into the account
A FIDO2-capable YubiKey or similar security key	The physical security key	You can use it with compatible computers or phones while the private key remains on the security key

“Device-bound” describes where the private key stays, not which computer you are allowed to use. Plugging a YubiKey into another computer does not copy the key to that computer. A spare security key normally needs its own registration with each service. See Yubico’s passkey FAQ.

Synced passkeys

Synced passkeys use encrypted synchronization to make credentials available on multiple devices. This can make replacing a phone or computer easier, but protecting and recovering the sync account or vault becomes essential.

Example	Sync account or system	What to understand
Microsoft Password Manager	Microsoft account	Syncs in supported Edge and Windows environments; separate from saving directly to Windows Hello
Google Password Manager	Google Account	Available in supported Chrome and Android environments; a manager PIN or other verification may be needed on a new device
Apple Passwords	Apple Account and iCloud Keychain	Uses iCloud Keychain to sync between supported devices
1Password	1Password account and vault	Stores and uses passkeys through supported integrations such as its browser extension
Bitwarden	Bitwarden vault	Stores and uses passkeys through supported browser extensions and mobile apps
LastPass	LastPass vault	Stores and uses passkeys through supported browser extensions and mobile apps

Support varies by operating system, browser, product version, and plan. Signing in to the same account does not guarantee that every browser and device can use its passkeys.

The official guides explain Microsoft’s storage choices, Google’s sync and PIN requirements, and Apple’s iCloud Keychain setup. Provider documentation also covers passkey storage in 1Password, Bitwarden, and LastPass.

KeePassXC: a database you manage yourself

KeePassXC can store passkeys in an encrypted database file. It does not automatically sync them through a KeePassXC cloud account: you manage file synchronization and backups yourself.

Browser use requires the KeePassXC-Browser extension, a connected database, and passkey support enabled in the extension. See the official user guide.

Because the database can be copied or synchronized, this differs from a hardware key whose private key cannot be exported. Do not assume that every KeePass-compatible app can use the passkeys stored in that database.

What else do you need to understand?

Imagine securing the front door with a passkey while leaving a side door accessible with a weak password. An attacker can target the side door. Adding a passkey does not automatically make the entire account phishing-resistant.

Password sign-in, SMS or email recovery, and support-assisted resets also affect account security. Where a service permits it, remove weak alternatives. Where they must remain, strengthen them with unique, long passwords and appropriate multifactor authentication.

Keep a tested recovery option before removing existing methods. Another passkey or securely stored recovery codes can help prevent losing access yourself.

Your browser must be able to reach the storage provider

A passkey may exist but fail to appear if your current browser or operating system cannot access its provider.

For example, a passkey in Bitwarden does not automatically appear in Windows Hello’s stored credentials. You generally access it through a supported extension or an operating system’s passkey provider integration. Browser sign-in, sync settings, extension permissions, or unlocking the vault may be necessary, depending on the provider.

When several managers are installed, also check which one the creation dialog offers to save to. The browser displaying a passkey prompt is not necessarily where the key is stored.

Loss and migration depend on storage

A passkey stored only on a lost device becomes unavailable. A synced passkey can also become unavailable if you cannot recover its sync account or unlock its vault. Avoid keeping every recovery method exclusively inside the very vault you might need to recover.

Changing providers may require more than copying a password-like string. Check migration support; if transfer is unavailable, register another passkey with the new provider while you can still sign in.

Separate the authentication standard from provider choices

Passkeys follow shared standards, while synchronization, recovery, and migration depend on the provider. Understanding compatibility and exit options helps you choose where to keep them.

Dependence on one operating system or vendor is not inherent to every passkey. Security keys and independent password managers are also options. However, an organization may restrict which authenticators can be registered, including through attestation: evidence about the authenticator used to create a credential.

The supplied GIGAZINE article about passkey lock-in concerns (Japanese) presents concerns and counterarguments about such restrictions. It helps to distinguish the authentication mechanism from a provider’s or service’s policies.

The starting point is simple: a service-specific key lives in a storage provider, and a PIN or biometric check authorizes its use. Understanding that relationship makes both the convenience of passkeys and the importance of storage and recovery easier to see.