Category: Multi-Factor Methods

One-Time Password

Also known as: OTP, One-Time Passcode, One-Time PIN

Simply put

A one-time password (OTP) is a temporary code that works only once and usually expires after a short period, used to help verify a user's identity when they sign in or complete an action. It is often delivered to something the user has, such as a phone via SMS, an email address, or a dedicated authenticator app. Because each code is valid for a single use, an OTP is harder for an attacker to reuse than a static, reusable password.

Formal definition

A one-time password (OTP) is a single-use authentication credential, typically valid for one login session, transaction, or action and often constrained to a short validity window. It generally functions as a possession-factor proof: the code is either generated by or delivered to a device or channel associated with the user (for example an authenticator app, SMS, or email), so that presenting the correct code demonstrates control of that channel. In practice OTPs are most commonly deployed as one factor within multi-factor or two-factor authentication rather than as a standalone authenticator, and they address authentication (verifying identity) rather than authorization. Specific generation and delivery mechanisms, algorithms, code length, and expiry behavior vary by implementation; details beyond what the cited sources establish are out of scope for this entry.

Why it matters

Static, reusable passwords remain one of the weakest links in identity systems: once captured through phishing, credential stuffing, or a database breach, they can be replayed by an attacker indefinitely until rotated. A one-time password mitigates this specific weakness because each code is valid only once and, in most deployments, only for a short window. Even if an OTP is intercepted or observed, its usefulness to an attacker degrades quickly, which raises the cost of straightforward credential-replay attacks.

OTPs matter most as a second factor within two-factor or multi-factor authentication rather than as a replacement for the primary credential. By binding a login or transaction to something the user has, a device or channel that receives or generates the code, an OTP adds a possession-factor check on top of a knowledge factor such as a password. This layering is why OTP-based verification is common for high-value actions like signing in from a new device, authorizing a payment, or confirming a sensitive account change.

It is important to recognize that OTPs address authentication only: they help verify identity but do not determine what an authenticated user is permitted to do, which remains an authorization concern. The strength an OTP provides also depends heavily on its delivery channel and implementation; the security properties of SMS delivery, email delivery, and app-generated codes differ, and the details of those tradeoffs are beyond the scope of this entry.

Who it's relevant to

IAM Engineers and Architects

Engineers designing authentication flows use OTPs as a possession factor within MFA or 2FA, deciding where a code is required, new-device sign-in, sensitive transactions, or step-up scenarios, and selecting delivery channels. They should treat OTP verification as one step in an authentication sequence and weigh the differing security properties of SMS, email, and authenticator-app delivery when configuring flows.

Security Architects

Architects evaluating credential strategy consider OTPs as a mitigation against static-password replay, while recognizing that an OTP addresses authentication and not authorization. They assess how OTP-based factors fit alongside other authentication methods and account for the fact that the assurance an OTP provides depends on its delivery channel and implementation.

Compliance and Audit Teams

Compliance officers and auditors reviewing access controls often need to confirm that a second factor, such as an OTP, is enforced for sensitive logins and transactions. They should document which actions require OTP verification and understand that OTP presence alone speaks to identity verification, not to what a user is authorized to access.

System Administrators

Administrators operating identity platforms configure and support OTP delivery for end users, including handling channel choices and expiry behavior that vary by implementation. They manage day-to-day issues such as codes expiring within their short validity window and users needing an alternate factor when a delivery channel is unavailable.

Inside OTP

HOTP (HMAC-based One-Time Password)

An event-based OTP algorithm that derives each code from a shared secret and an incrementing counter. Because the counter advances per generated code, verifiers typically tolerate a look-ahead window to handle codes generated but not consumed.

TOTP (Time-based One-Time Password)

A time-based variant that replaces the HOTP counter with the current time divided into fixed steps (commonly 30 seconds). Verification typically accepts a small window of adjacent time steps to accommodate clock drift between the generator and validator.

Shared secret (seed)

A symmetric key provisioned to both the generator (authenticator app or hardware token) and the validating service. Its confidentiality is essential, since anyone holding the seed can produce valid codes.

Possession factor role

In most deployments an OTP evidences the possession factor, since it demonstrates control of the device or token holding the seed. It is one factor and, on its own, does not constitute multi-factor authentication.

Delivery channel

OTPs may be generated locally (authenticator app, hardware token) or delivered out-of-band (SMS, email, voice). The channel materially affects the security properties, with out-of-band delivery generally exposing additional interception risks.

Code lifetime and single use

An OTP is intended to be valid only once and, for time-based variants, only within a short validity window, after which it should be rejected by the validator.

Common questions

Answers to the questions practitioners most commonly ask about OTP.

Does an OTP by itself provide multi-factor authentication?

No. An OTP is a single credential, and on its own it typically represents only one factor. Whether it counts toward MFA depends on how it is delivered and combined. A TOTP generated by an authenticator app or hardware token is generally treated as a possession factor, and it constitutes MFA only when paired with another factor of a different category, such as a knowledge factor (password) or an inherence factor (biometric). Using an OTP as the sole authentication step is single-factor authentication, not MFA.

Is verifying an OTP the same as authorizing what a user can do?

No. Validating an OTP is part of authentication, which establishes that the principal is who they claim to be. It does not determine what that principal is permitted to access. Authorization is a separate step that, depending on the deployment, is evaluated against an access control model such as RBAC or ABAC after authentication succeeds. A successful OTP check confirms identity for that authentication event and says nothing about entitlements.

How should we choose between HOTP (counter-based) and TOTP (time-based) OTPs?

The choice typically depends on your synchronization model and operational tolerances. TOTP relies on synchronized clocks between the generator and validator, so deployments usually configure a validation window to tolerate clock drift. HOTP relies on a shared counter, and validators commonly allow a look-ahead window to resync when the client and server counters diverge. In most modern deployments TOTP is more common, particularly with authenticator apps, but the appropriate option depends on your device constraints, connectivity, and vendor support. Confirm which variants your IdP and token supply support before standardizing.

What are the security limitations of delivering OTPs over SMS or email?

OTPs delivered over SMS or email are subject to interception and social-engineering risks such as SIM swapping, number porting attacks, and mailbox compromise, because the delivery channel is generally outside your direct control. They also remain phishable, since an attacker who relays a valid OTP in real time can complete authentication. Depending on your threat model and any applicable compliance requirements, you may need to treat these channels as lower assurance and consider app-based or hardware-based OTPs, or move to phishing-resistant methods where appropriate. Out of scope here are the specific assurance-level classifications, which vary by the framework you follow.

How do we handle OTP validation windows and replay protection?

For TOTP, deployments typically configure a small acceptance window spanning one or more time steps to accommodate clock drift, balancing usability against exposure. For HOTP, a look-ahead window handles counter divergence. To limit reuse, many implementations reject an OTP that has already been accepted within its validity period, effectively enforcing single use per code. The exact window sizes, drift tolerances, and replay-tracking behavior depend on vendor configuration, so validate the defaults and document the values you set.

How does OTP relate to passwordless and phishing-resistant authentication approaches?

OTPs can serve as one factor in an MFA flow or as a step-up factor for sensitive actions, but they are generally not considered phishing-resistant because a code can be relayed to an attacker who is proxying the login. Passwordless is a broader design goal, and using an OTP in place of a password does not by itself make an approach phishing-resistant. Where resistance to real-time phishing is required, credentials such as those based on FIDO2 and WebAuthn are typically preferred, though whether they fit depends on your device support and deployment context. Positioning OTPs as a bridge or fallback rather than the strongest available method is a common pattern.

Common misconceptions

OTP and MFA are the same thing.

An OTP is a single authentication factor, typically evidence of possession. It contributes to multi-factor authentication only when combined with a factor of a different type, such as a knowledge or inherence factor. An OTP used alone is single-factor authentication.

OTP verifies who the user is, so it handles authentication end to end.

An OTP is one input to the authentication step; it demonstrates control of a seed or device. Identification and authorization remain separate steps, and OTP by itself says nothing about what the authenticated principal may do.

SMS-delivered OTP is equivalent in security to an app- or hardware-generated OTP.

Delivery channel changes the risk profile. Out-of-band delivery such as SMS is generally more exposed to interception and social-engineering attacks than locally generated codes, though the exact exposure depends on deployment context.

Best practices

Prefer locally generated OTPs (authenticator app or hardware token) over out-of-band SMS or email delivery where the threat model and user base allow, given the greater interception risk of shared channels.

Protect the shared secret throughout its lifecycle: provision it over a secure channel, store it securely on both sides, and treat seed compromise as equivalent to compromise of the factor.

Enforce single-use and short validity windows, rejecting reused codes and, for TOTP, tuning the accepted time-step window narrowly enough to limit exposure while accommodating reasonable clock drift.

Combine OTP with a factor of a different type (knowledge or inherence) when the goal is multi-factor authentication, rather than treating OTP alone as MFA.

Keep OTP scoped to the authentication step and rely on separate authorization mechanisms to determine access, avoiding any assumption that a valid OTP implies entitlement.

Where stronger phishing resistance is required, evaluate whether OTP meets the threat model, since OTP codes can typically be relayed to an attacker in real time; document this limitation for stakeholders.