The Passkey Works—Until You Need a Way Back In
Passkeys are designed to make the ordinary web login resistant to phishing without asking people to memorize another secret. This series examines the passkey as a complete account-control system: not just how a relying party verifies a cryptographic assertion, but also how a credential is synchronized, how another authenticator is added, and what happens when the preferred device is lost. The practical judgment is simple to state but easy to miss in product demos: a strong login does not automatically make every route back into the account equally strong.
A passwordless login is still a login system
A passkey is a discoverable WebAuthn credential that can be synchronized across a user’s devices through a credential manager. It is built on public-key cryptography rather than on a password shared with a service. During registration, the authenticator creates a key pair. The relying party—the service that wants to recognize the user—keeps the public key. During a later login, it sends a fresh challenge, and the authenticator uses the private key to sign a response. The service checks that response with the public key.
That arrangement changes the central problem. A password is a reusable secret: if an attacker learns it, the attacker can present the same value to the real service until the password is changed. A WebAuthn assertion is tied to a particular transaction and to the identity of the relying party. The authenticator is not supposed to sign a challenge for a lookalike site merely because the user has been persuaded to visit it. NIST describes this property as verifier-name binding, one form of phishing resistance that does not depend on the user spotting every fake page.
Several protections are working together here, and keeping them separate prevents overstatement. The relying party’s challenge provides freshness, so an old response should not simply be replayed. The verifier name binds the response to the intended service, so a fraudulent site cannot turn the user’s action into a valid assertion for itself. Local user verification or another explicit action can establish that the claimant intended to authenticate, rather than allowing malware or an unattended endpoint to trigger the operation silently. These properties reinforce one another, but none of them describes what happens when the claimant cannot perform the operation at all.
This is also why a passkey is not just a biometric. A fingerprint or face scan may be the local action that unlocks an authenticator, while the relying party verifies a cryptographic assertion. The service does not receive a reusable password-equivalent value from that local gesture. But the account still needs a policy for adding a replacement authenticator and for handling a user who has lost access to the device or credential manager. The strong part of the ceremony is real; it is simply narrower than the entire account relationship.
The distinction matters because “passwordless” describes what the user does not type, not everything the account can do. A passkey can protect the preferred authentication ceremony while the account still has other operations: adding a device, replacing an authenticator, recovering access, or using an alternate sign-in method. Each operation changes who is allowed to act for the subscriber and what evidence the service accepts.
The basic system therefore has more than one actor. The subscriber controls the authenticator. The authenticator performs the private-key operation, often after local biometric or PIN-based verification. The browser or client connects that operation to the relying party. A sync fabric may copy the credential to another device. An identity provider may authenticate the user first and then pass a token to the relying party. Finally, the account service owns the rules for binding, recovery, notifications, and invalidation. Treating all of these as “the passkey” hides the points where control can change hands.
The map below separates proving control during an ordinary login from restoring control after the preferred authenticator is unavailable.
The ordinary branch proves that the claimant controls an authenticator for one session. The lower branches decide whether the claimant can regain that control later, and under what conditions. They are related, but they are not the same security event.
The account survives longer than the device
An authenticator has a lifecycle. It is bound to an account, used, possibly copied through a sync fabric, joined by additional authenticators, renewed, suspended, or invalidated. NIST recommends that providers encourage subscribers to maintain at least two separate means of authentication because redundancy can reduce the need for emergency recovery. It also requires providers to track the authenticators bound to an account and the important events in their lives.
That recommendation creates a necessary tension. A second way into an account improves availability: a user who loses a phone need not be locked out forever. But a second method is not automatically as resistant to phishing, replay, or unauthorized use as the passkey it backs up. The correct question is not simply whether a service offers “backup.” It is what the backup proves, who controls it, and what the service does after it is used.
Synchronization adds another layer. A passkey that works on several devices is convenient partly because its authentication key can be backed up and transferred through a sync fabric. NIST consequently treats syncable keys as exportable. The normal login may still perform the signing operation locally, but the key’s lifecycle now depends on access controls around the sync account, the devices that can receive the key, and the recovery process that can restore access to the sync fabric. Convenience has reduced dependence on one physical device, while increasing the number of systems that must preserve control.
This is also why assurance labels need care. NIST allows syncable authenticators to support some AAL2 uses when the relevant protections are present, but sync violates the non-exportability requirement for AAL3. “Passkey” therefore does not name one universal assurance level. A service may be using a phishing-resistant WebAuthn ceremony while making a different choice about syncability, local user verification, device management, or recovery.
A security review that stops at the successful assertion sees only the front door. A review that follows binding and synchronization can ask more useful questions: Was a new authenticator added after an adequately authenticated event? Was the subscriber notified independently? Can the subscriber see where a credential has been synchronized? Can the service remove a compromised authenticator, and how quickly? Those questions concern account control, not the cryptographic validity of one login.
Loss makes the difference visible. If a subscriber signs in successfully, the service has evidence about control of an authenticator at that moment. If the phone is lost the next day, that evidence is no longer available in the same form. The service must decide whether the claimant can report the loss, recover the account, or bind a new authenticator, and it must decide what happens to the old one. Those decisions are not merely user-experience refinements. They determine whether an attacker who has obtained a device, a recovery channel, or access to a sync account can convert temporary access into durable control.
NIST treats account recovery as a distinct event and notes that it may be less convenient or involve waiting. It also requires notification after recovery and expects compromised authenticators to be suspended or invalidated promptly once the compromise is detected. This creates a useful design test: a recovery process should be difficult enough to resist an impostor, but visible and usable enough that a legitimate subscriber can regain control before an attacker’s temporary advantage becomes permanent. A service that advertises only the speed of its normal login has not answered that test.
The lifecycle perspective also changes how “backup” should be read. A backup can mean another authenticator that remains bound to the account, a credential copied through a sync fabric, a method for reporting loss, or a full account-recovery channel. Those arrangements do not provide the same evidence or serve the same purpose. The rest of this series will keep them separate rather than treating every route around the passkey as an equivalent substitute.
Availability is not adoption—and support is not one trust arrangement
The deployment evidence makes the distinction practical. The census of the Tranco top 100,000 domains reports 9,397 detected passkey-supporting sites and states that 11.3% of scanned sites supported passkeys. It also reports a strong popularity gradient: support was much more common among the most popular sites than among sites ranked 50,000 to 100,000. These are measurements of service-side availability. They do not show how many users enrolled a passkey, how often they use it, or whether they can recover an account safely.
The paper also separates native passkey implementations from support delegated to an external identity provider. A site may offer “Continue with Google,” for example, while Google handles the actual authentication. The relying party receives an OAuth token; it may not know whether the provider used a passkey, a password, a one-time code, or another method. The login page can therefore look like one coherent experience even though its security and recovery boundaries belong to different organizations.
Delegation can be sensible: a service does not need to build every authenticator function itself, and a mature provider may give users a familiar way to sign in across many sites. But delegation changes the audit question. The relying party may be able to validate the token and protect the session while having little control over how the provider enrolls a passkey, recovers a locked-out account, or notifies the user about a newly added device. The provider’s recovery policy becomes part of the relying party’s practical access path, even if the relying party never sees the underlying recovery transaction. That is an architectural dependency, not proof that the provider’s process is weak; it is simply a dependency that must be identified.
That distinction is not an argument against passkeys. It is an argument for asking a more precise question. When a service says it supports passkeys, which service stores or verifies the credential? Who can add another authenticator? Which process restores the account after a device is lost? Who sends the warning when recovery occurs? The answers may belong to the relying party, a platform credential manager, an identity provider, or several of them together.
The census itself illustrates why the answers cannot be inferred from a visible button. Passkey options may appear only after JavaScript runs, after a user enters an identifier, or inside conditional browser mediation. The study needed browser instrumentation and multiple heuristics because static page inspection missed much of the behavior. Its results are valuable evidence about deployment patterns, but they are not a security audit of each site’s recovery design.
The central question for this series is therefore not whether passkeys are secure. Their ordinary public-key ceremony can provide strong, phishing-resistant protection. The better question is whether the account remains under the subscriber’s control when that ceremony is unavailable, when a new device is added, when synchronization is involved, or when another provider handles the login. The next step is to look closely at what the ordinary passkey actually protects—and to keep that protection separate from the rest of the account’s lifecycle.