Compare the stored counter with the new one. If either is non-zero and the new value is not higher, the spec says a cloned authenticator may exist, or the device may be faulty, or requests may have been processed out of order. A mismatch is a risk signal for you to weigh, not proof of attack.
What the counter is
WebAuthn authenticators should keep a signature counter. The initial value comes back at registration in the authenticator data. Each successful sign in increases it, and the new value is returned in the authenticator data the relying party receives. Its purpose, per the W3C spec, is to help detect cloned authenticators.
The relying party stores the counter from the most recent assertion, or from registration if there has been none.
The comparison rule
On each sign in, compare the stored value with the new signCount. The spec describes the failure case: if either value is non-zero, and the new value is less than or equal to the stored one, a cloned authenticator may exist, the authenticator may be malfunctioning, or a race condition may exist where assertions are processed in a different order than they were generated.
| Stored | New | Meaning |
|---|---|---|
| 0 | 0 | Authenticator does not use a counter. Skip the check. |
| 5 | 6 | Normal. Store 6. |
| 5 | 5 | Suspicious or racing requests. Decide per policy. |
| 5 | 3 | Suspicious or racing requests. Decide per policy. |
| 5 | 0 | Falls under the same rule, since the stored value is non-zero. Decide per policy. |
Authenticators that do not implement a counter leave signCount at zero. The spec adds that detecting a mismatch does not tell you whether the clone or the original made the request.
What to do on a mismatch
The spec leaves the response to the relying party, based on risk tolerance and operations. A reasonable ladder:
- Log the event with the credential ID, account, time and network details.
- Do not lock the user out on the first event alone. Race conditions happen.
- Require an extra step, such as another factor or recent reauthentication, for that session.
- If it repeats, flag the credential for review or ask the user to register a new one.
- Offer a way for users to see and remove old credentials.
Pick the level that fits your data. A bank may be stricter than a forum.
Why zeros are common
Because the counter is optional, many authenticators keep it at zero. The spec notes per credential counters are preferred for privacy, since a counter shared across sites could act as a correlation handle. If you store nothing but treat any zero as failure, you will lock out legitimate users. Treat zero as "no information".
Race conditions in your own code
If two sign ins from one device overlap, your server may see counters out of order. Use a transaction or compare and set update when storing the new value, and avoid blindly overwriting with a lower number from a slower request.
What the counter cannot do
It does not stop a stolen session cookie, and it does not prove the sign in was the real user. It is one signal among several: device history, location, and credential flags such as backup eligibility. For how those flags change your risk view, see synced vs device-bound passkeys.
Quick check
Should I reject a sign in when the counter repeats?
The spec does not say to reject. It says a clone may exist and leaves the response to your risk tolerance. Many sites log it and step up verification.
Is a zero counter a bad sign?
No. Authenticators without a counter report zero. Skip the check when both values are zero.
Safeguard's SBOM and dependency scanning shows which WebAuthn libraries you ship, so you can check how they treat counters and what advisories apply. A free scan is available.
Sources
Last reviewed: 19 October 2026.
