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

At a glance

What this is: This is Okta's analysis of one-time passwords, showing that OTPs remain useful for MFA but are no longer sufficient on their own against modern phishing and delivery-channel attacks.

Why it matters: It matters because IAM teams have to decide where OTPs remain acceptable, where stronger phishing-resistant authentication is required, and how to phase in passkeys without weakening user access control.

By the numbers:

• Most implementations use time-based algorithms that generate codes valid for only 30 to 60 seconds.

Context

One-time passwords are temporary authentication codes used to verify a user during sign-in or transaction approval. The security gap is not the existence of OTPs themselves, but the assumption that a short-lived code automatically makes the whole authentication flow phishing-resistant or channel-secure.

For IAM teams, the relevant question is where OTPs still belong in a layered authentication strategy and where they should be replaced by stronger methods such as WebAuthn or passkeys. That decision affects workforce access, recovery flows, remote access, and any programme trying to reduce reliance on SMS-based verification.

Key questions

Q: When is an OTP still acceptable in an MFA strategy?

A: OTP remains acceptable for lower-risk access, transitional deployments, and fallback authentication where stronger phishing-resistant methods are not yet available. It is weaker when the business context includes privileged access, sensitive transactions, or active phishing exposure, because the code can still be intercepted or replayed through the delivery path.

Q: Why does SMS OTP create more risk than many teams assume?

A: Because the trust boundary sits in the telecom and messaging path, not in the user’s device alone. Phishing relay, SIM swap, port-out fraud, recycled numbers, and SS7 interception can all break the model without stealing the user’s password. For regulated journeys, that makes SMS OTP a weak assurance factor rather than a stable control.

Q: Should organisations prioritise passkeys over OTPs and magic links?

A: Usually yes, when phishing resistance and device binding matter most. Passkeys offer stronger assurance, while OTPs and magic links can still be useful as transitional methods or lower-assurance alternatives in a phased customer IAM rollout.

Q: What should teams do if OTP is the only fallback factor?

A: Treat fallback design as part of the control, not an afterthought. Limit who can invoke it, require extra verification in recovery flows, and test whether the fallback path is easier to attack than the primary login flow.

Technical breakdown

How TOTP and HOTP generate and validate codes

Time-based one-time passwords (TOTP) and HMAC-based one-time passwords (HOTP) both depend on a shared secret between the user device and the authentication server. TOTP combines that secret with a timestamp, while HOTP uses an incrementing counter. In both cases, the server validates a short code inside a limited window, which makes replay harder but still leaves the secret, the device, and the delivery path as security dependencies.

Practical implication: treat OTP generation as a shared-secret system, not as a stand-alone control, and govern the secret lifecycle accordingly.

Why SMS OTP creates a weak delivery channel

SMS OTPs inherit the security weaknesses of the mobile carrier ecosystem. If an attacker can perform SIM swapping, compromise a carrier portal, or intercept messages across synced devices, the OTP no longer protects the session. The code may still be technically valid, but the channel that delivered it has already been subverted. That means the authentication factor is weaker than the code format suggests.

Practical implication: do not treat SMS as equivalent to app-based OTP or phishing-resistant authentication when setting policy for higher-risk access.

How WebAuthn and passkeys change the authentication model

WebAuthn and passkeys shift authentication away from shared secrets and toward public-key cryptography tied to the device and user gesture. Because the authenticator signs a challenge instead of transmitting a reusable code, phishing and replay become much harder. That changes the control conversation from 'Can the code be stolen?' to 'Can the private key be used outside the approved device and context?'

Practical implication: use passkeys and WebAuthn where you need phishing-resistant authentication and a lower reliance on code delivery channels.

Threat narrative

Attacker objective: The attacker aims to bypass MFA controls and gain trusted session access despite the presence of OTP-based verification.

1. Entry occurs when a threat actor captures primary credentials through phishing, credential stuffing, or account compromise before the OTP step is challenged.
2. Credential access succeeds when the actor obtains an OTP through SMS interception, SIM swapping, real-time phishing, or compromise of an authenticator recovery path.
3. Escalation follows when the attacker uses the validated session to access protected applications, VPNs, or privileged workflows that trust the OTP result.
4. Impact is unauthorized account takeover, transaction approval, or lateral access into systems that assumed the second factor closed the risk gap.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Uber breach 2016: An AWS key posted to Uber's private GitHub repositories let intruders copy data on 57 million people; Uber paid $100,000 and hid it for a year.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OTP is a compensating control, not a terminal control: One-time passwords reduce replay and password reuse risk, but they do not close the trust problem in the authentication channel. SMS, app delivery, and recovery flows each create a different attack surface. The result is that teams still need to distinguish between 'adds friction' and 'resists phishing,' because those are not the same control outcome.

Passkeys expose the real governance gap in MFA programmes: The issue is no longer whether organisations can issue a second factor, but whether that factor is phishing-resistant by design. WebAuthn and passkeys move authentication toward device-bound cryptography, which is a different trust model from shared-code verification. Practitioners should treat that as an authentication architecture shift, not just a UX upgrade.

SMS-based verification is a lifecycle problem as much as an authentication problem: Carrier porting, device sync, and account recovery all extend the effective lifetime of the factor beyond the login screen. That means the strongest OTP code can still fail through weak offboarding and weak channel governance. Identity teams need to evaluate the whole factor lifecycle, not just the code format.

Phishing-resistant authentication should be the default direction for high-risk access: The article reinforces a broader identity security pattern: if the channel can be replayed, coerced, or intercepted in real time, the factor is only partially protective. That does not make OTP obsolete, but it does mean risk-based authentication programmes should reserve it for lower-risk or fallback use cases.

Authentication assurance depends on delivery path assurance: A code that is valid for 30 to 60 seconds still fails if the attacker controls the delivery path. This is the named concept that matters for IAM teams: delivery-path trust debt. The practical conclusion is that assurance must be measured across the whole authentication flow, not only at the code generator.

What this signals

Delivery-path trust debt: OTP programmes often look stronger than they are because the code is short-lived, but the surrounding path can still be coerced or intercepted. For IAM teams, the security question is whether the factor remains trustworthy after it leaves the authenticator and before it reaches the verifier.

Passkeys change the control objective from code freshness to possession of a private key bound to a device and user gesture. That shifts governance toward phishing resistance and away from shared-secret handling, which is where many current MFA policies still spend their effort.

For practitioners

• Prioritise phishing-resistant authentication for high-risk access Move privileged, remote, and sensitive workforce access toward WebAuthn or passkeys where the environment supports them. Reserve OTP for lower-risk fallbacks and transitional use cases where the business has not yet completed the migration.
• De-risk SMS delivery as a primary factor Remove SMS from critical access paths where possible, and if it must remain, wrap it in stronger policy, monitoring, and recovery controls because carrier compromise and SIM swapping can defeat the channel.
• Review OTP recovery and fallback paths Inspect account recovery, device replacement, and help-desk reset workflows for the same trust assumptions as sign-in, because weak recovery often undoes the security benefit of the OTP itself.
• Set assurance levels by access context Map user groups and use cases to explicit authentication requirements so that high-risk systems require stronger factors than commodity applications, rather than applying one OTP policy everywhere.

Key takeaways

• OTPs still add security value, but they are strongest as a compensating control rather than as the end state of authentication design.
• SMS delivery remains the weakest OTP channel because carrier compromise and SIM swapping can defeat the second factor even when the code itself is valid.
• Phishing-resistant authentication such as WebAuthn or passkeys is the more durable answer for sensitive access, privileged workflows, and high-risk environments.

Key terms

• One-Time Password: A one-time password is a temporary authentication code that can be used only once within a short validity window. In practice it strengthens sign-in by adding a possession factor, but it still depends on the security of the generation, delivery, and verification path.
• 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.
• Authenticator assurance level: Authenticator assurance level is a measure of how strongly an identity event proves the claimant is genuine. In NIST 800-63B, higher levels require stronger factor evidence and tighter cryptographic protections, which makes the level a practical way to map identity controls to regulated access requirements.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.