Authentication failures account for a substantial share of data breaches every year, and static passwords are a primary culprit. A one-time password (OTP) — sometimes called a one-time passcode — addresses this directly by generating a code that works exactly once and then becomes worthless. Whether you have received a six-digit code via SMS before logging into your bank, or used an authenticator app to access a work VPN, you have already encountered OTP in practice.
This article explains what OTP means, how the underlying algorithms generate codes, the two main standards (HOTP and TOTP), every delivery method available, and the security trade-offs that most explainers skip. It also covers real-world use cases across banking, healthcare, and enterprise access, and answers the most common questions about OTP codes.
What Is an OTP? (Definition)
An OTP — one-time password or one-time passcode — is an automatically generated string, usually 4 to 8 digits, that is valid for a single authentication session or transaction. Once used, or once its expiry window closes, the code is permanently invalid.
This stands in direct contrast to a static password, which a user creates, remembers, and reuses across many sessions. Static passwords can be stolen, leaked in data breaches, guessed through brute force, or reused across sites. An OTP eliminates all of those vectors: even if an attacker intercepts the code, it is already expired or consumed by the time they attempt to use it.
The code is generated by an algorithm running on a server (or a hardware device), delivered to the user through a trusted channel, submitted during authentication, and then validated by the server against its own calculation of what the correct code should be at that moment.
A Quick Note on the Other OTP
In internet slang, OTP also stands for One True Pairing — a term used in fan communities to describe a favorite fictional couple. That meaning has no connection to cybersecurity. This article covers only the authentication meaning.
How Does a One-Time Password Work?
The process follows a predictable sequence regardless of which delivery channel is used.
- User initiates access. You enter your username and static password (or just your email) on a login page.
- Server triggers OTP generation. The authentication server runs an algorithm — either counter-based or time-based — using a shared secret seed combined with either an incrementing counter value or the current Unix timestamp.
- Code is delivered. The generated code is sent to you via SMS, email, authenticator app, or another channel.
- User submits the code. You enter the code into the verification field within the valid window (typically 30 to 300 seconds, depending on the implementation).
- Server validates. The server independently calculates what the correct code should be at that moment and compares it to what you submitted. If they match within the allowed window, access is granted.
- Code is invalidated. Whether you succeed or fail, the code cannot be used again. The counter increments or the time window closes.
The core security property here is that the code is derived, not stored. Neither the server nor the user’s device stores the actual OTP — both sides compute it independently from the shared secret. An attacker who intercepts the code after step 4 has nothing useful.
Pro tip: If you are evaluating OTP for a business deployment, check whether your authentication provider supports look-ahead windows for HOTP (allowing for a small counter drift) or time-step tolerance for TOTP. A tolerance of ±1 step is standard and prevents lockouts from clock skew without meaningfully weakening security.
Types of OTP: HOTP vs TOTP
Two standards dominate OTP implementation, both defined by the IETF.
HOTP (HMAC-Based One-Time Password) is defined in RFC 4226 and uses an incrementing counter as its moving factor. Each time a code is generated, the counter advances by one. The server and the token must stay synchronized on the counter value.
TOTP (Time-Based One-Time Password) is defined in RFC 6238 and replaces the counter with the current Unix time divided into 30-second intervals. Both the server and the client calculate the same code independently as long as their clocks are synchronized.
| Criteria | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Moving factor | Incrementing counter | Current timestamp |
| Code validity | Until used or resynchronized | 30-second window (standard) |
| Clock dependency | None | Requires clock synchronization |
| Replay risk | Higher if counter drifts | Lower — window expires automatically |
| Common use today | Hardware tokens, older systems | Authenticator apps, most modern 2FA |
| Typical code length | 6–8 digits | 6 digits |
TOTP is the dominant standard today. Apps like Google Authenticator and Authy implement TOTP. The 30-second expiry window makes replay attacks impractical in most threat models, and clock synchronization is trivially maintained on smartphones and servers.
HOTP remains relevant in hardware tokens that have no reliable time source — a physical key fob that generates a new code each time you press a button is typically HOTP.
How to Receive an OTP Code: Delivery Methods
The algorithm generates the code; the delivery channel gets it to you. Each method carries different security and usability trade-offs.
SMS and Voice Call
SMS is the most widely deployed OTP delivery method globally. The server sends a text message containing the code to your registered phone number. Voice call delivery works the same way but reads the code aloud — useful for users without reliable SMS access or with visual impairments.
Trade-off: SMS is convenient and requires no app installation, but it is the weakest delivery channel from a security standpoint. SS7 protocol vulnerabilities allow sophisticated attackers to intercept SMS messages in transit, and SIM-swap fraud — where an attacker convinces a carrier to transfer your number to their SIM — redirects all your SMS OTPs to them. NIST’s Digital Identity Guidelines (SP 800-63B) explicitly classifies SMS-based OTP as a restricted authenticator type due to these risks.
The server sends the OTP to your registered email address. Email OTPs typically have longer expiry windows — 10 to 15 minutes is common — because email delivery is less instantaneous than SMS.
Trade-off: Security depends entirely on your email account’s own security. A compromised email account defeats the purpose of the second factor.
Authenticator App (Soft Token)
Apps generate TOTP codes locally on your device using a shared secret established during initial setup (usually via QR code scan). No network connection is required to generate codes after setup.
This is the recommended method for most users and organizations. Codes are generated on-device, never transmitted until you type them in, and expire every 30 seconds. A team of 50 employees using app-based OTP for VPN access faces a dramatically smaller attack surface than the same team using SMS.
Hardware Token (Hard Token)
A physical device — typically a key fob — displays a rolling OTP code. These are HOTP or TOTP devices with no network connectivity, common in financial services and government environments where mobile phones are restricted.
Trade-off: Hardware tokens have to be bought for each user, require physical distribution, and create a support burden when lost. For high-security environments, the cost is justified.
Common mistake: Organizations often deploy SMS OTP for high-value transactions — wire transfers, admin access, healthcare records — because it is the easiest to implement. For those scenarios, app-based or hardware OTP is the appropriate choice. SMS is acceptable for lower-risk flows like e-commerce checkout verification.
Push Notification
The authentication server sends a push notification to a registered mobile app. You approve or deny the login with a single tap. This is technically not a traditional OTP (no code to type), but it achieves the same goal and is increasingly common in enterprise identity platforms.
Why Is OTP Secure? Benefits of One-Time Passwords
OTP addresses four specific attack vectors that plague static passwords:
Replay attacks: An attacker who captures your OTP during transmission cannot reuse it. The code is already consumed or expired.
Credential stuffing: Attackers who obtain username/password pairs from breached databases cannot access accounts protected by OTP without also controlling the OTP delivery channel.
Phishing resistance (partial): A phished static password gives an attacker indefinite access. A phished OTP gives them a 30-second window — which is still exploitable via real-time phishing proxies, but significantly harder to operationalize at scale.
No stored secrets on the user side: Users do not create or remember OTPs. There is no password to reuse across sites or write on a sticky note.
OTP vs. 2FA vs. MFA
These terms are frequently confused. OTP is a type of authentication factor — specifically, a “something you have” or “something you receive” factor. Two-factor authentication (2FA) is a framework requiring two distinct factor types. Multi-factor authentication (MFA) requires two or more. An OTP used alongside a password is one implementation of 2FA, but 2FA can also use biometrics, hardware keys, or other methods.
Limitations and Vulnerabilities of OTP
No authentication method is without weaknesses, and OTP has several worth understanding before deployment.
SS7 attacks: The SS7 (Signaling System 7) protocol underpins global telephone network routing and has known vulnerabilities that allow attackers with access to telecom infrastructure to intercept SMS messages. Documented attacks against banking customers have used SS7 interception to steal SMS OTPs.
SIM-swap fraud: An attacker calls your mobile carrier, impersonates you, and convinces a representative to transfer your phone number to a new SIM card they control. All subsequent SMS OTPs go to the attacker. This attack requires social engineering rather than technical skill, making it accessible to lower-sophistication threat actors.
Real-time phishing proxies: Automated tools can sit between a user and a legitimate site, forwarding credentials and OTPs in real time. The attacker’s proxy submits the OTP to the real site within the valid window. This defeats SMS and app-based OTP equally.
Social engineering: Attackers call targets, impersonate bank fraud departments, and ask victims to read back the OTP they just received. This is a common fraud vector requiring no technical capability.
Device theft: If your OTP is delivered to a phone without a lock screen, physical theft grants access to all SMS and app-based codes.
For high-security deployments — admin access, financial transactions, healthcare portals — hardware tokens or FIDO2 passkeys are more appropriate than SMS OTP. For lower-risk flows, SMS OTP is a reasonable and practical choice.
Common Use Cases for OTP Codes
OTP messages appear across nearly every industry that handles sensitive data or financial transactions.
Online banking and card activation: Banks send OTPs to verify high-value transactions, new payee additions, and card-not-present purchases. A typical implementation requires OTP confirmation for any transfer above a defined threshold.
E-commerce checkout: Payment processors use OTP as part of 3D Secure authentication to verify the cardholder during online purchases, reducing chargeback fraud.
Government and healthcare portals: Patient portals, tax filing systems, and benefits platforms use OTP to meet regulatory requirements for identity verification. NIST SP 800-63B provides the federal baseline for these implementations.
Employee remote access (VPN): Organizations require OTP as the second factor for VPN login. A 200-person company with remote employees typically enforces app-based TOTP for all VPN sessions.
Account registration and onboarding: Services send an OTP to a new user’s phone or email to verify ownership of the contact information during signup — distinct from ongoing authentication.
Password reset flows: Rather than security questions, most modern platforms send an OTP to verify identity before allowing a password change. Password reset is a common account takeover vector, making this one of the most critical OTP use cases.
Frequently Asked Questions
What does OTP stand for? OTP stands for one-time password or one-time passcode. In internet slang it also means One True Pairing, but in any security or authentication context, it refers to a single-use authentication code.
What is an OTP code used for? OTP codes verify your identity during login, transactions, account registration, and password resets. They serve as a second authentication factor alongside your primary password.
How do I get an OTP code? You receive an OTP via SMS, email, an authenticator app (like Google Authenticator or Authy), a hardware token, a voice call, or a push notification, depending on what the service supports and what you have configured.
How long is an OTP valid? TOTP codes generated by authenticator apps are valid for 30 seconds. SMS and email OTPs typically have longer windows — 5 to 15 minutes — set by the service. Hardware token HOTP codes are valid until used, regardless of time.
Can someone steal my OTP code? Yes. SMS OTPs are vulnerable to SS7 interception and SIM-swap attacks. Any OTP can be stolen through phishing, social engineering, or device theft. App-based and hardware OTPs are significantly harder to steal than SMS codes.
What is the difference between HOTP and TOTP? HOTP uses an incrementing counter as its moving factor and is valid until used. TOTP uses the current timestamp and expires after 30 seconds. TOTP is the more common standard in modern authenticator apps.
What is the difference between an OTP and 2FA? OTP is a type of authentication code. 2FA (two-factor authentication) is a security framework requiring two distinct factors. An OTP used alongside a password is one implementation of 2FA, but 2FA can also use biometrics, hardware keys, or other methods.
What are OTP messages? OTP messages are the SMS texts, emails, or push notifications that deliver your one-time code. The message typically contains the code, a brief instruction, and a warning not to share it — a standard format used by banks, apps, and platforms globally.
Conclusion
A one-time password is one of the most practical and widely deployed tools in digital authentication. It solves the core weakness of static passwords — reusability — by generating a code that expires in seconds or minutes and cannot be used twice. Whether delivered via SMS, email, authenticator app, or hardware token, the underlying principle is the same: the code is computed, not stored, and worthless after its window closes.
The limitations are real, particularly for SMS-based delivery. SS7 vulnerabilities and SIM-swap fraud mean that SMS OTP should not be the sole protection for high-value accounts. For those scenarios, authenticator apps or hardware tokens provide meaningfully stronger security.
The broader trajectory is toward app-based TOTP and passkeys for everyday authentication — methods that eliminate the delivery channel as an attack surface entirely. Understanding where OTP fits in that landscape helps you make better decisions about which authentication methods to use and trust.