A WebAuthn assertion can carry a valid signature and still present an operational anomaly: its signature counter is not greater than the value stored after an earlier successful assertion. That condition is useful, but it is not equivalent to proof that a private key was copied, and it does not make the counter a replay-prevention mechanism.

The signCount field sits inside authenticator data. A relying party receives that authenticator data as part of an assertion and verifies it together with the client data and signature. The counter can give the relying party evidence about authenticator state across successful ceremonies. Its security value depends on the authenticator’s counter behavior and on the relying party retaining the prior value correctly.

That makes signCount a stateful risk signal at the authentication boundary, not a substitute for WebAuthn’s cryptographic challenge, origin checks, RP ID checks, or signature verification.

The counter is authenticated state

Authenticator data includes a 32-bit unsigned signature counter. Because authenticator data is covered by the assertion signature, an intermediary cannot simply replace the counter with a preferred value without invalidating the signature.

For authenticators that implement a nonzero counter, successful authentication operations can advance it. The relying party stores the counter associated with a credential and compares a later assertion with the stored value. A value that advances is consistent with the expected sequence. A non-advancing value can indicate that two authenticator instances are using credential material whose counter state is no longer synchronized.

The relevant boundary is easy to miss. The relying party is not asking the counter to authenticate the request. The signature already authenticates possession of the credential private key for the ceremony. The counter adds historical context after the cryptographic checks succeed.

A simplified server-side sequence is:

receive assertion
    |
    +-- verify challenge and ceremony context
    +-- verify origin and RP ID binding
    +-- verify assertion signature
    |
    +-- read authenticatorData.signCount
    +-- compare with stored counter
    |
    +-- update risk state and stored counter

A counter check performed before signature verification would be acting on unauthenticated input. The counter becomes meaningful only as part of verified authenticator data.

A regression is evidence, not a verdict

Suppose a relying party has stored signCount = 41 for a credential. A later valid assertion reports 42. For an authenticator using an increasing counter, that sequence is ordinary. If a later valid assertion reports 18, the sequence is inconsistent with a single monotonically advancing counter state.

Credential cloning is one possible cause. If private credential material and counter state were copied at an earlier point, two copies could advance independently. Assertions arriving from both copies could then expose a counter value that fails to exceed the relying party’s stored value.

That observation does not establish a universal causal rule. Counter behavior varies, and platform or authenticator implementation details matter. A relying party therefore has to treat a suspicious counter comparison as input to policy. Depending on account sensitivity and other signals, policy might require another authentication factor, mark the credential for review, request credential replacement, or record the event for later correlation.

Immediate account lockout based only on a counter anomaly can turn an imperfect signal into an availability problem.

Zero has explicit operational significance

WebAuthn permits authenticators that do not implement a signature counter. In that case the counter can remain zero. A relying party cannot manufacture useful ordering from a sequence of zero values.

This distinction changes server logic. A comparison such as newCount <= storedCount cannot be treated as a clone detector without accounting for zero-counter behavior. If both values are zero, the relying party has no counter progression to evaluate.

Conceptually, the decision can be expressed as:

if storedCount == 0 and newCount == 0:
    no counter-based signal
else if newCount > storedCount:
    progression is consistent
else:
    counter anomaly; apply relying-party policy

Production logic still has to follow the WebAuthn specification and the behavior of the WebAuthn library in use. The important property is that zero is not silently converted into evidence of cloning.

Multi-device credentials weaken simple device narratives

Passkeys can be implemented as multi-device credentials. Credential material can be backed up and made available across a provider’s supported device ecosystem. That model does not fit the older assumption that one credential necessarily corresponds to one physical authenticator with one durable hardware counter.

WebAuthn authenticator data also carries backup eligibility and backup state information. Those flags provide separate credential-state signals and must not be inferred from signCount. A relying party that needs policy distinctions around backed-up credentials should evaluate the defined backup flags and its own acceptance policy rather than trying to derive device topology from the signature counter.

This is especially relevant to incident interpretation. A counter anomaly for a credential that can exist across devices does not justify a claim that a hardware token was physically duplicated. The server has observed a state inconsistency, not a forensic reconstruction of the credential’s storage history.

Replay defense belongs to the ceremony

The signature counter is sometimes given too much responsibility because its value changes over time. WebAuthn replay resistance primarily comes from the ceremony’s fresh server-generated challenge and the signed binding to ceremony data, not from requiring a globally unique counter value.

A relying party generates a challenge for an authentication ceremony, associates it with the pending transaction, and validates the returned client data. A captured assertion from an earlier ceremony should fail against a different fresh challenge. Origin and RP ID validation bind the ceremony to the expected web security context, while signature verification proves possession of the credential private key for the signed data.

The counter serves a different purpose. It can reveal suspicious state across otherwise valid assertions. Treating it as the replay nonce would blur two independent controls and create fragile behavior for authenticators whose counter remains zero.

Counter storage is part of the security property

A useful counter signal requires durable and correctly serialized relying-party state. If two application nodes accept assertions concurrently and both compare against a stale stored value, counter updates can race. The result can be lost progression, false anomalies, or reduced ability to correlate later assertions.

The database operation therefore deserves the same attention as the comparison itself. The credential record should identify the public key and current counter state unambiguously. Updates should prevent an older observation from overwriting a newer stored value.

Distributed deployments may implement this with a transaction, a conditional update, or another concurrency primitive appropriate to the datastore. The exact mechanism is deployment-specific. The invariant is more important: accepted counter state must not move backward because two server workers processed assertions at the same time.

Counter storage also needs to remain attached to the correct credential identifier. A user account with several WebAuthn credentials can legitimately have different counter histories for each credential.

Policy should preserve the distinction between failure and signal

Some WebAuthn checks are binary protocol requirements. A bad signature, wrong challenge, unacceptable origin, or RP ID mismatch causes the ceremony to fail. A signature-counter anomaly has a different role: it is evidence that can indicate a cloned authenticator or another state inconsistency.

Collapsing those categories makes policy harder to operate. A system that records the counter result as structured authentication telemetry can combine it with credential backup state, account recovery events, recent credential registration, device-management signals, and application-specific risk controls. None of those extra signals changes the validity of the WebAuthn signature itself.

The clean boundary is to finish mandatory cryptographic and ceremony verification first, evaluate authenticated counter state second, and apply explicit relying-party policy to any anomaly. That preserves the counter’s value without assigning it a guarantee the protocol does not provide.

Cybersecurity WebAuthn Authentication Passkeys