WebAuthn Signature Counters Are Clone Signals, Not Identity Proofs

A relying party can verify a valid WebAuthn assertion and still receive a counter value that adds no useful evidence about credential cloning. The signature proves possession of the credential private key for the signed assertion. The signCount field has a narrower role: when an authenticator maintains a usable signature counter, changes in that value can give the relying party evidence that the same credential may be active in more than one place.

That distinction matters because counter handling is sometimes treated as part of the core authentication decision. It is not a second proof of identity. It is a stateful signal whose security value depends on what the authenticator reports, what the relying party previously stored, and whether the credential can legitimately exist across multiple devices.

The counter travels inside authenticated data

A WebAuthn assertion contains authenticatorData, which includes the relying-party identifier hash, flags, and a 32-bit unsigned signCount. The authenticator signs data that incorporates this structure, so a relying party that successfully verifies the assertion can rely on the counter value as part of the authenticated message.

Authenticity of the field does not imply that every authenticator uses it as a monotonically increasing per-credential counter. WebAuthn permits counter behavior that does not provide that property. A relying party therefore has to interpret the value according to the protocol rules rather than assume that every successful assertion advances a unique credential-local sequence.

The relevant state exists on both sides. An authenticator may maintain a counter and return its current value. The relying party can retain the largest accepted value associated with the credential. A later assertion can then be compared with that stored state.

This comparison creates a detection mechanism, not a cryptographic binding to one physical device.

A non-increasing value can indicate duplicated credential state

Suppose a credential begins with a counter of 40 and its private key plus counter state are duplicated at that point. One copy produces assertions that advance its counter to 41 and 42. The relying party stores 42. If the other copy later produces an assertion with 41, the signature can still be valid because both copies possess the same credential private key.

The counter regression is the extra signal. The relying party has observed an authenticated counter value that is inconsistent with the state it previously accepted.

That pattern can be compatible with cloned authenticator state, but it is not a complete diagnosis. Counter semantics vary, and deployment behavior can create conditions that require more context. A relying party should not turn a counter anomaly into a universal statement about compromise without considering the authenticator and credential model in use.

The important security property is asymmetry: possession of a copied private key can satisfy signature verification, while divergent state may expose that more than one copy is producing assertions. The counter can therefore reveal some forms of duplication that signature verification alone cannot distinguish.

Zero changes the available signal

WebAuthn explicitly accommodates authenticators that do not implement a meaningful signature counter. A zero value can therefore be legitimate. If both the stored counter and the newly received counter are zero, the relying party does not gain clone-detection evidence from this mechanism.

That does not make the assertion invalid. Signature verification, challenge validation, origin checks, relying-party binding, user-presence or user-verification policy, and other applicable WebAuthn checks remain separate parts of the authentication decision.

Treating zero as an authentication failure would conflate an optional detection signal with proof of credential possession. Treating zero as evidence that cloning is impossible would make the opposite error. It means that this counter path contributes no useful ordering evidence for that credential state.

Operational policy can record the absence of a counter signal without pretending it is a protocol violation.

Synced credentials weaken the physical-device interpretation

Passkey deployments make a device-centric interpretation even less reliable. A credential may be available through an ecosystem that supports credential synchronization or backup. In such a model, the useful security question is not necessarily whether one private credential exists on exactly one piece of hardware.

WebAuthn exposes backup-related flags separately from signCount. Those signals let a relying party reason about credential properties without assigning a meaning to the counter that the protocol does not guarantee.

A relying party that requires hardware-bound credentials needs a policy and credential model that support that requirement. A signature counter cannot establish hardware exclusivity on its own. Even a steadily increasing counter only shows a sequence of authenticated values consistent with the stored state; it does not prove that no other copy of credential material exists.

This boundary is especially important when security policy distinguishes synced passkeys from credentials held by a dedicated security key. The distinction must come from supported authenticator and credential properties, not from an inference that a healthy counter sequence equals one physical authenticator.

Counter checks need atomic relying-party state

A useful counter comparison also depends on server-side concurrency control. Consider two valid assertions for the same credential arriving close together. If both application workers read the same stored value before either update is committed, a naive check-and-write sequence can produce misleading state.

The relying party should treat counter comparison and state advancement as one consistency problem. The exact implementation depends on the datastore, but the invariant is straightforward: accepted counter state should not move backward because two requests raced at the application layer.

For a credential whose counter semantics support monotonic comparison, an update can be expressed conceptually as:

received = assertion.authenticatorData.signCount
stored   = credential.signCount

if counter_signal_is_applicable:
    if received <= stored:
        record_counter_anomaly()
    else:
        atomically_advance(stored, received)

The predicate is deliberately explicit. Counter handling has to account for cases where the mechanism supplies no meaningful monotonic signal. The atomic update also needs to be tied to an assertion that has already passed the required cryptographic and contextual checks; an unauthenticated request must not be able to advance credential state.

An anomaly belongs in risk policy, not in signature verification

The cleanest implementation boundary keeps cryptographic validity separate from counter-derived risk. A valid signature answers whether the assertion was produced with the credential private key over the expected data. Counter comparison answers whether the newly authenticated state is consistent with previously accepted counter state, when such comparison is meaningful.

A deployment can react to an anomaly according to its threat model. It may require another authentication factor, flag the credential for investigation, notify an account owner, restrict a sensitive action, or reject the assertion. Those are policy decisions. WebAuthn supplies the authenticated counter and the conditions for interpreting it; it does not turn every suspicious counter value into a complete account-compromise verdict.

Keeping that boundary explicit also improves incident evidence. Logs can distinguish a failed WebAuthn assertion from a cryptographically valid assertion carrying anomalous counter state. Those events have different causes and call for different investigation paths.

The durable property is authenticated state, not uniqueness

signCount is most useful when it is treated for what it is: authenticated state that can expose inconsistency across assertions. Its strength comes from being covered by the credential signature and compared with relying-party history. Its limitation comes from the fact that counter behavior is not a universal proof of one credential residing on one device.

A relying party can preserve the signal by storing counter state consistently, interpreting zero and credential capabilities correctly, and routing regressions into an explicit risk policy. The resulting control can detect some duplicated-state patterns without making the stronger claim that WebAuthn counters establish physical credential uniqueness.