One-time passwords still matter, but they are not enough

At a glance

What this is: This is an explanatory piece on one-time passwords, covering how OTPs work, where they add value, and where they fail under modern phishing and interception techniques.

Why it matters: It matters because OTPs often protect non-human and human identities in the same authentication stack, and weak delivery choices can leave IAM controls exposed even when MFA is technically enabled.

👉 Read Okta's full guide to one-time passwords, MFA, and authentication choices

Context

One-time passwords are a temporary authentication factor, but they are not a complete defence model. In practice, they reduce some reuse and replay risk while leaving organisations exposed to phishing, SIM swapping, and delivery-channel compromise. For IAM teams, the issue is not whether OTPs exist, but whether they are still appropriate for the access paths they protect.

This is especially relevant to NHI governance because OTP-like controls often sit alongside service access, admin workflows, and delegated authentication paths. Once authentication depends on short-lived codes, the security question shifts to the trust assumptions around device possession, message delivery, and fallback recovery. That makes the move toward passkeys and phishing-resistant MFA a governance issue, not just a UX improvement.

Key questions

Q: Should organisations still use one-time passwords for MFA?

A: Yes, but only as a transitional or fallback control. OTPs reduce password reuse and replay risk, yet they remain vulnerable to phishing, SIM swapping, and recovery-channel abuse. For high-risk or privileged access, organisations should prefer phishing-resistant authentication such as WebAuthn or passkeys and reserve OTPs for lower-risk scenarios.

Q: What is the difference between SMS OTP and authenticator-app OTP?

A: SMS OTP depends on a phone number and carrier delivery, while authenticator-app OTP binds the code to a specific device and shared secret. App-based OTP is generally stronger because it avoids SIM swap exposure and message interception, but it still does not stop real-time phishing the way cryptographic authenticators do.

Q: Why do OTPs not fully stop phishing attacks?

A: Because attackers can relay the password and OTP in real time through an adversary-in-the-middle page. The code is valid long enough for the attacker to use it, and the user may not notice the relay. Phishing-resistant methods break that relay by proving possession of a key rather than sharing a reusable code.

Q: How should security teams phase out SMS OTP without breaking access?

A: Start with privileged users and sensitive applications, then move to passkeys or WebAuthn for primary access. Keep SMS only as a temporary recovery option, add approval for factor changes, and monitor reset flows closely. The goal is to reduce dependence on phone-number trust without creating lockout risk.

Technical breakdown

How OTP generation and validation actually work

One-time passwords are generated from a shared secret and a changing input, usually time or counter state. TOTP, the common model, uses a secret key plus a timestamp to produce a short code that remains valid only for a narrow window. The server checks the presented code against expected values and often allows adjacent windows to account for clock drift. HOTP uses a counter instead of time, which reduces dependency on synchronised clocks but introduces state management issues. In both cases, the security property comes from short-lived codes and shared-secret validation, not from the code itself being unpredictable to humans.

Practical implication: Treat OTP as a compensating control, then harden the shared-secret lifecycle and validation window rather than relying on the code format alone.

Why SMS-based OTP creates a weaker trust model

SMS delivery adds a telecom trust layer that the authentication system does not control. That means the security of the factor depends on carrier processes, number porting, message forwarding, and device sync behaviour. Attackers can exploit SIM swap workflows or compromise account portals tied to the phone number, then receive codes without taking over the original handset. Real-time phishing also remains effective because the attacker can relay both the password and the OTP in the same session. The core problem is that SMS proves access to a number, not strong possession of a cryptographic authenticator.

Practical implication: Use SMS only as a fallback with compensating controls and restrict it from high-risk administrative or NHI-related access paths.

How WebAuthn changes the authentication model

WebAuthn replaces shared-secret guessing with public-key cryptography bound to the device and origin. The authenticator signs a challenge rather than transmitting a reusable secret, which is why replay and phishing are much harder. In practical terms, this moves authentication from a code-delivery model to a cryptographic proof-of-possession model. That matters for users, but it matters even more for automated and delegated access flows, where recovery paths, step-up logic, and device binding become part of the control surface. The architectural shift is from temporary credentials to verifiable authenticators.

Practical implication: Prioritise WebAuthn or passkeys for privileged and high-risk access, then remove OTP fallback from workflows that should be phishing-resistant.

Threat narrative

Attacker objective: The attacker wants to bypass MFA by harvesting a usable login session or recovery path without possessing the original device or authenticator.

1. Entry occurs when a user submits a password and OTP into a phishing page that relays both values to the real service in real time.
2. Escalation follows when the attacker reuses the captured session or initiates a recovery flow that relies on weak delivery-channel trust such as SMS or email.
3. Impact is account takeover without needing persistent malware, because the attacker can authenticate as the victim until the session is revoked.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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 transitional control, not a destination control. The article reflects an authentication pattern that solved password reuse better than passwords alone, but it still depends on shared secrets and delivery channels. That design can reduce opportunistic compromise while leaving the highest-risk access paths exposed. Practitioners should treat OTP as a bridge toward stronger authenticators, not as the end state.

SMS OTP creates avoidable identity debt. When the second factor rides on a phone number, the organisation inherits telecom recovery logic, carrier support workflows, and message-forwarding exposure. That is a weak fit for privileged access and any workflow touching NHIs. Teams should reserve SMS for low-risk fallback and remove it from the core trust path where possible.

Passkeys change the governance question from code delivery to device assurance. WebAuthn and FIDO-based authentication reduce replay risk because the authenticator signs a challenge tied to the relying party. That does not remove governance, but it shifts it to enrollment, recovery, device binding, and revocation. Practitioners should align authentication policy with phishing resistance, not with code convenience.

NHI authentication needs stronger assumptions than human login flows. Once service accounts, automation, and delegated access share the same identity stack as users, weak fallback mechanisms become systemic risk. The right response is segmentation of authentication methods by risk class, with stronger controls for anything that can act autonomously or hold elevated privilege.

Identity resilience now depends on the weakest fallback, not the primary factor. Organisations often improve their primary authentication while leaving recovery, reset, and support channels under-governed. That gap is where attackers pivot after a failed phishing attempt. Practitioners should review the full authentication lifecycle, including recovery, because that is where OTP trust assumptions most often fail.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For lifecycle controls, see NHI Lifecycle Management Guide, which frames provisioning, rotation, and offboarding as linked governance steps.

What this signals

Ephemeral codes do not eliminate identity risk, they compress it. That matters for teams that rely on short-lived factors while leaving recovery, reset, and support processes untouched. The bigger governance signal is that identity assurance now fails at the edges, where users, devices, and help desks intersect.

With only 5.7% of organisations having full visibility into their service accounts, according to our Ultimate Guide to NHIs, the same visibility gap can easily extend into authentication recovery paths and delegated access. Teams should assume that the weakest path is often not primary login but the exception handling around it.

Recovery is the real control plane: if a team can reset, rebind, or reissue access too easily, the strongest primary factor loses value. That is why authentication policy should be reviewed together with identity lifecycle controls, including offboarding and factor revocation, rather than as a standalone login decision.

For practitioners

• Restrict SMS OTP to low-risk fallback only Remove SMS from privileged, administrative, and NHI-related workflows where a phishing-resistant factor is feasible. Keep a documented exception process for legacy users and high-availability recovery, and review the exception list on a fixed cadence.
• Adopt phishing-resistant factors for high-risk access Prioritise WebAuthn or passkeys for admin consoles, privileged portals, and any system that can modify secrets or credentials. Bind enrollment to device assurance checks and require a clean revocation path for lost or replaced authenticators.
• Test recovery and reset paths as attack paths Map password reset, phone change, SIM replacement, and help-desk override flows as if an attacker were already inside the account. Verify that recovery does not downgrade from strong MFA to a weaker channel without compensating approval.
• Separate user login policy from machine access policy Do not let the same fallback rules govern humans, service accounts, and automation. For NHIs, prefer short-lived credentials, scoped trust, and explicit revocation over any factor that depends on human-mediated code delivery.

Key takeaways

• One-time passwords improve authentication, but they do not eliminate the trust assumptions that make phishing and SIM swapping effective.
• SMS delivery is the weakest common OTP channel because it depends on carrier processes rather than cryptographic proof of possession.
• Security teams should move privileged and NHI-adjacent access toward phishing-resistant authenticators and keep OTPs only where the risk justifies them.

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.
• TOTP: Time-based one-time password is a code generation method that combines a shared secret with the current time to produce a temporary login code. It is common in authenticator apps and reduces replay risk, but it still relies on shared-secret trust and careful clock synchronisation.
• WebAuthn: WebAuthn is a browser and platform standard for phishing-resistant authentication using public-key cryptography. It binds the authenticator to the origin and signs a challenge instead of sending a reusable code, which makes replay and relay attacks far harder.
• Adversary-in-the-middle Attack: An adversary-in-the-middle attack intercepts and relays authentication in real time between the user and the legitimate service. It is especially dangerous for OTPs because the attacker can capture the code while it is still valid and immediately use it to complete login.

Deepen your knowledge

One-time password risk, phishing-resistant MFA, and NHI authentication choices are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing OTP-heavy workflows with stronger access controls, the course is a useful starting point.

This post draws on content published by Okta: a guide to one-time passwords, MFA, and authentication methods. Read the original.