FIDO authentication is widely described as resistant to phishing, credential theft, and replay. Those claims are broadly justified. But one important security mechanism remains inconsistently implemented across the ecosystem: the signature counter.
For consumer accounts, that inconsistency may be an acceptable tradeoff for convenience. For administrators, infrastructure operators, financial systems, identity recovery, and other high assurance applications, it is a risk that should no longer be ignored.
A FIDO credential that continuously returns a signature counter of zero should not be considered safe.
Every successful FIDO authentication produces a signed assertion. An authenticator that supports a signature counter advances the counter and includes its new value in the signed authenticator data.
The relying party stores the last accepted value. If a later assertion contains an equal or lower nonzero value, the relying party has evidence that the credential may have been copied, the authenticator may be malfunctioning, or authentication requests may have been processed out of order.
The counter does not prevent a private key from being copied. It provides a way to detect possible duplication when two copies begin authenticating independently. Without a counter, that detection mechanism disappears, allowing an attacker who has obtained a copy of the credential to impersonate the user without triggering counter based evidence of duplication.
The FIDO Alliance certification page now identifies its February 2026 FIDO2 Server Requirements version 2.3 as the active requirements document. It states that a server must validate authentication assertions using the WebAuthn verification procedure. FIDO2 Server Requirements
That WebAuthn procedure includes storing and comparing the signature counter whenever either the stored value or the newly received value is nonzero. A counter regression is a security signal that the relying party is expected to evaluate. WebAuthn Level 3
This is an important requirement for FIDO servers. Servers cannot simply discard a valid counter supplied by an authenticator. If a credential supplies a nonzero counter, the server must retain the last accepted value, compare the next value, and respond appropriately when the counter fails to advance. Merely receiving the field is not enough. A counter that is accepted but never evaluated provides no clone detection value.
A permanent counter value of zero means the relying party cannot use the counter to detect independent use of duplicated credentials. A copied credential may continue signing fresh authentication challenges while the relying party receives no counter based indication that more than one copy exists.
For ordinary consumer accounts, an organization may choose to accept this limitation. For administrators, infrastructure operators, identity recovery, financial approvals, regulated transactions, and production systems, zero should not be permitted.
A credential returning zero should never be the sole authenticator for a privileged account.
Synced passkeys allow the same private credential to be available on multiple devices. Major providers include Apple Passwords and iCloud Keychain, Google Password Manager, Microsoft Password Manager, and third party password managers. These credentials commonly return a counter of zero. Because several devices can use the credential independently, maintaining a reliable monotonic counter is difficult.
The relying party must therefore depend on the provider’s synchronization security, encryption, account recovery process, and access controls. The relying party loses its own counter based clone detection signal. Synced passkeys returning zero should not be accepted as the sole authentication method for privileged enterprise access.
Shared passkeys create a more direct problem. Multiple people or vault members may possess usable copies of the same credential. The relying party may be unable to determine which person or device produced a particular assertion. When the credential returns zero, the relying party also loses the ability to detect independent use through counter regression.
Shared passkeys should not be used for administrator access, production infrastructure, sensitive approvals, identity recovery, or regulated transactions.
Apple has publicly documented that its Face ID and Touch ID platform authenticator does not implement the signature counter and returns zero. Apple relies on Secure Enclave protection instead. Secure Enclave protection is valuable, but it does not provide the relying party with an independent counter based clone detection signal. Apple credentials that can be synchronized or shared should therefore be treated as lower assurance than a device bound credential with a functioning counter.
An enterprise that requires clone detection should not accept imported, exported, synchronized, or shared passkeys for any accounts which should be protected.
In controlled testing, Microsoft Entra accepted authentication assertions from credentials returning a counter of zero. More concerning, Entra also accepted valid assertions from a duplicated credential when the supplied nonzero counter did not increase from the previously accepted value. The duplicated credential was able to sign fresh authentication challenges, and authentication completed even though the counter failed to advance. This is precisely the condition the signature counter is intended to expose.
These results indicate that Entra did not enforce counter progression in the authentication flow we tested. Entra customers therefore should not assume they are receiving counter based clone detection merely because their authenticator supplies a valid counter.
Microsoft should publicly disclose:
Until Microsoft documents or corrects this behavior, enterprises should not treat the Entra implementation as enforcing the signature counter security control.
The findings described here are based on controlled testing and should be independently reproduced. Microsoft has not publicly confirmed them. Though the issue has been reported.
For high assurance accounts, organizations should require device bound authenticators that produce working nonzero signature counters.
The relying party must:
A counter does not always need to increase by exactly one. It must increase by a positive amount according to the authenticator’s design.
A credential returning zero may still provide phishing resistance and strong cryptographic authentication. It does not provide counter based clone detection. Those are not equivalent security states.
Synced and shared passkeys may offer convenience. Platform authenticators may strongly protect credentials. None of those benefits restores the relying party’s missing clone detection signal.
For ordinary users, an organization may decide that the tradeoff is acceptable. For the most sensitive identities in an enterprise, it should not be.