What is the difference between a passkey and a password?

A password is a shared secret you type, which can be guessed, reused or phished; a passkey is a private key that stays on your device and signs a one-time challenge only for the registered site. The NCSC said in April 2026 that passkeys are at least as secure as, and generally more secure than, the strongest password plus two-step verification.

What happens to my passkeys if I lose my phone?

If the passkeys were synced and another device is signed in to the same credential provider, they remain usable there, and you can remove the passkey tied to the lost device as Google's 2-Step Verification help advises. If the phone held your only credential, access depends on the other methods that service has registered, with no guaranteed restoration.

What is the difference between synced and device-bound passkeys?

A synced passkey is copied through your credential provider to devices signed in to it, while a device-bound passkey stays on one authenticator such as a hardware security key and never syncs. Shopify's documentation shows both: a passkey marked synced across devices works on phone and computer, while a phone-only passkey can still sign you in on a computer by using a passkey from another device.

Does adding a passkey remove two-step verification requirements?

Not universally. Google states a passkey bypasses the second step at sign-in without changing or removing existing authentication or recovery factors, while Shopify's help pages still require two-step authentication activated to accept payments with Shopify Payments and for Shopify Balance eligibility.

Does a passkey stop fraudulent charges on my saved card?

No. A passkey protects the sign-in step, not the payment authorisation, and it cannot stop malware, a hijacked session or a scam that persuades you to approve something yourself.

What Is a Passkey? Sign-In, Lost Phones and Recovery

A passkey is a sign-in credential built from two mathematically linked cryptographic keys: a private key that stays inside your device or password manager, and a public key stored by the website or app where you registered it. Instead of typing a shared secret, you approve the sign-in the same way you unlock the device — fingerprint, face, PIN or screen lock — and the device signs a one-time challenge from that exact site, which is why a passkey cannot be typed into a lookalike phishing page. The FIDO Alliance, which defines the standards behind passkeys, describes passkey sign-in as built on the FIDO2 specifications (WebAuthn and CTAP) and treats "passkey" as a general-use term, not one company's feature.

Quick answer

A passkey replaces a password: the private key never leaves your device or credential provider, and the site only ever stores the public key.
Your fingerprint or face is used locally to unlock the key. Google's help page states biometric data used for fingerprint or face unlock stays on your device and is never shared with Google.
Synced passkeys follow your credential provider account to new devices; device-bound passkeys on a security key do not sync, so a lost sole key means falling back to another registered method.
Recovery depends on the service and the methods you configured beforehand; there is no universal passkey reset and no guaranteed restoration.
Adding a passkey does not always cancel a separate two-step requirement: Shopify's Help Center still states that using Shopify Payments to accept payments requires two-step authentication activated on the account.

How a passkey actually works at sign-in

When you create a passkey for an online store, your device generates a key pair. The public key goes to that store's server; the private key stays with your authenticator — the phone, your operating system's password manager, a third-party password manager or a hardware security key. At sign-in the site sends a random challenge, your device asks you to unlock it, and the private key signs that challenge. The site checks the signature against the public key it already holds. Three properties follow:

Nothing reusable is transmitted. The signature is valid only for that one challenge, so a stolen copy from a server breach or a network intercept is not a usable login.
The credential is bound to the site. The browser will only offer the passkey registered for the legitimate domain, so a convincing fake checkout page cannot harvest it.
Your biometric is a local unlock, not a transmitted secret. The FIDO Alliance describes the user approving sign-in with the same biometric, PIN or on-device password used to unlock the phone, computer or security key. The face or fingerprint template is checked by the device; it is not sent to the merchant.

The UK's National Cyber Security Centre now treats this as the default. In its April 2026 CYBERUK guidance the NCSC said it will recommend passkeys wherever a service supports them, and two-step verification (2SV) where it does not, and its technical report concluded that passkeys are at least as secure as, and generally more secure than, the strongest password paired with 2SV.

Passkey vs password, synced passkey vs security key

The table compares three sign-in setups on the points that matter when protecting a payment, shopping or merchant account. Supported devices and options vary by service.

Point of comparison	Synced passkey	Device-bound passkey on a security key	Password plus verification code
Where the secret lives	Private key in your credential provider, synced to devices signed in to that provider	Private key generated on and locked to the hardware key; it does not sync	A shared secret you know, plus a code from an app, SMS or email
What signing in requires	An unlocked device with the passkey available, or a nearby phone holding it	Physical possession of the key, plus its PIN or touch	Typing the password and the code into whatever page asked for them
Resistance to phishing pages	High: the browser only offers the credential to the registered domain	High: same domain binding, with the key never leaving the hardware	Low: password and code can both be relayed to the real site by an attacker's page
If the device is lost	Other devices signed in to the same provider still have the passkey	No copy exists elsewhere; you need another registered method	The password still works; the second factor depends on what you registered
Main trade-off	Access depends on continued access to the credential-provider account	Register a spare key or a documented fallback	Reusable, guessable and phishable; code delivery can fail

Both types are passkeys under current FIDO terminology; the meaningful split is whether the credential syncs. Shopify's passkey documentation shows the distinction in its interface: a passkey labelled as synced across devices is available on a phone and a computer when you are signed in to the same password manager on each, while a passkey saved only on your phone can still be used to sign in on a computer by choosing to use a passkey from another device, with the passkey itself remaining on the phone.

What happens to your passkeys if you lose your phone

Three situations look similar to a locked-out user and behave very differently. In all three, what you can do is set by the service's own policy and by the methods you configured before the loss.

1. Lost phone, another usable device on the same credential provider

If the passkey was synced and you are still signed in to that provider on a laptop or tablet, the passkey is available there and sign-in continues normally. Google's help on 2-Step Verification problems tells users to remove the passkey associated with the lost or stolen device; that removal is about cutting off the missing hardware, not about recovering access, and you do it from a device you can still use.

2. Lost sole hardware security key

A device-bound passkey has no synced copy, so the account falls back to whatever else is registered. Google's guidance for signing in after losing a security key points users to their other second step or to account recovery, and its 2SV troubleshooting page notes that accounts with Advanced Protection are restricted to a backup security key. That is a Google-specific condition and does not describe how every bank, broker or payment platform treats a lost key.

3. Loss of access to the credential-provider account itself

If your synced passkeys live in an account you can no longer open, every passkey that depends on it becomes unavailable at once, and each service falls back to its own recovery process. Recovering the provider account and recovering each service are separate problems, which is why the inventory below asks whether a backup depends on the same provider.

Two constraints apply throughout. Do not delete a working recovery method to test a replacement: add the new method, confirm it works, then retire the old one. And no provider promises restoration or a decision time, so treat recovery pages as a route to try, not a guarantee.

Worked scenario: a lost phone and a merchant account

This is a hypothetical setup used to show how the pieces interact, not a test we ran.

Starting setup. Priya runs a small store. Her phone holds synced passkeys for her Google Account and her Shopify account in the same credential provider. She also has a laptop signed in to that provider, an authenticator app on the laptop registered with Shopify as two-step authentication, and a hardware security key registered with Google only. Her phone is stolen.

What still works. Because the laptop is signed in to the same credential provider, both passkeys are present there — the behaviour Shopify's documentation describes for a passkey marked as synced across devices. If a passkey is not offered during a Shopify sign-in, Shopify's troubleshooting page directs users to log in using a different method already set up on the account, which for Priya is the authenticator app.

What she does next. She signs in on the laptop, removes the passkey tied to the stolen phone from each account, and registers a passkey on the replacement phone. She keeps the hardware key registered with Google as a second route; Google's help page states that adding a passkey does not change or remove existing authentication or recovery factors on the account.

The remaining uncertainty. Priya's fallback for both accounts sits partly in one place: the credential provider and, for Shopify, an authenticator app on a single laptop. If the laptop failed in the same week, her Shopify route would depend on whatever other method she had registered and on Shopify's recovery process, with no guaranteed outcome. That single-point dependency is what the inventory is for.

Build an account-access inventory

For each money-related account, record where the passkey is stored, the second supported sign-in method, whether that backup depends on the same device or credential-provider account, and the service's official recovery page. The rows below are illustrative placeholders, not provider recommendations.

Service	Credential provider holding the passkey	Second supported sign-in method	Does the backup depend on the same device or provider account?	Official recovery page
Email or identity account	OS password manager on phone and laptop	Hardware security key kept at home	No — key is independent of the provider account	Provider's account recovery help page
Merchant admin (example: Shopify)	Same OS password manager	Authenticator app on laptop	Partly — app lives on one device	Provider's login troubleshooting page
Payments dashboard (example: Stripe)	Browser profile on laptop	Authenticator app or security key	Yes if both sit on the same laptop	Provider's two-step authentication support page
Shopping account with a stored card	Phone only, not synced	Password plus emailed code	Yes — recovery email may also be passkey-protected	Provider's help centre sign-in page

Fill it in on paper or in a file you control. It is a planning inventory of method names and dependencies only: never write passwords, recovery codes or PINs into it, never type them into a page that asks you to "check" them, and do not send a completed copy to anyone, including us. A printable companion is available at payney.com/downloads/passkey-recovery-checklist.pdf; it duplicates the structure above, so this article stands on its own.

Merchant and payment accounts: passkeys do not always replace two-step

Two Shopify pages have different scopes. Its secure sign-in methods page says a secure sign-in method may be required if your organisation's owner has enforced it or if you have access to financial products, that either a passkey or two-step authentication meets that requirement, and that setting up more than one gives you a backup. Its page on deactivating two-step authentication states separately that using Shopify Payments to accept payments requires two-step authentication activated, that payouts might be placed on hold without it, and that you cannot remove your last method when a secure sign-in method is required. Shopify Balance eligibility documentation also lists two-step authentication as a requirement.

Read together, those pages mean a passkey can satisfy the general secure sign-in requirement while a separate product-level two-step requirement still applies. Do not infer from one provider's wording that a passkey removes a two-step obligation elsewhere.

Stripe documents passkeys as a Dashboard sign-in method: its account checklist says Stripe supports passkeys, security keys, authenticator apps and SMS for two-step authentication, and its support pages describe passkey login to the Dashboard with a biometric, device PIN or hardware security key, usable as a two-step method too. Stripe's two-step authentication requirement page states that users having trouble can submit an account recovery form or have an account owner reset two-step authentication from the Team settings page. No timescale or outcome is promised there.

What phishing-resistant sign-in does not protect

A passkey defends the login step. It does not defend everything downstream:

Authorising a card payment is a different transaction. Signing in proves who is using an account; approving a card charge runs through the merchant checkout, card network and issuer. A passkey on the login page does not authenticate each payment, and a stored card can be charged by anyone inside an active session.
A compromised session survives a strong login. Malware, a hijacked session token or a support-desk social engineering call can act inside an account that was opened with a passkey.
Scams that persuade you to act are unaffected. A fake invoice, a refund scam or a "verify your payout account" message works through you, not through your credentials.
Blockchain wallet keys are a separate category. A passkey signs a challenge to prove identity to a service; a self-custody wallet's signing key authorises transfers of assets and no provider can restore it. Passkey syncing is not a model for how wallet keys behave.

Common mistakes to avoid

One passkey on one phone and no second method, so the phone becomes a single point of failure.
Synced passkeys held by a provider whose own recovery route is itself protected by a passkey in that provider.
Deleting a working authenticator or security key before confirming the replacement signs you in.
Assuming a passkey cancelled a product requirement such as Shopify Payments' two-step authentication.

The single next step

Open the security settings of the account whose loss would hurt most — usually the email or identity account every reset link flows through — and confirm it has a second sign-in method that does not depend on the device you carry every day. If it does not, add one, verify it works, then record it in your inventory.