A moving factor is the changing input used to generate a one-time password. In TOTP, the factor is time. In HOTP, it is an event counter. The moving factor is what makes each code different, while the shared secret ensures both the user device and server can validate the same value.
What the moving factor does in one-time passwords
The moving factor is the changing value that keeps each OTP distinct. In TOTP, that value is time-based, so the code changes on a schedule; in HOTP, it is a counter that advances with each event, usually a successful authentication request.
This is what separates a one-time password from a static shared secret. The secret remains constant on both sides, while the moving factor changes the generated output in a predictable way that both the authenticator and verifier can reproduce.
For this reason, the moving factor is not the credential itself. It is the input that makes the code dynamic, while the secret is the material that binds the generator and validator to the same expected result.
How TOTP and HOTP use it
In NIST SP 800-63 Digital Identity Guidelines, the distinction matters because the verifier must know which moving factor model is in use before it can validate the code. A time-based code depends on clock alignment and acceptable drift, while a counter-based code depends on both sides advancing the counter consistently.
That difference changes the operational behaviour of the token. TOTP is simpler for users because it does not require an event to advance the value, but it is sensitive to time synchronisation. HOTP avoids clock dependency, but it can fall out of sync if one side increments the counter differently from the other.
The same core mechanism is described in NIST SP 800-63B and in the OWASP Cheat Sheet Series, both of which treat OTP validation as a coordinated process, not just a code lookup.
Security implications of the moving factor
The moving factor is what prevents a captured OTP from being reused unchanged. Because the input changes, the same shared secret produces a new code at the next step, which reduces the value of replay and limits the lifetime of any exposed code.
That protection only works if the verifier correctly enforces freshness. If time windows are too wide, or if counter resynchronisation is too permissive, an attacker gets more opportunity to replay a captured code before it expires.
Moving-factor design also affects usability and resilience. Tight time windows improve short-lived code protection, but they can increase false rejects when device clocks drift. Counter-based systems avoid clock issues, but they can create recovery and synchronisation problems after skipped events or failed deliveries.
Risk and Threat Considerations
OTP systems fail when the moving factor is weakly controlled, because a valid code can be accepted for too long, resynchronised too loosely, or generated from a device that is no longer trustworthy. The security issue is not the concept itself, but the verification window, clock integrity, and counter handling that determine whether the code is still fresh.
Failure mechanism: Attackers exploit replay opportunities, clock drift, or counter desynchronisation to extend the usefulness of a stolen OTP or to trigger acceptance of an outdated code.
Impact: The result can be account compromise despite the presence of OTP, especially when the code is phished, intercepted, or reused within an overly generous acceptance window.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while 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-63 | 5.1.4 — Look-Up Secrets | Defines OTP authenticators using a moving factor and shared secret. |
| 5.1.7 — Multi-Factor One-Time Passwords | Covers OTP authenticators that rely on time or counter moving factors. | |
| Recommendation — Validate OTP implementations against the moving-factor model and restrict acceptance windows to limit replay. Use OTP guidance to verify synchronisation, freshness, and verifier checks for TOTP or HOTP. | ||
| CIS Controls v8 | 6.3 — User Account Management | OTP moving factors support account access controls and authentication safeguards. |
| Recommendation — Enforce strong authentication controls and review account access paths that rely on OTP validation. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | OTP systems depend on secret material combined with a moving factor to generate codes. |
| Recommendation — Protect OTP secrets and rotation processes so the moving factor cannot be abused with stale material. | ||
Practitioner Guidance
What to watch for: Treat the moving factor as a verifier control point, not just a token detail. The practical question is whether your implementation keeps the validation window narrow enough to limit replay while still tolerating ordinary drift or synchronisation error.
Common misunderstanding: A code changing over time does not automatically make the scheme resistant to interception or phishing. The protection comes from the freshness check plus the binding between the secret, the moving factor, and the server’s acceptance logic.
Practitioner takeaway: If the factor is time-based, monitor clock synchronisation and drift handling; if it is counter-based, monitor resynchronisation behaviour and recovery paths.
Related resources from NHI Mgmt Group
- What was the common factor in the Snowflake, BeyondTrust, OmniGPT, and DeepSeek breaches?
- Why is identity such a critical factor in securing AI agent systems?
- Should organisations modernise ERP governance before moving systems to cloud applications?
- What is the difference between a low-assurance recovery question and a strong recovery factor?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
