Passkey Saved but Login Still Fails: What's Actually Wrong

Your device is certain it holds a passkey for this site. The site behaves as though it has never heard of you. Both can be true at once, and the fix is knowing which side is out of step.

A saved credential is not a registered one

Two separate records are involved: a credential on your side, made of a private key that stays with you and the public key from the same pair, and an entry on the site tying that public key to your account.

Saving creates the first. Registration finishes only when the site has stored the second. If that last step failed — the request timed out, the tab closed early, you were signed into an account you did not expect — you hold a credential the site has no record of, and both outcomes look identical from the outside.

The check: sign in by whatever means you still have, open the account's security settings, and read the registered passkey list. If your device has one and that list is empty, your copy is orphaned. Remove it and register again from inside the account — safe only because you have a working way in.

Wrong browser profile, or a different browser

Profiles are separate storage compartments, and a passkey created in one is often invisible in another. The same holds across browsers: unless the credential lives in a keychain or manager that syncs independently of the browser, a passkey made in one browser will not appear in a second.

The check: sign in with the exact browser and profile you used when you created it, then compare the passkey lists. If the entry appears under only one, you have found the mismatch rather than a fault.

The account has two entries and the site expects the other one

This is more common than people expect, and it is the classic "but I saved it" case. Duplicate accounts accumulate easily: a personal address and a work address, an old alias that still forwards, or a password login alongside a single-sign-on login.

During sign-in the site sends a challenge listing the credential identifiers it knows for the account, and your browser can only offer a passkey whose identifier is on that list. If yours was registered against an account you no longer use, the site will never ask for it, and nothing on your device will look wrong.

The check: compare the username you type with the username on the passkey entry in your device's list, then open the passkey list inside each account you hold on that site. Sign into the one that lists a passkey.

Sync has not finished yet

If your passkey syncs through a platform keychain or a password manager, a second device has it only once replication completes. Creating a passkey on a phone and trying the laptop straight away is a normal way to see this fail.

The check: sign in on the device where you created the passkey. If that works, the credential is fine and the question is propagation. Confirm the second device is signed into the same sync account, then re-check the passkey list.

Clock and time skew

A passkey sign-in is a short-lived exchange: the site issues a challenge, your device signs it, the site verifies it promptly. A device whose clock is badly wrong can fail to complete that exchange, usually with an unspecific error.

The check: open date and time settings on the failing device and confirm the clock is set automatically rather than by hand. Do this after the identity checks above — an account mismatch is far more common than a wrong clock.

The site still wants a second factor

Some sites accept a passkey as one factor and still want a second: your password, a code from an authenticator app, or a code by email. If the passkey prompt succeeds and you are then asked for something else, that is design, not breakage.

The check: read that second screen before retrying anything. If it wants a code, confirm the entry for the site still exists in your authenticator app — people delete it after adding a passkey and then get stuck at exactly this step. See backup and recovery for keeping that path intact.

Quick reference

What you see	What it usually means	What to check
Passkey on the device, but no passkey option on the site	The site has no credential registered for the account you are using	That account's passkey list
The site prompts, but your passkey is not offered	You are in a different profile or browser than the one that registered it	The passkey list in each browser profile
Prompt appears and immediately fails	Credential mismatch — the passkey belongs to another account on that site	The username on the passkey entry versus the one you typed
Works where it was created, not elsewhere	Sync has not propagated, or the passkey is device-bound	Your manager's notes on which passkeys sync
Passkey accepted, then a code is requested	The site uses a second factor by design	Whether your authenticator app still has the site

When to stop and fall back to password plus recovery

Switch routes when one of these is true.

1. You can still sign in by password, hardware key, or code. Use it now, while you can, then fix the passkey from inside the account.
2. Someone has suggested clearing browser data or deleting the passkey. Sign in another way first: deleting the last working credential can turn a puzzle into a lockout.
3. You no longer have the device, the key, or the password. Go to the site's account recovery flow directly; that sequence is in passkey lost phone.

Once you are back in: confirm the passkey list matches what you hold, register a second passkey on another device or a hardware key, and note how you would get back in without the first device. If you would rather software managed that, see password managers with passkey recovery and our comparison of password managers for passkeys. Still deciding whether a passkey should be first? Read passkey versus password manager first, or start from the troubleshooting index.

Last updated: 2026-10-16