HOTP is a counter-based one-time password algorithm that generates a code from a shared secret and an incrementing counter. It stays valid until used or invalidated, which makes synchronisation the main operational challenge and makes replay protection essential after verification.
How HOTP Works
HOTP is a shared-secret algorithm that turns a counter value into a short code, so the verifier and the user’s token or app must stay roughly in step. The security value comes from the secret plus the moving counter, but the operational cost is that each successful use changes state and every missed event can widen the gap.
Because the counter is part of the computation, HOTP behaves differently from time-based OTPs. A code is not "fresh" because the clock changed; it is valid because the expected counter still matches the next accepted value. That makes HOTP suitable for event-driven use, but it also means resynchronisation is part of the design rather than an edge case.
Why Synchronisation Matters
The main implementation issue is drift between the two counters. If a user generates one or more codes that are never presented, the server must decide how far ahead it will search, or the next legitimate login will fail. If the search window is too wide, the verifier accepts more candidate codes and weakens the effective replay window.
In practice, the best HOTP deployments treat synchronisation as a governed state problem: the verifier must track which counter was last accepted, support controlled resync when needed, and make it clear when a token has been used out of sequence. That is why HOTP is often discussed alongside authenticator app and OTP guidance, where backup handling and migration can also disturb expected state.
Security Properties and Limits
HOTP is a one-time password scheme, but the code is only one-time if the verifier enforces that property after a successful check. Without strict invalidation or counter advancement, the same code can be replayed while it remains within the acceptance window. The security assumption is therefore not just secrecy of the shared secret, but correct server-side state handling.
HOTP also inherits the limits of any shared-secret OTP design. If the seed is copied, exposed, or reused in multiple places, an attacker who learns it can generate valid codes until the secret is replaced. That is why deployment hygiene, secret protection, and recovery procedures matter as much as the algorithm itself.
Where HOTP Fits
HOTP is best understood as a counter-based authenticator rather than a general identity platform feature. It can still support strong authentication when deployed carefully, but it works best where the verifier can reliably maintain state and the token is used in a predictable sequence. Where synchronisation is hard, operational friction increases quickly.
For that reason, HOTP should be evaluated as part of the full authentication journey, not as a standalone code generator. The real question is whether the surrounding process can preserve counter alignment, rotate the shared secret when needed, and resist replay after verification.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | HOTP depends on secure lifecycle handling of shared OTP authenticators and counters. |
| Recommendation — Manage OTP authenticators so counters, seeds, and replacement procedures stay under control. | ||
| NIST SP 800-63 | Digital Identity Guidelines | HOTP is an authenticator type addressed by digital identity guidance for assurance and OTP use. |
| Recommendation — Use HOTP only where the authenticator and verifier state can meet the required assurance profile. | ||
| CIS Controls v8 | CIS-5 — Account Management | HOTP protects account authentication and must fit account issuance, recovery, and revocation processes. |
| Recommendation — Bind HOTP enrollment and recovery to managed account lifecycle controls. | ||
Related resources from NHI Mgmt Group
- How should security teams handle HOTP secret re-creation so user presence and user verification are both enforced?
- What is the difference between TOTP and HOTP for access control and user authentication?
- How should teams decide between TOTP and HOTP for step-up authentication in higher-risk applications?
- Why does HOTP create more brute-force risk than TOTP in authentication flows?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org