A counter-based one-time password is a one-time code generated from a shared secret and an incrementing counter. Each new code depends on the next counter value, so the verifier must keep pace with the token’s counter state to authenticate the user or device.
How Counter-Based One-Time Passwords Work
A counter-based one-time password, often called HOTP, is generated from a shared secret plus a moving counter value. The verifier and token must stay in step, which is what makes each code usable only once in the intended sequence.
The security value comes from predictability only to the two parties that share the secret, while the counter prevents reuse of an old code after it has already been accepted. If the counter drifts, the verifier may reject a legitimate code until it resynchronises with the token state.
Why Counter State Matters
Unlike time-based codes, counter-based codes do not expire because the clock moves forward. They expire because the counter advances. That design helps in environments where time sync is unreliable, but it also means the verifier must track state carefully and tolerate small resynchronisation windows.
This statefulness is the key operational difference. If a token is cloned, reset, or used in parallel on more than one device, the counter can diverge and the system may either lock users out or accept a replay pattern if resynchronisation is handled poorly.
Where Counter-Based OTP Fits in Authentication
Counter-based OTP is commonly used as an additional authentication factor, especially with hardware tokens and older authenticator implementations. It can strengthen account security when paired with a password or another factor, but it is still a shared-secret mechanism and does not on its own stop phishing, relay, or theft of the underlying secret.
The important distinction is that the verifier validates possession of the secret and correct counter progression, not the user’s identity by itself. In practice, this makes HOTP a control for authentication assurance, not a complete defence against all account takeover paths.
For a broader comparison of OTP methods and their weaknesses, see Authenticator Apps and OTP Guide and MFA Guide.
Operational Limits and Failure Modes
Counter-based OTP works best when enrollment, device reset, backup, and recovery are tightly controlled. The main failure modes are desynchronisation, secret duplication, weak recovery processes, and overreliance on one-time codes where stronger phishing-resistant methods would be better.
Because the server must remember the last accepted counter position, implementation quality matters. A poorly designed resync process can let an attacker probe for valid codes, while a weak recovery flow can turn a lost token into an account recovery problem rather than an authentication problem.
For a practical view of how attackers target one-time codes in the real world, review OTP security and the breach pattern in Twilio 0ktapus breach 2022.
Risk and Threat Considerations
Counter-based OTP is attractive to attackers when the shared secret can be copied, the token can be replayed through a weak recovery flow, or the verifier accepts excessive counter drift. The main security risk is not the math of the code itself, but the trust placed in a secret plus state sequence that can be stolen, cloned, or desynchronised.
Failure mechanism: An attacker who learns the shared secret, intercepts an activation flow, or abuses resynchronisation can generate apparently valid codes and continue authentication until the secret or token state is replaced.
Impact: The result can be account takeover, repeated login abuse, lockouts from counter mismatch, or a longer detection window if the organisation treats OTP acceptance as stronger assurance than it really provides.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines OTP authenticators, verifier binding, and phishing-resistant assurance choices for this login factor. |
| Recommendation — Assess whether counter-based OTP meets the assurance level you need and prefer phishing-resistant authenticators where possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle handling for shared secrets and OTP authenticators used in authentication. |
| Recommendation — Manage OTP secrets and tokens with controlled issuance, replacement, revocation, and secure recovery. | ||
| OWASP ASVS | V6 — Authentication | Addresses authenticator design, OTP handling, and authentication assurance in application verification. |
| Recommendation — Verify OTP enrolment, verification, recovery, and failure handling under the authentication requirements. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Applies to protecting authentication secrets and their controlled use in identity verification. |
| Recommendation — Protect OTP secrets as authentication information and restrict how they are issued, stored, and recovered. | ||
| CIS Controls v8 | CIS-5 — Account Management | Supports secure account and authenticator lifecycle management, including recovery and removal of stale access. |
| Recommendation — Tie OTP enrollment and recovery to managed account lifecycle events and remove stale authenticators promptly. | ||
Practitioner Guidance
Why practitioners should care: Counter-based OTP is still useful where simple shared-secret authenticators are acceptable, but it needs explicit lifecycle ownership. The key decision is whether your risk model can tolerate a secret that is not phishing-resistant and a verifier that must maintain exact or near-exact state.
What to watch for: Repeated resynchronisation events, unexpected token resets, recovery tickets, and failed logins after device migration often reveal more about control weakness than about user error. Those signals usually mean the authentication flow, not the user, needs review.
Practitioner takeaway: Treat HOTP as a stateful authenticator with recovery and rotation responsibilities, not as a “set and forget” code generator.
Related resources from NHI Mgmt Group
- What is the difference between a time-based one-time password and a digital signature?
- Why does SMS-based one-time password delivery improve password reset security compared with knowledge questions alone?
- What risks does HMAC-Based One-Time Password reduce?
- How does HMAC-Based One-Time Password work?