Checkpoint: Where the Trust Boundary Moves

The passkey model now has two connected layers: a normal login in which a relying party verifies a fresh, verifier-bound assertion, and a lifecycle in which authenticators are bound, added, synchronized, renewed, or invalidated. This checkpoint connects those layers so readers can make one practical judgment: whether the account still has a controlled path back to the subscriber when the original authenticator is unavailable. The point is not to repeat each mechanism, but to see what changes when they operate together.

One assertion, many lifecycle decisions

During the preferred login, the relying party creates a challenge, the authenticator performs a local private-key operation, and the relying party verifies the response against the public key associated with the account. Verifier-name binding limits the response to the intended service. The fresh challenge limits replay. Local user verification or another explicit action can establish that the claimant participated in the transaction. These properties answer a narrow question well: does this claimant control an authenticator that can produce the right proof for this service now?

An account has to answer a broader question over time: which authenticators will the service accept tomorrow, and who is allowed to add or remove them? Binding turns an authenticator into an account relationship. Adding a second authenticator creates another future route into the account. Independent notification gives the subscriber a chance to notice that this relationship changed. Renewal replaces one relationship with another, while invalidation removes a relationship that should no longer be trusted.

Those events are not accessories to the cryptographic proof. They determine the set of proofs the service will accept. A perfectly verified assertion from an attacker-controlled authenticator is still a successful login from the service’s point of view unless the service has a way to detect and remove the unauthorized binding. Conversely, a subscriber may have a legitimate passkey but still be unable to use the account if every bound authenticator has been lost and no controlled restoration path exists.

This creates two different dimensions of account security. One dimension is proof strength: how difficult is it to forge, relay, or replay the assertion produced by an authenticator? The other is control continuity: how difficult is it for the wrong person to add a new authenticator, regain access through another route, or keep using an old authenticator after compromise? A service can perform well on the first dimension and poorly on the second. The dimensions interact, but one cannot be used as a shortcut for the other.

The distinction also explains why lifecycle records matter. A relying party needs more than a public key to decide whether to trust an event; it needs enough state to know which key is bound, when it was added, what kind of authenticator it represents, and whether a later event changed that relationship. Without such state, “invalidation” becomes an aspiration rather than a verifiable transition. The account may continue accepting a response that is mathematically valid but no longer belongs to the subscriber’s intended set of authenticators.