A one-time password is a short-lived authentication code used once, then discarded. It usually supplements a primary password as a second factor, but its security depends heavily on how the code is generated, delivered, and recovered if the user loses access.
What OTP Is and How It Fits Authentication
A one-time password is a short-lived code layered on top of a primary login factor, so its value depends on the whole authentication flow, not just the code itself. It can be a separate factor, a fallback path, or part of a passwordless journey, but each of those uses changes the security properties.
That means OTP is best understood as an authentication mechanism family rather than a single product feature. The same code pattern can support SMS-based second factor, app-based TOTP, email verification codes, hardware token output, or recovery flows, and each option has different failure modes, assurance, and operational burden.
How OTPs Are Generated and Delivered
Most OTP systems rely on either a shared secret and time or counter input, or on server-side generation and delivery. App-based codes generally offer stronger protection than SMS or email because they reduce dependence on carrier routing, inbox compromise, and message interception, but they still depend on secure enrolment and secret storage.
Delivery matters because the channel becomes part of the control. A code sent by SMS or email can be exposed through phishing, forwarding, SIM swap, message prefetching, or account takeover of the receiving channel, while a token or authenticator app shifts the risk toward device security and backup-code handling.
For a practical comparison of these methods, MFA Guide and Authenticator Apps and OTP Guide cover TOTP, HOTP, enrolment, seed handling, and the trade-offs between app-based and message-based codes.
Why OTPs Can Still Be Bypassed
OTP raises the cost of simple password theft, but it does not automatically stop account takeover. Attackers often target the code itself, the session after verification, or the recovery path, because those are usually easier to exploit than the underlying password.
Phishing kits can relay codes in real time, “push” fatigue can trick users into approving an unexpected challenge, and insecure recovery procedures can let an attacker replace the second factor after they have already compromised the first. That is why OTP should be treated as a control with specific bypass patterns, not as a guarantee of strong identity proof.
OTP security and Magic Links and Email OTP Security Guide show how relay attacks, code sharing, scanner breakage, and recovery weaknesses change the security of one-time codes in practice.
Operational Trade-Offs and Recovery Design
OTP creates a design choice between convenience and assurance. The more you simplify delivery and recovery, the more you risk weakening the control through predictable codes, broad resend logic, weak rate limits, or help desk-assisted bypasses. The more you harden it, the more you risk user friction and lockout when devices are lost or channels fail.
Recovery deserves the same attention as primary enrolment because it is often the easiest way around a strong second factor. Backup codes, device migration, and re-enrolment workflows should be tightly governed so that losing access to one factor does not silently turn into account takeover by social engineering.
Where OTP is only one part of a broader identity control stack, strong password policy and phishing-resistant alternatives matter too, especially for high-value accounts and support staff. Password Policy Guide (NIST-aligned) is useful because OTP is strongest when paired with good primary credential hygiene rather than used as a substitute for it.
Where OTP Fits in Modern Defences
OTP remains common because it is simple to deploy and broadly supported, but many organisations now reserve it for lower-risk scenarios, step-up challenges, or transitional deployments. The stronger the adversary model, the more the security conversation shifts toward phishing-resistant authentication and session protection rather than code entry alone.
That is especially true when the login journey is tied to cloud consoles, developer tools, and privileged access, where a stolen code can be enough to open the door to sensitive resources. In those settings, OTP is better viewed as one control within a layered authentication strategy than as the endpoint of identity security.
For real-world attack paths, Twilio 0ktapus breach 2022 and Dropbox GitHub breach 2022 illustrate how OTP compromise can become a wider exposure event when attacker access is followed by repository theft or credential rotation.
Risk and Threat Considerations
OTP is vulnerable where the code is not the only thing being trusted. If the delivery channel, recovery process, or session handoff is weak, an attacker can use a valid code to complete login, establish access, and then pivot to sensitive data or administrative functions.
Failure mechanism: Phishing relay, SIM swap, inbox compromise, or weak recovery lets the attacker capture or reuse the code in time to authenticate, while the victim believes the code protected the account.
Impact: Account takeover can lead to session theft, data exposure, privileged access abuse, or secret rotation work that arrives only after the attacker has already used the access.
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 OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | OTP is a user authentication method covered by organizational login controls. |
| IA-5 — Authenticator Management | OTP depends on issuing, protecting, rotating, and revoking authenticators and shared secrets. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | OTP is commonly used for external-user authentication flows and recovery steps. | |
| Recommendation — Require strong user authentication for workforce access and avoid weaker OTP paths where higher assurance is needed. Manage OTP seeds, tokens, backup codes, and recovery credentials through controlled lifecycle processes. Apply appropriate authenticator assurance for external users and align OTP strength to account risk. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The guidelines define authenticator assurance, phishing-resistant options, and OTP channel limits. |
| Recommendation — Use the guideline's authenticator assurance model to choose OTP only where its assurance level fits the use case. | ||
| OWASP ASVS | V6 — Authentication | OTP is an authentication control whose security depends on enrolment, delivery, and recovery design. |
| V7 — Session Management | OTP often protects session creation, and compromise can still occur after successful verification. | |
| Recommendation — Verify OTP enrolment, verification, rate limiting, and recovery requirements as part of authentication testing. Bind OTP success to secure session handling so authentication cannot be bypassed through weak session controls. | ||
Practitioner Guidance
Why practitioners should care: OTP is often deployed as if it were uniformly “strong,” but the actual assurance level depends on whether the code is app-based, SMS-based, email-based, or tied to a weak recovery path. Treat the method, channel, and fallback flow as part of the control design, not as interchangeable implementation details.
Common misunderstanding: A code that expires quickly is not automatically resistant to phishing or replay. The practical question is whether the attacker can obtain the code, race the legitimate user, or hijack the account through recovery and support workflows.
Practitioner takeaway: Use OTP intentionally, reserve weaker channels for lower-risk use cases, and review every recovery path as if an attacker is already trying to exploit it.
Related resources from NHI Mgmt Group
- What breaks when password management is treated as a one-time rollout instead of an ongoing control?
- What breaks when users cannot enter a one-time password before it expires?
- Why do regular backup routines matter more than a one-time export for self-hosted password and credential systems?
- What are the main failure points in one time password authentication for mobile access?
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 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org