What a passkey protects—and what it does not
A passkey is a cryptographic credential that uses a key pair: the service keeps the public key, while the device or credential provider stores the private key. When you sign in, the device answers a challenge from the service without sending it the private key. Because the credential is associated with the site or app for which it was created, it can help resist phishing: a fake page should not be able to reuse the response as if it were the legitimate page. This does not mean a passkey eliminates every account risk. Access to the device, the account that manages synchronization, and recovery mechanisms still matter. (Google Developers)
That is why it helps to separate two questions when comparing options: how the account authenticates you and how you recover the credential or account if you lose access. A passkey can reduce exposure to fake pages and reused passwords, but it does not, by itself, guarantee that nobody can recover the account through another route. The experience also depends on the options each service provides, such as a second authenticator or recovery codes. Recovery is not an administrative detail to leave until later: it is part of the security model you will actually use. Consider both ordinary sign-in and the less frequent situation in which a device is lost, replaced, or no longer available. A strong sign-in method is only one part of the picture if the account’s recovery route remains unclear or depends on something you cannot reach.
Synced or device-bound
A synced passkey can be available on more than one device through a service that manages and synchronizes credentials. This can make it easier to switch phones or sign in from another compatible computer. It also introduces an additional dependency: access to the credential may depend on the protection and recovery of the account that controls synchronization. The U.S. National Institute of Standards and Technology (NIST) defines these credentials as syncable authenticators and treats synchronization as the copying of keys to other devices, typically through a cloud service. (NIST)
A device-bound passkey—or one stored on a security key—is not automatically replicated as part of cloud synchronization. That may limit where it is available, and losing the device or making it unusable could leave you without that credential. In return, non-exportable keys have a relevant property in environments with high assurance requirements: NIST notes that non-exportable keys are required for assurance level AAL3, whereas syncable keys are exportable and do not meet that non-exportability requirement. Do not turn this standards distinction into a universal classification of “secure” and “insecure”: the needs of a personal account and those of a regulated system are not necessarily the same. Each option has practical trade-offs, and the right choice depends on the requirements that apply to your account and on the recovery arrangements you can maintain. (NIST)
Compare the backup system, not just the key type
Before choosing, identify who stores the passkey, which account controls synchronization, and what steps the provider requires to restore access. Check whether you can see which services have registered credentials and which devices they have been synchronized to: NIST says syncable authenticators should provide an interface for reviewing this information without revealing the private key. That visibility can help you identify devices you no longer use or understand why a passkey appears on a particular device. Do not assume that every provider displays the information in the same way or that the same credential can be moved freely between managers. Review what you can actually inspect in the provider’s settings rather than relying on a general description of how passkeys work. (NIST)
Compatibility matters just as much as protection. If you switch between operating systems, browsers, or work and personal devices, check in advance where you can use the passkey and what happens if the primary manager is unavailable. For a physical key, check which connection method each device accepts and whether the service lets you register more than one key. For synced credentials, check how the provider account is protected, how it can be recovered, and whether that process is available from another device. These are checks to make in the service documentation: specific features can change, so do not take them for granted just because a service uses the word “passkey.” A convenient arrangement on one device may not offer the same experience across your other devices, so verify the combinations you expect to use.
Choose for your situation and your tolerance for loss
If you mainly use devices in one ecosystem and value being able to restore credentials on another device, a synced option may be practical, provided you are willing to protect the account that manages it. Review its recovery method and enable the protections available for that account; a passkey stored there will not solve the problem if you cannot get back into the system that synchronizes it. Apple, for example, documents synchronization and recovery as separate iCloud Keychain functions. That illustrates why it is useful to read how your chosen provider operates rather than assume that all providers work the same way. Think about whether you can still reach the provider account if your usual phone is unavailable, and whether you understand the steps required to restore access. (Apple Support)
If you use multiple systems or need to reduce dependence on a single cloud account, compare a compatible credential manager, credential options supported by your devices, and a physical security key. A key does not automatically replace every other way of signing in: you will need to keep it safe, carry it when needed, and check what happens if it is lost. For especially important accounts, separating backups can reduce the risk that losing one device leaves you without access, although the solution must fit what the service supports. A sensible choice depends on the whole arrangement: provider security, everyday availability, compatibility, and a recovery plan you can carry out. Before settling on an approach, consider which parts rely on the same device or account; having several methods is not necessarily helpful if they all fail together.
Set up recovery before you depend on it
Start by adding a second passkey or an alternative method allowed by the service, preferably on a device or medium that does not depend on the same single point of failure. If you choose a physical key, register a second key and store it in a secure place separate from the one you carry. If the service offers recovery codes, keep them outside the account they unlock and avoid storing them only on the device whose loss you are trying to protect against. NIST includes recovery codes among the secrets that can allow an account to be recovered, but the specific option and its conditions depend on the service. You should therefore check how the service issues, stores, and accepts those codes rather than assuming that all recovery-code processes are identical. (NIST)
Next, test the plan while you still have ordinary access: confirm that the second method appears in settings and that you know where to find a code or how to use the other key. Do not remove the primary passkey until you have confirmed that the alternative works. Also secure the email account and credential-provider accounts, because they may be involved in recovery processes. Avoid keeping the only copy of codes inside the same manager or on the same device that could become inaccessible. These steps do not make the account invulnerable; they reduce the chance of confusing everyday access with the actual ability to recover it. A method that has not been checked is only a possibility, not a dependable backup. Make sure you understand the sequence you would follow if your main device were unavailable, while you still have the time and access to verify it.
Checklist for important accounts
Start with an inventory: which accounts already use passkeys, where those passkeys are stored, and what alternatives each service offers. For each important account, note whether the credential is synced or device-bound, which account manages its storage, and how you would recover access if you lost your phone today. Check whether there is a secondary sign-in method and whether the service imposes a waiting period or an additional verification step. If an option is unclear in the documentation, ask the provider before relying on it: the recovery procedure is specific to each account, not a uniform property of passkeys. It can be useful to keep the relevant details somewhere you can reach without relying on the device or account that you may need to recover. (NIST)
The practical rule is to choose a combination you can maintain and recover, rather than accumulating methods without knowing which one works. A synced passkey can provide continuity across devices; a credential bound to a key or device may be useful when avoiding key export is necessary. Neither removes the need to plan for recovery. From time to time, review registered devices, replace credentials associated with equipment you no longer control, and confirm that your backups remain available. The best choice is the one that meets your account’s requirements and whose emergency procedure you have tested—not the one that sounds most advanced in the abstract. Include recovery in your regular account review, since a backup that is no longer accessible or compatible may not help when you need it.