the counter that never counts

WebAuthn credentials carry a signature counter that increments on every use. The intent is clone detection: a counter going backwards means someone copied the authenticator. That picture died when passkeys started syncing. iCloud Keychain and Google Password Manager report zero, forever, because syncing is cloning, done benignly and on purpose. The clone-detection signal is permanently indistinguishable from the most common legitimate setup.

That kills two designs. The obvious one treats a regressed counter as a cloned authenticator and locks the credential — against a synced passkey it can only ever fire on the owner. The subtle one bit me building a “last signed in” line: stamp the timestamp only when the counter advances, and the primary phone (the device the feature exists to make visible) never gets a stamp. So the stamp now lands on every successful assertion, the counter only moves forward via a max, and the counter is demoted to telemetry: recorded, displayed, never a gate.

The same inventory grew a remove button with exactly one refusal in it: deleting the last credential while no recovery path exists. Everything else is the owner’s call, including removing the passkey of the machine you’re sitting at. I tested that one honestly, by doing it and walking back in through another device before re-enrolling.

A signal that can be legitimately wrong can never be a gate. Demote it to telemetry, stamp facts you control, and save the hard refusal for the one action that would lock the owner out of everything.