OTP and TOTP are one-time codes used to verify a user or system for a single login or transaction. OTP means a password valid only once. TOTP means time-based OTP, where the code changes at fixed intervals using a shared secret and the current time, strengthening authentication against reuse.
What OTP and TOTP actually do
One-time passwords are short-lived authentication codes that are valid for a single use, which makes them more resilient than static passwords when a login or transaction is being verified. totp adds a time factor so the code changes at fixed intervals, which helps reduce the value of a reused or intercepted code.
OTP is a broad mechanism, while TOTP is the most common timed variant used in authenticator apps and hardware tokens. The security value comes from limiting replay, not from making the code secret forever.
How OTP and TOTP are generated and verified
TOTP is based on a shared secret and the current time, so both the client and the verifier can independently derive the same code for a narrow time window. That design means the server does not need to transmit a password that can be reused later, but it does require careful secret handling and clock tolerance.
In practice, deployment details matter. Enrollment normally starts with a QR code or provisioning flow, and the shared secret becomes the root of trust for every future code that app or token generates. If that secret is copied, stolen, or reused across systems, the protection becomes much weaker than the acronym suggests.
Where OTP and TOTP are strong, and where they are weak
OTP and TOTP are useful against password reuse and many simple replay attempts, but they are not phishing-resistant by themselves. An adversary who can proxy a live login, trick a user into revealing a code, or steal the underlying shared secret can still defeat the factor.
They are also sensitive to operational edge cases. Time drift, backup code handling, app migration, and seed storage failures can all create support issues or weaken assurance. For that reason, TOTP should be treated as a compensating factor in a broader authentication design, not as a universal substitute for stronger methods.
OTP and TOTP in modern authentication design
OTP and TOTP often sit between basic password checks and stronger phishing-resistant methods such as security keys or passkeys. They remain widely deployed because they are simple, interoperable, and inexpensive to roll out, especially for legacy applications that cannot yet support stronger authenticators.
When organisations keep OTP or TOTP in the stack, they should think about the whole lifecycle of the shared secret, the recovery path, and the conditions under which the factor can be bypassed. The practical question is not only whether a code is generated, but whether the enrollment, storage, and verification steps preserve the assurance that the factor is supposed to add. For a deeper comparison of deployment patterns and bypass risks, see the MFA Guide and the Authenticator Apps and OTP Guide.
Risk and Threat Considerations
OTP and TOTP reduce password replay risk, but they still depend on the secrecy of the shared seed and on the user entering the code into the right system. That creates exposure to phishing, adversary-in-the-middle interception, seed theft, and weak recovery processes that can undermine the second factor even when the login flow looks healthy.
Failure mechanism: Attackers capture or proxy the live code, or they steal the TOTP seed during enrollment, backup, or device migration and then generate valid codes independently.
Impact: The account can be accessed without the user’s approval, and the organisation may lose confidence in the factor even if the password itself was never reused.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-63, OWASP ASVS 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 | OTP and TOTP rely on authenticator lifecycle and shared-secret handling. |
| Recommendation — Manage OTP and TOTP secrets through issuance, renewal, revocation, and secure storage. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | TOTP is an authenticator choice within digital identity assurance and enrollment. |
| Recommendation — Assess whether the authenticator meets the required assurance level for the transaction. | ||
| OWASP ASVS | V6 — Authentication | OTP and TOTP are authentication mechanisms that must be verified for strength and usability. |
| Recommendation — Verify that the application enforces strong multi-factor authentication and resists code replay. | ||
| CIS Controls v8 | CIS-5 — Account Management | OTP and TOTP depend on secure account enrollment, recovery, and deprovisioning processes. |
| Recommendation — Control account lifecycle and recovery paths so authenticator changes do not create bypasses. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | TOTP seeds are secret material whose exposure defeats the one-time code model. |
| Recommendation — Protect TOTP seeds from disclosure in provisioning, storage, backup, and migration flows. | ||
Practitioner Guidance
Why practitioners should care: OTP and TOTP are often the last line between a stolen password and a successful account takeover, so their real value depends on how well the enrollment and recovery process is controlled. Treat the shared secret as sensitive authentication material, because weak handling there can quietly collapse the protection the code is meant to provide.
Common misunderstanding: A time-based code is not automatically phishing-resistant. If a user can be induced to read the code to an attacker in real time, the factor still fails in the exact scenario many teams assume it prevents.
Related resources from NHI Mgmt Group
- What do organisations get wrong about TOTP setup and OTP entry?
- What is the difference between TOTP and alternative OTP in two-factor authentication setups?
- What is the difference between TOTP, SMS OTP, email OTP, and certificate-based 2FA for user authentication?
- Why can SMS and OTP-based MFA still be attacked?
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 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org