Signature Counter

What the signature counter does

A signature counter is a stateful signal that changes with each signing event, so the verifier can tell whether a credential is being used in the expected sequence. In practice, it is a simple anti-cloning check: when the counter behaves normally, the authenticator is likely genuine and the signing history is consistent.

That makes the counter useful in systems that rely on cryptographic authenticators, passkeys, or other signing tokens. It is not the trust anchor itself, but it is part of the evidence a verifier uses to judge whether a signing device is still the same device that was originally enrolled.

How signature counters help detect cloned authenticators

The main value of a signature counter is that a copied secret or duplicated authenticator will often fail to reproduce the expected counter progression. If an attacker clones a token or restores a copied credential onto another device, the verifier may see an unexpected reset, a stale value, or a value that moves in a way the original authenticator never would.

That pattern matters because replay and cloning attacks often preserve the cryptographic material but not the original device state. A counter gives the relying party a way to notice that the signing history no longer matches a single legitimate authenticator instance.

In systems that support passkeys and synced authenticators, counter behaviour can be more nuanced than a simple monotonic device counter. Some authenticators may keep counters per device, some may present backup or sync states differently, and some deployments must treat the signal as one factor among several rather than as a standalone proof of compromise.

For a practical implementation lens on passkey portability and the related counter behaviour, see the FIDO Credential Exchange Passkey Portability Guide.

Where signature counters can fail or mislead

Signature counters are useful, but they are not perfect. A counter can fail to increment for benign reasons, such as authenticator resets, synchronization behaviour, implementation quirks, or recovery flows that change how state is stored. If a verifier treats every counter anomaly as definite fraud, it can create false positives and lock out legitimate users.

They also do not protect against every kind of misuse. A valid signing operation from a compromised but still genuine authenticator may still look normal if the counter advances as expected. That means the counter is best understood as a consistency check, not a complete compromise detector.

Because of that, organisations should treat signature counters as one input in a broader authentication decision that also considers attestation, device binding, session behaviour, and anomaly detection.

What practitioners should verify when using signature counters

Teams implementing or relying on signature counters should be clear about what their verifier does when the counter goes backward, stays flat, or changes in an unexpected way. The policy needs to distinguish between a strong cloning signal, a recoverable state change, and a harmless implementation edge case.

Operationally, the most important question is whether the verifier can safely use the counter without overreacting to normal device lifecycle events. If the environment includes synced passkeys, backup restoration, or token replacement, those cases need explicit handling so the counter remains a useful signal instead of an outage trigger.

Practitioner note: A signature counter is strongest when the relying party knows how to interpret it, not when it is blindly trusted. The value comes from comparing expected state over time, then combining that check with the rest of the authentication posture.

Related resources from NHI Mgmt Group

• How can organizations counter AI-driven cyber attacks?
• What breaks when JWT claims are checked before signature validation?
• Why do JWTs fail even when the signature is valid?
• What breaks when SAML signature verification and assertion processing are separated?