Audit the Whole Account, Not the Button
The central question for passkeys is not whether the preferred login is strong. It is whether the account remains under the subscriber’s control across every route that can authenticate, add an authenticator, restore access, or keep an old credential alive. This final chapter turns that question into a whole-account audit: trace the normal proof, identify the owners of recovery and synchronization, separate AAL claims from account-wide claims, and state conclusions only as strongly as the evidence allows.
Start with every way into the account
A passkey review should begin with the normal ceremony because that is where the technology’s strongest properties are most visible. The relying party creates a fresh challenge. The authenticator produces a credential-specific response tied to the relying party. Local user verification or another explicit action may establish user participation. The relying party verifies the assertion and creates a session.
That path answers one question: can this claimant prove control of an authenticator the service already recognizes for this transaction? It does not answer how the account was first bound, whether another authenticator was added later, whether a sync fabric can place the credential on another device, or what happens when the preferred authenticator is lost. The first audit move is therefore to draw a boundary around the normal proof rather than allowing its strength to stand in for the whole account.
The next move is to inventory the account’s other transitions. A service may allow another authenticator to be added, a device to be approved, a recovery address to be changed, a saved code to be used, a support request to be opened, an identity provider to be linked, or a password to be reset. These operations are not all authentication in the same technical sense, but each may change who can authenticate later. A route that cannot sign a WebAuthn challenge may still be able to create an authenticator that can.
The practical audit is not a hunt for a single weakest button. It is a comparison of paths and outputs:
- Ordinary authentication proves control of an existing authenticator for a current session.
- Additional binding creates another durable authenticator relationship.
- Loss reporting contains a suspected compromise by asking the service to suspend or invalidate an unavailable authenticator.
- Account recovery accepts specified evidence to restore ownership when the required authenticators are unavailable.
- Replacement binding creates the credential that will carry control into the future.
- Invalidation removes an old or compromised route so that it no longer authenticates.
The same user interface may combine several of these operations, but a sound audit keeps their purposes separate. If a service accepts a password to report a lost passkey, that does not by itself show that the password is an acceptable general replacement for the passkey. If a recovery event binds a new authenticator, the reviewer must still ask what happened to the old one. If a user has a second bound passkey, using it may be ordinary alternate authentication rather than recovery.
A useful test is to ask what durable state changes at each step. A normal login may create a session. Adding a device changes the set of authenticators accepted by the account. Recovery changes who the service recognizes as having regained control. Replacement binding changes the future path into the account. Invalidation changes which old proofs remain valid. The security significance comes from the state change, not from the label on the screen.
The audit should also examine visibility. NIST expects providers to maintain records of bound authenticators and significant lifecycle events. Independent notifications matter because an attacker who adds an authenticator may control the channel used to perform that transaction. A subscriber needs a separate way to learn that account control changed.