The Credential Has a Second Life
A passkey does not remain a one-time object created on one phone and used forever in one place. This chapter follows the credential after the first successful login: how it becomes bound to an account, how another authenticator is added, how synchronization changes the trust boundary, and how those choices affect the assurance a service can claim. The practical result is a way to tell the difference between a passkey that is merely available on another device and an account whose whole authenticator lifecycle remains under control.
Binding is an account event
The most important lifecycle transition is binding. Binding establishes the association between a particular authenticator and a subscriber account. It is what changes a cryptographic capability from something a device possesses into something a service will accept as evidence for a particular person’s account.
That association has state. NIST says a credential service provider must keep a record of the authenticators bound to each account, their relevant characteristics, and significant events such as binding, renewal, expiration, and update. The provider needs that information because an authenticator is not just “valid” or “invalid” in the abstract. The service may need to know whether it is a single-factor or multi-factor authenticator, whether it is phishing-resistant, and whether it is suitable for the assurance level of the account or transaction.
A second authenticator is therefore a security event, not merely a convenience setting. NIST recommends that providers encourage subscribers to maintain at least two separate means of authentication because a second method can reduce dependence on emergency recovery. At the same time, it requires providers to permit multiple authenticators and says that adding one must require authentication at the maximum assurance level currently available in the account or at which the new authenticator will be used, whichever is lower. The rule protects the account at the moment an attacker would most like to create a durable alternative route.
Consider a user who has a passkey on a phone and wants to add a laptop. The service should not treat the laptop as trusted simply because it is nearby or because the user is already looking at a login page. The new binding must be approved through an authenticated process. When the new device cannot directly use the already authenticated endpoint, NIST describes a short-lived, one-time binding code transferred between the endpoints, manually or through a local out-of-band method. It should not be sent through an insecure channel such as email. After binding, the provider should encourage a test authentication and must notify the subscriber through a mechanism independent of the transaction that added the authenticator.
The independent notification matters because the same channel that creates a new authenticator may be controlled by an attacker. A message sent through that channel alone cannot reliably tell the legitimate subscriber that account control has changed. A separate notification gives the subscriber a chance to recognize a mistaken or fraudulent binding and begin invalidation while the event is still recent.
Imagine the phone-and-laptop example from the subscriber’s point of view. The subscriber first proves control with the phone, approves the laptop through the binding process, and then receives a notice through a separately maintained address. The new laptop is now another way to authenticate, but it is not an invisible clone of the original event: it has its own binding history and may need to be removed independently. If the subscriber did not request the addition, the notice is evidence that something changed even if the attacker has already ended the browser session that performed the binding.
This is also why “add a device” should not be hidden inside an ordinary login success screen. The ordinary login answers, “Can this claimant use an authenticator already bound to the account?” Adding an authenticator answers, “May this new device become another future answer to that question?” Those are different decisions. The second one creates persistence, so its approval and notification deserve their own controls.
The account can also move in the other direction. An authenticator may be renewed before it expires, and the old one should be invalidated after the replacement has been used successfully. If an authenticator is lost, stolen, damaged, or otherwise compromised, the service has to record and act on that state rather than continuing to treat it as an ordinary member of the account. The lifecycle is therefore not a calendar of maintenance tasks. Each transition changes which proof the service will accept and which device or person can exercise it.
The states and transitions can be pictured this way:
The diagram is not saying that every account follows one rigid sequence. A credential can be eligible for synchronization while it is still bound, and an account can contain several bound authenticators at once. The point is that “the passkey” has a history. A review that examines only the final signature has discarded the events that determined where the credential is accepted and how it can be removed.
Synchronization changes what “on the device” means
Synchronization makes a passkey useful across devices by allowing its authentication key to be backed up and transferred through a sync fabric, such as a cloud-backed credential manager. The ordinary login can still look local: the device selected by the user performs the private-key operation and returns an assertion to the relying party. But the key’s availability on that device was created by a larger system. The sync account, its access controls, its recovery process, and the devices allowed to receive the key now participate in the account’s security boundary.
NIST calls this operation cloning and treats the resulting authentication keys as inherently exportable. Exportability has a precise meaning here: the authentication key can be replicated, shared, or stored outside the protected boundary of one authenticator. It does not mean that the key is sent in plain text to every relying party. It means that the ability to use the key is no longer confined to one non-exportable hardware boundary.
That trade-off is what makes synchronization valuable. A device-bound authenticator can fail through loss, theft, damage, or simple hardware replacement. A syncable authenticator can make the credential available on another device, reducing dependence on the original object. The cost is that the sync fabric becomes a high-value control point. NIST requires synced keys to be encrypted, limits access to authenticated users, and requires user access to the sync fabric to be protected by AAL2-equivalent multi-factor authentication. It also recommends encryption using a user-controlled secret, meaning a secret not known only to the sync provider, and recommends a user interface that shows which services have syncable keys and whether and where those keys have been synced without exposing the key itself.
The word “can” is important in the WebAuthn backup signals. The Backup Eligible flag indicates that an authenticator can be synced to another device. The Backup State flag indicates that it has been synced. Capability and current state are different facts. A credential can be built on a platform that supports synchronization while not yet having been copied. Conversely, a service that sees a synchronized state is learning something about the credential’s history, not receiving a complete description of every protection around the sync account.
NIST says agencies may use these flags to establish policies, but public-facing applications generally should not condition acceptance on Backup State because doing so can create user-experience problems. That is a policy judgment, not a claim that the state is irrelevant. It means the relying party has to decide how much visibility it needs and what consequence it can safely attach to the information. A flag can inform a risk decision without becoming a universal pass-or-fail rule.
Synchronization also creates threats beyond device loss. If an attacker gains access to the sync fabric or to its recovery process, the attacker may gain a route to keys intended for multiple devices. Some implementations allow keys to be shared between users, which can be useful for shared accounts but reduces the relying party’s visibility into who is exercising the credential. And because WebAuthn credentials are specific to relying parties, there is no simple, single central list that revokes every affected key when a sync account or device is compromised. The service may need to identify and remove each bound credential, while the sync provider manages a different layer of access.
The important failure is not limited to a cloud database being stolen. A sync fabric can be exposed through the account that authorizes a new device, through recovery of that account, through an unmanaged device, or through a sharing feature that the relying party cannot inspect. NIST therefore lists unauthorized access to the sync fabric and recovery as a distinct challenge and recommends binding multiple authenticators, requiring strong authentication to add new ones, notifying the user about recovery activity, and using a user-controlled secret where possible. These measures do not remove the trade-off; they make the new boundary visible and give the subscriber or provider more ways to detect and contain it.
Revocation is another consequence of the distributed design. A service can remove a credential that it knows is bound to the subscriber’s account, but it may not know every device on which the corresponding syncable key exists. The sync provider may be able to remove access to the sync fabric, while the relying party still needs to invalidate its own credential binding. Conversely, invalidating one relying-party credential does not necessarily remove other credentials held by the same sync account. A complete response can require action at both layers.
These risks do not make syncable passkeys equivalent to passwords. A synchronized key can still be used in a verifier-bound, challenge-based protocol. The trade-off is different: the key is better protected against the failure of one device, but the account depends on more state and more control surfaces. The security question moves from “can this one device sign?” to “who can cause this credential to appear on another device, and how will the account detect and undo that change?”
Assurance is not the same as convenience
The lifecycle choices also put a ceiling on the assurance label. NIST describes AAL1 as basic confidence that a claimant controls an authenticator. AAL2 requires proof of two distinct authentication factors and requires that a phishing-resistant option be available. AAL3 requires phishing resistance, two factors, and a non-exportable authentication key. Because synchronization inherently makes the key exportable, NIST says syncable authenticators cannot be used at AAL3.
This does not turn AAL2 into an endorsement of every sync implementation. The AAL2 possibility depends on the relevant requirements: protected sync-fabric access, suitable local verification, replay-resistant cryptography, and the other controls that apply to the authentication process. Nor does an AAL label describe the security of recovery, sessions, or every action available after login. It describes the assurance of the authentication process under the stated conditions.
The distinction is useful when two devices appear to offer the same passkey. They may produce equivalent-looking assertions for the same relying party, yet differ in whether the credential is device-bound, eligible for backup, already synchronized, or governed by a managed account. The relying party may see some of those properties, depending on the authenticator and the available metadata, but it should not infer more than the response and policy support.
For example, accepting a syncable passkey for an AAL2 transaction does not mean that the relying party has established the conditions required for AAL3. AAL2 can accommodate a syncable key when the authentication process supplies the required factors and protections. AAL3 deliberately sets a different boundary: the private key must be non-exportable, so the ability to clone it to another device is disqualifying. The two cases can share the same user-facing gesture and still represent different assurance decisions.
Nor should convenience be treated as a universal measure of security. A device-bound key may be harder to lose through cloud-account compromise but easier to lose through physical failure. A syncable key may be easier to restore across devices but harder for an individual relying party to revoke everywhere it exists. The right choice depends on the account’s threat model and the controls available at the sync and service boundaries. What must remain constant is the discipline of saying which property the choice improves and which new dependency it creates.
The account is now best understood as a set of relationships rather than as one secret. Binding determines which authenticators count. Synchronization determines how a credential can cross device boundaries. Backup signals describe capability and history. Independent notification provides a way to detect changes. Invalidation determines whether a compromised relationship still works. These choices make the passkey resilient to one kind of failure while introducing questions about another.
Before judging recovery or fallback, the essential model is therefore complete: a passkey’s normal assertion can remain strong while the account’s control surface expands through additional authenticators and synchronization. The next judgment is to put those pieces together and ask where trust moves when the credential is no longer confined to the original login device.