HMAC-Based One-Time Password generates a short-lived code from a shared secret and a moving value such as time or a counter. The verifier computes the same code and checks it within an allowed window. Security teams should protect the seed, limit replay, and monitor for clock drift, resynchronisation, and brute-force attempts.
How HMAC-Based One-Time Passwords are generated and verified
HMAC-Based One-Time Password, usually called HOTP, is built from two inputs: a shared secret and a moving value, most often a counter. The authenticator and the verifier each compute an HMAC over those same inputs, then truncate the result to a short numeric code. Because both sides derive the same value independently, the code can be checked without sending the secret across the network.
The important security property is that the code is only valid for the specific moving value that was used to generate it. That means the secret seed is the real asset, while the displayed code is only a temporary proof derived from it. The system is simple, but it depends on the two sides staying synchronised on the counter state and on the seed remaining protected.
What makes HOTP secure, and where it can fail
HOTP security comes from message authentication, not from the code being random in isolation. If an attacker does not know the seed, they should not be able to predict the next valid code, even if they see previous ones. That is why seed compromise is far more serious than a single code capture: once the shared secret is exposed, the attacker can generate future valid codes until the seed is rotated.
Operational failure usually appears in three places. First, the counter can drift if one side accepts a code and the other side does not advance state as expected. Second, short numeric codes are brute-forceable if the verifier does not rate-limit attempts or track failures. Third, HOTP can be phished or relayed because the code is still a reusable bearer factor during its validity window. A good implementation therefore treats HOTP as one step in a broader authentication design, not as a complete control on its own. For a broader view of one-time password trade-offs and common bypass paths, see MFA Guide and the Authenticator Apps and OTP Guide.
HOTP also inherits risk from the credential supply chain around the seed. If the seed is stored badly, copied into logs, exported insecurely, or reused across systems, the cryptographic design can be sound while the deployment is still weak. That is why shared-secret handling, enrolment, backup, and recovery procedures matter as much as the code algorithm itself. The cryptographic primitive is only one layer; the protection of the secret decides the real assurance level, which is why the underlying HMAC construction is worth understanding in Cryptography Basics Guide.
Practical guidance for deploying HOTP without creating avoidable risk
What to verify: Confirm how the verifier advances the counter, how many counters it will search ahead to handle desynchronisation, and what happens after a failed attempt. If the implementation accepts a wide replay window or silently resynchronises too far ahead, the effective attack surface is larger than the code length suggests.
Decision rule: If the shared secret can authenticate to a valuable account or administrative function, rotate it immediately when compromise is suspected, even if no abuse is confirmed. If the seed is still safe but the counter state is unreliable, investigate state handling and device replacement before changing the factor design.
What good looks like: The seed is unique per user or device, recovery paths are controlled, failed attempts are rate-limited, and drift is visible in logs or help-desk telemetry. In practice, that means you can explain when a code was accepted, how far the counter moved, and whether repeated failures indicate user error or active guessing.
Practitioner takeaway: HOTP is secure only when the shared secret is tightly protected and the verifier enforces replay resistance, bounded resynchronisation, and attempt throttling. Treat seed handling and counter state as first-class controls, not implementation details.
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 and NIST SP 800-63 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 controlled lifecycle and protection of shared secrets. |
| IA-2 — Identification and Authentication (Organizational Users) | HOTP is an authenticator used to prove user identity during login. | |
| AC-7 — Unsuccessful Logon Attempts | HOTP verifiers must limit brute-force attempts against short codes. | |
| Recommendation — Manage OTP seeds with defined issuance, rotation, storage, and revocation controls. Require authenticated use of HOTP as part of user sign-in. Throttle repeated OTP failures and lock or delay suspicious authentication attempts. | ||
| NIST SP 800-63 | AAL2 — Authenticator Assurance Level 2 | HOTP commonly serves as an OTP authenticator within AAL2-style deployments. |
| Recommendation — Use HOTP only within an assurance model that matches its phishing and replay limitations. | ||
Related resources from NHI Mgmt Group
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 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org