One-time passwords still matter, but only as a fallback factor

At a glance

What this is: This is a practitioner-focused explainer of one-time passwords, showing that OTPs improve MFA resilience but are now best treated as a fallback rather than a primary control for sensitive access.

Why it matters: It matters because identity teams still rely on OTPs in employee, partner, and customer flows, and they need to understand where OTPs fit alongside passkeys, risk signals, and modern IAM assurance decisions.

👉 Read Ping Identity's guide to one-time passwords and MFA

Context

One-time passwords are single-use codes that add a second factor to password-based login flows. In practice, the key issue is not whether OTPs work, but where they still provide enough assurance for IAM programmes that now have stronger options.

OTP remains relevant for compatibility, low-risk access, and recovery flows, but it is no longer the right primary control for every sensitive journey. For identity teams, the decision is increasingly about whether OTP is an acceptable fallback or a control that should be replaced by passkeys, biometrics, or risk-based authentication.

Key questions

Q: How should security teams use OTP without creating avoidable risk?

A: Use OTP as a compatibility or fallback factor, not as the primary assurance method for sensitive access. Reserve weaker delivery channels for low-risk use cases, and prefer authenticator apps, passkeys, or adaptive MFA for anything that would be costly to lose. The goal is to match the factor to the risk, not to standardise on one code type everywhere.

Q: When does OTP become the wrong control choice?

A: OTP becomes the wrong choice when the access path is high-risk, attacker pressure is likely, or the organisation can support phishing-resistant alternatives. If the business action involves sensitive data, privileged administration, or repeated fraud exposure, a single-use code is usually not enough assurance on its own.

Q: What do teams get wrong about SMS and email OTP?

A: Teams often assume the code itself is the control, when the real weakness is the channel carrying it. SMS and email can be intercepted, redirected, or abused through account recovery abuse, so they should not be treated as equivalent to device-bound methods. Their convenience is real, but so is their lower assurance.

Q: How do organisations decide whether OTP is still acceptable?

A: Decide by use case, not by habit. If the journey is low risk, legacy-dependent, or recovery-oriented, OTP may remain acceptable with clear policy limits. If the journey is sensitive, privileged, or exposed to phishing, move to stronger methods and require adaptive signals before granting access.

Technical breakdown

How OTP generation and expiry shape assurance

OTP systems generate a unique code for one login session or transaction and invalidate it after use or after a short window. Time-based OTPs use the current timestamp, while event-based OTPs use counters and shared secrets. That short lifetime reduces replay risk, but it does not remove the dependence on delivery channel security or user-device trust. The control protects best when the code is bound to a separate device or secure app, and weakest when the transport path is exposed to interception or account takeover.

Practical implication: treat OTP lifespan and delivery path as part of the control design, not just the code format.

SMS, email, and authenticator app OTP are not equivalent

Delivery channel matters more than many teams admit. SMS and email OTPs are convenient but inherit the weaknesses of mobile carrier processes, mailbox compromise, and message interception. Messaging apps improve transport encryption, but they do not change the underlying exposure of out-of-band codes. Authenticator apps are stronger because they generate codes locally on the user device, reducing dependence on external delivery channels. Hardware keys add another layer by keeping code generation offline. The result is a spectrum of assurance, not a single OTP category.

Practical implication: classify OTP delivery methods by assurance level and reserve weaker channels for lower-risk flows.

Why OTP is being demoted by passkeys and adaptive MFA

OTPs were designed for a world where passwords were the main control and a second factor was enough to close the gap. That assumption is under pressure because modern phishing can proxy credentials in real time, and attackers can exploit SIM swaps or mailbox access to intercept codes. Passkeys reduce that exposure by binding authentication to cryptographic keys on a device, while adaptive MFA adds contextual signals before access is granted. OTP still has value, but mainly as a compatibility layer or recovery factor in lower-risk use cases.

Practical implication: move high-risk journeys away from OTP-first design and toward phishing-resistant authentication.

Threat narrative

Attacker objective: The objective is to turn a stolen password into a working authenticated session or approved transaction.

1. entry: The attacker starts with stolen or phished primary credentials and waits for the OTP challenge to be triggered.
2. escalation: The attacker attempts to intercept the one-time code through SIM swapping, mailbox compromise, or real-time phishing relay.
3. impact: The attacker completes authentication, bypasses the second factor, and gains access to the target account or transaction.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OTP is a control of diminishing assurance, not a universal second factor. One-time passwords still add value where the alternative is password-only access, but they no longer represent a stable endpoint for IAM design. Phishing-resistant methods and contextual signals have moved the assurance baseline, which means OTP should be treated as a compatibility or fallback control rather than the default answer to identity risk. Practitioners should align OTP use with the risk of the action, not the convenience of the channel.

The real security question is which delivery path you trust, not whether the code is single-use. A code that expires after one use still fails if the channel carrying it is vulnerable to interception or account recovery abuse. SMS and email OTP expose organisations to weaknesses outside the OTP algorithm itself, while authenticator apps reduce that exposure by staying on-device. The implication is that delivery architecture determines whether OTP adds meaningful assurance or just creates an impression of control.

Channel trust debt: OTP programmes accumulate risk when organisations keep weak delivery methods alive after stronger authentication is available. That debt is visible in legacy journeys, recovery flows, and low-risk exceptions that quietly become normalised. Over time, the control set can drift so far from the original threat model that OTP becomes a governance exception instead of an assurance choice. Practitioners should identify where the exception has become the standard.

Identity teams should stop treating OTP as a stand-alone MFA strategy. OTP remains useful inside layered authentication, but the market direction is clear: binding proof to a device, a cryptographic key, or real-time risk signals is now a stronger pattern for medium- and high-risk access. The teams that reduce OTP scope earliest will have less technical debt when they later standardise on passkeys and adaptive controls.

OTP policy is really lifecycle policy in disguise. Code expiration, device registration, recovery method selection, and fallback handling all create governance obligations that belong in IAM and lifecycle review, not just authentication configuration. If those choices are unmanaged, the organisation is not only using weaker authentication, it is also accepting unmanaged identity pathways. Practitioners should put OTP under the same governance lens they use for other access methods.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a persistent behaviour gap.
• For a broader control strategy, see Ultimate Guide to NHIs , Static vs Dynamic Secrets for how ephemeral credentials change the governance model.

What this signals

Channel trust debt: many organisations keep OTP alive because it is easy to deploy, not because it remains the best assurance choice. As passkeys and device-bound authentication mature, the programme risk shifts from authentication coverage to control rationalisation, and that is where IAM teams need to be deliberate.

The practical signal is simple. If your authentication stack still relies heavily on SMS or email OTP for anything above low-risk access, you are carrying legacy assurance debt that will show up during phishing testing, recovery reviews, and audit scrutiny. Start by mapping where those exceptions live and which journeys can move first.

For identity leaders, OTP strategy now sits alongside broader lifecycle and secrets governance. The teams that treat fallback factors as governed exceptions, not permanent architecture, will have a cleaner path to passkeys, adaptive authentication, and stronger access assurance.

For practitioners

• Restrict SMS OTP to low-risk fallback flows Keep SMS codes out of sensitive transactions and privileged journeys. Use them only where stronger factors are unavailable, and document the exception in your access policy so the fallback does not become the default.
• Prioritise authenticator apps or passkeys for higher-risk access Move employee, partner, and admin journeys to on-device factors that reduce interception risk. Where possible, pair authentication with device posture and risk signals so the factor choice matches the action being taken.
• Review OTP recovery paths as part of IAM lifecycle governance Audit account recovery, device replacement, and fallback enrolment because these are often the weakest points in OTP programmes. Make sure recovery methods are recertified with the same discipline as privileged access.

Key takeaways

• OTP still improves security over passwords alone, but it is no longer strong enough to be the default answer for sensitive access.
• Delivery method matters as much as the code itself, and SMS or email OTP should be treated as low-assurance fallback channels.
• The next step for IAM teams is to reduce OTP scope, favour device-bound authentication, and govern recovery paths with the same discipline as access policy.

Key terms

• One-Time Password: A one-time password is a single-use authentication code that expires after it is entered or after a short time window. It is designed to add a second factor to password-based access, but its security depends heavily on the delivery channel and the surrounding identity controls.
• Authenticator App: An authenticator app is a mobile application that generates or stores one-time codes on the user’s device. Because the code is produced locally, it reduces reliance on email or SMS delivery, but it still requires strong device security and careful recovery governance.
• Phishing-Resistant Authentication: Phishing-resistant authentication is a method that cannot be easily copied, relayed, or intercepted by an attacker during a live login flow. In modern identity programmes, this usually means device-bound cryptographic authentication rather than transferable codes sent over external channels.
• Adaptive MFA: Adaptive MFA uses contextual signals such as device posture, location, and user behaviour to decide whether extra authentication is needed. It improves assurance by evaluating risk at the moment of access, rather than assuming every login deserves the same factor combination.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Ping Identity: One-Time Passwords Explained: How They Work & Common Use Cases. Read the original.