Passkeys Replace Passwords, but They Do Not Eliminate Recovery and Backups
Cryptography reduces phishing and credential reuse, while synchronization, device replacement, and recovery still require attention.
R42 / SUMMARY
Passkeys replace passwords with cryptographic pairs unique to each account and service. The private key remains on a device, in a credential manager, or on a physical key, while the server stores only the public key. This reduces phishing and reuse, but account recovery, synchronization, and device security remain essential.
KEY POINTS
- Each passkey uses a cryptographic pair unique to one account and domain.
- Biometrics or a PIN unlock the credential locally and are not sent to the service.
- Domain binding prevents the correct credential from being used on a fake page.
- Synced passkeys simplify recovery; physical keys reduce cloud dependence.
- Backup and recovery methods still need to be configured and tested.
Passkeys replace a typed password with a cryptographic credential bound to a website or application. To sign in, a person unlocks a device with a fingerprint, face recognition, or PIN; the service receives a mathematical proof, not biometric data or a reusable secret. The experience looks like a shorter login, but the important change happens beneath the interface: there is no word that can be copied, reused, or surrendered to a fake page.
That does not make every account using a passkey invulnerable. Account recovery, device security, synchronization, and fallback methods still matter. Understanding that division makes it easier to use the technology without confusing convenience with absolute protection.
What happens when a passkey is created
According to the FIDO Alliance technical explanation, a credential manager or security key creates a cryptographic pair unique to that account and service. The public key is registered with the server. The private key remains in the manager, on the device, or on the chosen hardware. During sign-in, the server sends a random challenge; the private key signs it after the user authorizes the operation locally, and the server verifies the signature with the public key.
A fingerprint or face scan does not travel to the website. It works as a local way to release the credential, just like the device PIN. FIDO emphasizes that the service sees public keys and signatures, not the biometric method used. Nor is there one universal passkey presented to every company: each domain and account combination receives its own pair.
Why phishing becomes harder
Passwords depend on a person recognizing where they are typing. A convincing fake page can capture the text and reuse it on the real site. Passkeys are associated with the domain for which they were created. If the address does not match, the authenticator does not offer the correct credential. NIST guidance on syncable authenticators identifies this domain constraint as the basis of phishing resistance.
The advantage also appears after a server breach. A service stores the public key, which verifies signatures but cannot generate the private key. This removes the direct equivalent of a password database that can be tested or cracked to expose reusable credentials. The benefit still depends on correct implementation and on the account not retaining one weaker fallback as its only recovery route.
Synced and hardware-bound passkeys
A synced passkey is protected and distributed by a credential manager to other devices connected to the same account. This makes it easier to replace a phone or move between a computer and a handset. A device-bound credential, such as one stored on a particular physical security key, is not copied to the cloud; the hardware must be connected or brought near another device when it is used.
Neither model is universally superior. Synchronization favors availability and routine recovery. Dedicated hardware reduces reliance on a cloud account but creates a need to store a backup key. NIST notes that recovery processes for the synchronization service can become a risk point. Final security therefore includes more than passkey cryptography: it also depends on how new devices are admitted and how a lost account is restored.
What to check before leaving passwords behind
First, identify where the credential will be saved: the system manager, an independent application, or a physical key. Second, register more than one passkey when the service permits it, especially when one remains on hardware. Third, review and test recovery methods before removing the old sign-in option. Fourth, keep the screen lock and software updates enabled, because unlocking the device also authorizes access to stored credentials.
Google’s account guide for passkeys confirms that a fingerprint, face scan, or PIN demonstrates access to the device and recommends keeping recovery information current. On shared devices, a passkey should not be created in a profile another person can unlock, because the credential represents possession and local authorization of that environment.
Security is also an interface problem
Adoption depends on screens that explain where a credential was saved, how to remove it, and what happens when a device changes. Rota42’s analysis of dark patterns and digital choices helps reveal the inverse risk: simplifying enrollment without making recovery and deletion equally clear replaces a difficult password with an opaque journey.
Passkeys solve one specific and important problem: a secret that can be typed, reused, and easily phished. They do not replace backups, recovery, or device protection. The best transition happens when someone knows which manager controls the keys, has a tested alternative, and understands that biometrics are only the local unlock mechanism — not the credential sent to the service.
Gabriel Silva
Responsible for reporting and writing this story at Rota42.