Skip to content
R42 / Technology / 00010

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.

30.08.26 Gabriel Silva 4 MIN
WhatsApp X Facebook LinkedIn Telegram Email

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

  1. 01Each passkey uses a cryptographic pair unique to one account and domain.
  2. 02Biometrics or a PIN unlock the credential locally and are not sent to the service.
  3. 03Domain binding prevents the correct credential from being used on a fake page.
  4. 04Synced passkeys simplify recovery; physical keys reduce cloud dependence.
  5. 05Backup 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.

Written by

Gabriel Silva

Responsible for reporting and writing this story at Rota42.

Continue reading

View archive

We use necessary storage for operation and security. With your permission, we enable audience measurement, personalization and optional advertising features.

Necessary Always active for security, session, language, theme and recording your choice. Analytics Allows audience, navigation and performance measurement to improve content and experience. Personalization Allows content, preferences and experiences to be adapted based on your choices. Marketing Allows advertising storage, ad personalization and full measurement.

Install Rota42

On iPhone or iPad, open Rota42 in Safari and follow these steps:

  1. Tap Share in the Safari menu.
  2. Choose “Add to Home Screen”.
  3. Enable “Open as Web App”, then tap Add.