Two valid WebAuthn assertions for the same credential arrive close together. One carries a signature counter of 42 and the other carries 41. Both signatures verify. The relying party now has evidence that deserves attention, but it does not have cryptographic proof that the second assertion came from an attacker.
That distinction is built into WebAuthn’s signature-counter model. The counter is auxiliary state intended to help detect cloned authenticators. It is not part of the primary decision that establishes possession of the credential private key, and some authenticators legitimately keep it at zero.
Treating signCount as a hard monotonic authentication invariant can therefore reject valid traffic. Ignoring it entirely discards a signal that can be valuable for credentials whose authenticators maintain counters. The implementation boundary sits between those two extremes.
The signed assertion carries counter state
During authentication, an authenticator returns authenticator data alongside the assertion signature. That authenticator data includes a 32-bit unsigned signCount field. The relying party verifies the assertion using the stored public key and also processes the authenticator data according to WebAuthn’s verification rules.
For an authenticator that implements a signature counter, successful assertion operations increment the counter by a positive value. A relying party can store the latest accepted value with the credential record and compare it with the value presented by a later assertion.
The comparison is meaningful because the counter travels inside authenticator data covered by the assertion signature. An intermediary cannot simply replace 41 with 43 while preserving a valid signature. A suspicious value therefore reflects state reported by an entity possessing credential signing capability, subject to the authenticator’s actual counter behavior.
That still does not make the counter an identity proof. The signature proves possession of the private key for the assertion. The counter adds evidence about the history of operations associated with that key material.
Non-increasing values have several explanations
WebAuthn Level 3 specifies the core comparison condition precisely. If either the stored counter or the newly received counter is non-zero, and the new value is less than or equal to the stored value, a cloned authenticator may exist. The specification also identifies authenticator malfunction and assertion-processing races as possible causes.
The race case matters in distributed services. Suppose one authenticator creates assertion A with counter 41 and then assertion B with counter 42. Network timing, retries, load balancing, queues, or database scheduling can cause B to commit first. When A reaches the comparison later, its valid counter is now below the stored value.
A database transaction can make the stored update atomic, but atomicity cannot restore the authenticator’s original event order when assertions are processed out of order. A strict rule that rejects every non-increasing counter therefore converts a detection heuristic into an availability condition.
Clone detection has a similar ambiguity. If a copied credential and its original both produce valid signatures, a counter conflict can indicate duplicated key state. The relying party cannot infer from the mismatch which device is original. The signal can justify risk escalation, credential review, or another policy response, but the counter alone does not identify the malicious side.
Zero is a defined operating mode
Authenticators are not required to expose a useful increasing counter. WebAuthn Level 3 states that authenticators without a signature-counter feature leave signCount constant at zero.
This changes the server-side state machine. A credential registered with zero and continuing to return zero supplies no monotonic clone-detection signal through this field. The relying party still verifies the challenge binding, relying-party identifier hash, origin-related client data, flags required by policy, and assertion signature. Authentication does not become invalid merely because the counter is zero.
The zero case is especially important for deployments that assume every public-key credential behaves like a traditional hardware token with persistent per-credential mutable state. WebAuthn intentionally supports a broader authenticator ecosystem. Server logic has to preserve the distinction between a missing counter signal and a failed cryptographic check.
A transition involving non-zero state is different. Once either side of the comparison is non-zero, the specification’s counter comparison becomes relevant. Implementations should not silently reset stored non-zero state to zero merely to eliminate mismatch events.
Synchronized credentials weaken simple monotonic models
Modern credential ecosystems can make credential material available across multiple devices through a credential provider. That architecture does not fit neatly into a single physical authenticator maintaining one globally serialized mutable counter for every assertion.
WebAuthn’s security model accounts for authenticators that do not implement counters, so relying parties cannot require an increasing value as a universal property of passkey authentication. A service that makes successful login contingent on signCount > previousSignCount risks turning legitimate credential behavior into account lockout.
The operational consequence is subtle: stronger portability can reduce the usefulness of one legacy clone-detection signal without removing the core phishing-resistant credential properties supplied by WebAuthn’s scoped public-key authentication. Counter policy and signature-verification policy must remain separate.
This also affects telemetry. A dashboard that labels every zero-counter credential as defective will produce misleading data. Zero can mean that the authenticator deliberately supplies no signature-counter feature. Risk systems need to represent that state explicitly instead of collapsing it into success or failure.
Counter storage is shared security state
When a relying party does use non-zero counters, the stored value becomes security-relevant mutable state. Multiple application instances need a consistent strategy for reading and updating it. A process-local cache that lags behind the durable credential record can suppress a mismatch or generate one after another node has already advanced the value.
A common pattern is to compare and update within a transaction tied to the credential record. The update should avoid moving the durable value backward when an older assertion arrives after a newer one. Preserving the maximum observed valid value keeps stale processing from erasing evidence needed by later comparisons.
That storage rule does not resolve every race. Two valid assertions can still be generated and processed concurrently, and a counter anomaly can still be ambiguous. It does, however, prevent ordinary write ordering from making the server’s own record regress.
Credential identifiers also matter. Counter state belongs with the credential whose public key verified the assertion. Storing one account-wide counter across several WebAuthn credentials would combine independent authenticator state and manufacture conflicts between devices.
The signal belongs after cryptographic verification
Counter handling must not distract from the checks that make a WebAuthn assertion valid. The relying party first needs a credential record selected through the protocol’s credential-identification rules, then must validate the ceremony data and signature according to the specification and its local policy.
An attacker-controlled signCount from an assertion that fails signature verification has no trusted security meaning. Likewise, a pleasingly high counter cannot compensate for a challenge mismatch, incorrect relying-party identifier hash, invalid origin context, missing required user-verification state, or bad signature.
This ordering prevents auxiliary telemetry from becoming an authentication bypass. Counter evaluation enriches the verdict produced by a valid assertion; it does not repair an invalid assertion.
The same separation helps incident handling. A counter regression attached to a cryptographically valid assertion can be recorded as credential-risk evidence. A malformed or invalidly signed assertion belongs to a different failure class and should not mutate trusted counter state.
Counter anomalies need policy, not certainty
WebAuthn deliberately frames a non-increasing counter as evidence with multiple possible causes. That framing leaves the relying party responsible for selecting a response appropriate to its threat model and account-recovery design.
A high-assurance service might require an additional authentication factor or suspend the affected credential after a credible mismatch. Another service might allow the signed assertion while recording the anomaly and increasing risk controls. Either approach needs to account for concurrent processing and authenticator behavior before assigning meaning to the event.
The key limitation is irreducible: signCount cannot prove that a credential has not been cloned, and a mismatch cannot prove which holder is illegitimate. Authenticators that remain at zero provide no clone signal through this mechanism at all.
WebAuthn signature counters are therefore best treated as authenticated telemetry attached to a credential, not as a second signature verdict. Their value comes from preserving accurate per-credential state, interpreting non-increasing values in context, and keeping the signal subordinate to the protocol checks that establish a valid assertion.