If a website or application offers the option to create an access key, or passkey, it is generally worth activating it. The technology eliminates the password from that login flow and has an important advantage: it was designed to resist phishing, because the credential is linked to the website or application for which it was created.
This does not mean, however, that losing your cell phone has become irrelevant. The result depends on where the passkey was stored. Some are synchronized by a credential manager and can reappear on a new device; others are linked to a specific device. There is also a separate question: how the account itself allows you to regain access if all available passkeys are lost.
How a passkey works without you memorizing a secret
When creating a passkey, the device generates a pair of cryptographic keys. The public key is registered on the website or application. The private part is protected on the device or in the chosen credential manager. Upon login, the service sends a challenge, the device uses the private key to sign it, and the server verifies the response using the public key. The traditional password no longer needs to be sent to the service in this process.
To authorize the use of the passkey, you normally do something you already do to unlock the device: use your fingerprint, facial recognition, PIN, pattern or other local mechanism accepted by the platform. Biometrics are not sent to the website as part of the passkey; it serves to locally release the use of the credential.
This distinction is important. Your face or fingerprint is not the passkey. The passkey is the cryptographic credential stored and protected by the device or manager.
Why passkey is more resistant to phishing
A password can be entered both on the real website and on a convincing fake page. The same problem exists with single-use codes: if the victim enters an OTP on a page controlled by the scammer, that code can be retransmitted while it is still valid.
NIST, in its most recent revision of authentication guidelines, published in July 2025, states that mechanisms that require manual OTP entry are not considered phishing-resistant. WebAuthn, the standard used in the FIDO2 credentials that underlie passkeys, cryptographically links authentication to the service domain.
In practice, this means that a passkey created for a legitimate domain is not simply handed over to a visual copy of that site hosted on another domain. Verification is done by the browser and the system, rather than just relying on you realizing the page is fake.
Protection, however, does not cover every type of attack. Malware on the device, theft of an already authenticated session, compromise of the recovery mechanism, and a device unlocked by someone else are different problems. NIST itself draws attention to authenticator recovery as a potential weakness, especially when less secure backup methods or human-assisted processes come into play.
Passkey, password and 2FA are not exactly competitors
“Passkey or two-factor authentication?” may lead to an incomplete comparison. 2FA describes the use of authentication factors; it is not a single type of credential.
| Method | What do you present | Phishing resistance | Point of attention |
|---|---|---|---|
| Password | A secret you know and type | No | Can be reused, stolen or entered on a fake website |
| Password + OTP code | Password and temporary code | No for traditional relay phishing | It's better than relying solely on the password, but the code can still be requested by a fake page |
| Passkey with local verification | Device with key + local unlock when required | Yes, when implemented according to WebAuthn/FIDO | You need to plan for synchronization, backup device and recovery |
FIDO explains that a passkey can combine device ownership with a local verification, such as PIN or biometrics, when the service requests this verification. Therefore, in certain flows it can replace not only the password, but also traditional combinations such as password plus OTP.
This does not make all 2FA inferior. Cryptographic authenticators, such as certain FIDO physical keys, can also provide resistance to phishing. The problem is treating “2FA” as a synonym for just a code via SMS or an authenticator app.
Where the passkey is stored
There are two situations that the user needs to distinguish.
Synchronized Passkeys are under the responsibility of a credential provider capable of making them available on other authorized devices. The FIDO Alliance cites systems-integrated managers and third-party managers as examples. Google, Apple and Microsoft also document synchronization mechanisms in their ecosystems.
Device-bound Passkeys, or device-bound, remain on that device or authenticator. If there is no other passkey or recovery method, losing the device could mean losing that specific credential. Microsoft, for example, recommends having another passkey available when the credential is kept only locally.
Therefore, before tapping “Create passkey”, it is useful to note where the system informs you that it will be saved: on the device, in the Apple, Google or Microsoft manager, in a third-party manager or in a physical security key.
I lost my cell phone. Did I lose my accounts?
Not necessarily.
If the passkey is synchronized and you can regain access to the respective credential provider on another device, it may become available again. Google documents passkeys encrypted and synchronized by its manager; Apple syncs passwords and passkeys through iCloud Keychain; and Microsoft now offers synchronization via supported credential managers.
In the Apple ecosystem, the documentation also provides for recovery of iCloud Keychain even when all devices have been lost or stolen. Depending on your Apple Account setup, the process may involve a recovery contact or the protected iCloud Keychain recovery mechanism, as well as account authentication, trusted phone number, and device passcode.
If, on the other hand, the only passkey was linked exclusively to the lost cell phone and there is no other credential or a usable recovery process, you may be left without that form of access. Recovery then depends on the rules of the service itself.
There is also a security measure after a robbery. Services may allow the lost credential or device to be removed from the account. With a Google Account, for example, the documentation itself advises you to remove the access key associated with a lost or stolen device using another device that you can still log into.
What to do before activating passkeys on the most important accounts
The decision does not need to be between “continue with a password” and “bet everything on a cell phone”. A safer configuration is to reduce dependence on a single device.
- Find out where the passkey will be stored. Prefer to know if it will be synchronized or will just stay on the device.
- Review account recovery. Check email, phone number, recovery contacts, recovery codes or other methods actually offered by the service. The exact mechanism varies from one account to another.
- Have a second form of access when the account is critical. This could mean another passkey, another authorized device or a physical security key, depending on the service options.
- Protect the screen lock well. Anyone who can unlock a device on which there is a passkey may, depending on the service and configuration, be able to use it. Google explicitly warns to only create passkeys on your own devices and advises not to create them on shared devices.
The most important point is to avoid creating a dependency that you are unaware of. Knowing where the credential is and how your account is recovered is worth as much as activating the technology.
What if I change my cell phone?
If you use synchronized passkeys, the switch tends to be simpler: after configuring the new device and regaining access to the same credential provider, the compatible keys may become available again. This is precisely one of the objectives of synchronized passkeys.
The concrete experience varies depending on the operating system, the chosen manager and the service. In corporate or school environments, administrators can also limit where passkeys can be stored or how they are used.
If the passkey was exclusively local, the strategy changes: create another credential on the new device before deleting or handing over the old one, as long as the service allows it. If this is not possible, first confirm which alternative login or recovery method is available.
Can you use the passkey on a computer that isn't yours?
Yes, without necessarily saving the passkey on that computer.
FIDO standards enable cross-device authentication. In a common flow, the computer shows a QR code, the nearby cell phone reads it and you authorize login on the phone itself. There is a proximity check between the devices; FIDO and manufacturers document the use of Bluetooth in this process.
This is the preferred path on a public, borrowed or shared computer: use the passkey that is already on your device, instead of creating a new permanent credential on someone else's computer. Google's documentation expressly advises not to create passkeys on shared devices.
As with any access made to a third-party computer, the passkey does not eliminate risks existing on the equipment itself or in a session that remains open. When finished, close the session and avoid keeping the account logged in.
So, is it worth activating?
For most people who already use a cell phone and computer protected by a screen lock, passkey is a useful evolution in relation to password-only login and also reduces an important weakness of combinations such as password plus OTP code: credential phishing.
The best adoption is not to simply press “activate” on every account. Start with the important accounts that support it, check which manager the passkey will be stored in, and review the recovery before abandoning methods that may still be necessary.
If the passkey is synchronized, losing a cell phone does not automatically mean losing the credential. If it is linked to the device, treat another passkey or recovery method as a spare key. And, in any case, remember that access security also depends on protecting the device and the provider that stores your credentials.
