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

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Ping Identity's blog post: OTPs still have value, but mainly as a fallback factor rather than the primary control for sensitive authentication journeys.

Why it matters: IAM teams should treat OTP as a compatibility and recovery control, not as the assurance layer for higher-risk employee, partner, or customer access where phishing-resistant methods are available.

Context

One-time passwords are single-use authentication codes that add a second factor to a password login, usually through a device or channel the user already has. The governance problem is not whether OTP works at all, but where it still provides enough assurance for the identity journey being protected, especially when phishing-resistant options are available.

For human identity programmes, OTP sits inside MFA design decisions about assurance, recovery, accessibility, and user friction. Ping Identity's article argues that teams should reserve OTP for lower-risk or compatibility scenarios and move sensitive actions toward passkeys, biometrics, and risk-based controls.

Key questions

Q: Should organisations replace passwords with OTPs everywhere?

A: Not automatically. OTPs reduce password storage burden and short-lived code reuse risk, but they do not solve device loss, delivery failure, inbox compromise, or phishing on their own. The better decision is to apply OTP where the user experience fits and where the organisation can tolerate the assurance level it actually provides.

Q: Why are SMS OTP codes considered weaker than authenticator apps?

A: SMS depends on the mobile network and phone number, so it is exposed to SIM swapping, message interception, and number takeover. Authenticator apps generate codes locally on the device, which removes the carrier from the delivery path and narrows the attack surface. That does not make them perfect, but it does make them materially harder to intercept remotely.

Q: What are the best practices for using OTP in MFA programmes?

A: Use OTP only where it fits the risk level, pair it with stronger factors for sensitive access, and document which journeys depend on each delivery method. OTP should be treated as part of a layered authentication policy, not as the default answer for every login or transaction. The strongest programmes reserve OTP for fallback and recovery.

Q: How do security teams decide if OTP is good enough for a login flow?

A: Compare the authentication method to the value of the account, the sensitivity of the action, and the likelihood of phishing or interception. If the journey involves admin rights, payment approval, or other high-impact activity, OTP alone is rarely sufficient. If the flow is low risk or legacy-bound, OTP may be acceptable as a transitional control.

Technical breakdown

Why OTP still reduces password theft impact

A one-time password is a single-use code that expires after one login session or transaction. That short lifetime matters because it prevents simple replay of a stolen static password and adds a second factor tied to a device or channel. In identity terms, OTP works as a compensating control when the primary secret is already exposed or legacy systems still depend on password-based entry. Its protection is real, but it is only as strong as the delivery path and the attacker model. If the code can be intercepted, phished, or redirected, the factor no longer provides the assurance teams assume.

Practical implication: Use OTP as a risk-reduction layer, not as proof that a password-based journey is adequately protected.

Why SMS and email OTP create weaker assurance than device-bound factors

SMS, email, and voice delivery all depend on external channels that can be hijacked, forwarded, or socially engineered. SMS is especially exposed to SIM swapping and message interception, while email OTP often inherits the security of the mailbox rather than the login itself. That means the factor may be separate from the password, but not necessarily separate from the attacker. By contrast, authenticator apps and hardware keys reduce channel exposure, and device-bound passkeys bind the authentication event to a local cryptographic credential. The technical difference is not convenience alone. It is the degree to which the factor resists phishing and remote interception.

Practical implication: Prefer device-bound authentication for sensitive journeys and restrict channel-based OTP to low-risk or recovery use cases.

How risk-based MFA changes OTP's role

Modern MFA increasingly uses contextual signals such as device posture, location, and behavioral patterns to decide whether a login should continue. In that model, OTP is no longer the destination control for sensitive access, but one input inside a broader risk decision. That shift matters because it changes the assurance question from 'Did the user enter a code?' to 'Is this authentication context acceptable for this action?' When the action is high risk, the code alone is not enough. The stronger pattern is to combine phishing-resistant factors with adaptive policy, so authentication strength matches the sensitivity of the request.

Practical implication: Build OTP into adaptive policy flows and reserve stronger phishing-resistant controls for privileged or sensitive transactions.

NHI Mgmt Group analysis

OTP is now a fallback control, not an assurance endpoint: The article correctly places one-time passwords in a support role beside passkeys and biometric-backed authentication. That is the right governance shift for human IAM because a code that can be intercepted or socially engineered cannot carry the assurance burden for sensitive actions. Practitioners should stop treating OTP as the default strong factor and classify it by the risk level of the journey.

Channel dependence is the real weakness in OTP design: The control is only as strong as the path used to deliver or retrieve the code. SMS and email OTP inherit the security of the carrier or mailbox, which means the factor can be defeated without breaking the authentication algorithm itself. The implication is that assurance review must include delivery path risk, not just code generation.

Passkeys change the control question from possession to bound possession: OTP proves access to a channel, while passkeys and device-bound credentials prove possession of a specific cryptographic credential anchored to a device. That distinction matters because phishing-resistant authentication reduces the value of stolen passwords and intercepted codes. IAM teams should map this difference into policy, especially for customer and workforce journeys that involve sensitive transactions.

Legacy compatibility is the strongest remaining case for OTP: The article's best argument for OTP is not strength but reach. Many environments still need a fallback factor for older applications, low-risk segments, or recovery flows where stronger options are not yet available. That makes OTP a transition control, not a long-term assurance strategy, and the practical implication is to define where fallback is acceptable before it becomes permanent.

Human IAM programmes need explicit assurance tiers: A single MFA label hides very different risk profiles across SMS, authenticator apps, hardware keys, and passkeys. The same user journey can be acceptable for account recovery and unacceptable for payment approval or admin access. Teams should stop describing MFA in generic terms and instead govern it by assurance tier, because broad labels obscure the control gaps that matter most.

From our research library:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Fallback authentication needs explicit boundaries: OTP remains useful where organisations still need a second factor for legacy systems, recovery paths, or low-risk journeys, but those boundaries must be written into policy rather than assumed in practice. The governance mistake is to let a compatibility control become the standing control for sensitive access.

Channel risk, not code generation, now determines assurance: SMS and email OTP inherit the weaknesses of the phone network and mailbox, which means authentication strength can collapse before the code is even checked. Teams should evaluate the delivery path as part of the authentication control itself.

Assurance tiers are the missing design language: A single MFA label hides major differences between OTP, authenticator apps, hardware keys, and passkeys. Identity programmes should map each factor to the sensitivity of the action it protects, then enforce that mapping consistently.

For practitioners

• Define OTP as a fallback factor Classify OTP as acceptable only for low-risk login, compatibility, or recovery flows where stronger methods are unavailable or not yet deployed.
• Phase sensitive journeys to phishing-resistant methods Move privileged actions and high-value transactions to passkeys, hardware keys, or device-bound biometrics instead of channel-delivered codes.
• Review OTP delivery channels for exposure Treat SMS, email, and voice as separate risk paths and document which journeys depend on carrier, mailbox, or phone-number trust.
• Set assurance tiers for MFA policy Map each authentication method to the sensitivity of the action it protects, so the control standard matches the business risk.

Key takeaways

• OTP still reduces the value of stolen passwords, but it should be treated as a fallback factor rather than the primary answer for sensitive access.
• The main weakness is channel dependence, because SMS, email, and voice OTP can be intercepted or redirected even when the code itself is valid.
• Practical governance comes from matching authentication strength to transaction risk, with passkeys and other device-bound factors reserved for higher-assurance journeys.

Key terms

• One-Time Password: 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.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Adaptive MFA: A multi-factor authentication pattern that changes the challenge based on user context, risk, and policy. It reduces unnecessary friction by avoiding one-size-fits-all prompts, while still increasing assurance when a session, device, or location looks unusual.
• Fallback Factor: A secondary access method used when the primary passwordless factor is unavailable. It can preserve continuity, but it also creates a high-risk exception path if it is not tightly scoped, logged, and revoked after use, which is why fallback design is central to governance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.