OTP authentication exposes the trust assumptions in modern login

At a glance

What this is: This is an explainer on one-time passwords, their types, and the implementation trade-offs that determine when OTPs strengthen login and when they create new friction or risk.

Why it matters: It matters because IAM teams still use OTPs for human authentication, but the same trust assumptions influence step-up access patterns, secret handling, and broader identity design across NHI and autonomous programmes.

👉 Read WorkOS's OTP explainer on HOTP, TOTP, and login trade-offs

Context

One-time passwords reduce reuse risk because the code expires after a single use or a short time window, but that does not remove the underlying trust dependency. The login still depends on delivery channels, shared secrets, device clocks, and replay protection, which means the control is only as strong as the surrounding identity workflow.

For IAM teams, OTPs sit at the intersection of authentication, recovery, and step-up access. That makes them relevant not just to consumer login, but to the broader question of how identity systems handle short-lived credentials, verification windows, and user friction when a stronger factor is not available.

Key questions

Q: How should security teams use OTPs without overrelying on them?

A: Use OTPs as a bounded authentication step, not as the entire assurance model. They work best for low-risk login or step-up checks, especially when paired with session controls, phishing-resistant options for higher-risk users, and clear recovery policy. If OTP is the only factor, the organisation is usually compensating for missing identity design elsewhere.

Q: Why do SMS and email OTPs create different risk profiles?

A: SMS and email OTPs depend on the security of the delivery channel, so the channel becomes part of the credential boundary. SMS faces SIM swap and carrier interception risk, while email inherits inbox compromise, forwarding, and delivery delay. That means the right choice depends on whether convenience or assurance is the higher priority.

Q: What breaks when OTP verification does not enforce replay protection?

A: Without replay protection, a captured code can be reused inside its validity window, which defeats the single-use purpose of the control. The weakness is not just technical, because it undermines user trust and can enable session hijacking after the first successful submission. Replay checks are therefore mandatory, not optional hardening.

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.

Technical breakdown

How HOTP and TOTP generate a usable one-time code

HOTP and TOTP are both HMAC-based code generators, but they use different moving inputs. HOTP uses an incrementing counter shared by the client and server. TOTP replaces the counter with a time-step, usually 30 seconds, so both sides compute the same result from the current timestamp. In both cases, the server verifies the code against stored state, then rejects reuse. The design removes reusable passwords, but it also shifts trust to secret storage, synchronisation, and the integrity of the verification window. Practical implication: treat OTP secrets like protected credentials and build strict replay checks into verification.

Practical implication: protect the shared secret and enforce single-use verification with replay detection.

SMS, email, and app-generated OTPs do not carry the same risk

SMS and email OTPs are convenient because the user already has access to the channel, but the channel becomes part of the authentication boundary. SMS can be intercepted or redirected through SIM swap attacks, while email OTPs inherit inbox security, delivery latency, and forwarding risk. App-generated OTPs move the trust anchor onto the device and the secret it stores locally, which reduces dependence on the network but creates recovery and device-loss concerns. The underlying lesson is that OTP is a pattern, not a guarantee. Practical implication: choose the delivery method based on the assurance level the login really needs.

Practical implication: match the OTP delivery channel to the assurance level of the login flow.

Replay protection and clock drift are the hidden failure points

A correct OTP is not automatically a valid OTP. The server must check whether the code has already been used, and it must decide how much clock drift or counter desynchronisation it will tolerate. TOTP usually allows a small window around the current timestep to absorb device skew, while HOTP requires resynchronisation logic when counters drift apart. Those details are easy to ignore in implementation, but they define whether OTPs actually reduce risk or just add another brittle control. Practical implication: test verification logic under skew, retry, and reuse conditions before production rollout.

Practical implication: test verification logic for skew, retries, and replay before production use.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 human authentication control, not an identity strategy. OTPs can reduce password reuse and lower the impact of credential theft, but they do not solve account recovery, channel compromise, or phishing on their own. The control works best when it is one layer in a broader authentication and session policy, not the centre of the design. Practitioners should treat OTP as a bounded assurance step, not a complete trust model.

Email and SMS OTPs inherit the security of the delivery channel. If the inbox or phone number is the real credential, then the authentication boundary has moved outside the application. That is why recovery paths, carrier risk, mailbox compromise, and forwarding behaviour matter as much as code generation. Teams that ignore the channel are governing the code while leaving the identity path exposed.

One-time codes are useful precisely because they are ephemeral, but ephemerality also makes them operationally fragile. A code that expires fast can improve security, yet the same short lifetime creates support load when delivery lags or clocks drift. The governance lesson is simple: the shorter the validity window, the more the surrounding workflow must be designed for reliability, verification, and fallback control.

OTP remains a transitional control, not the end state for modern identity programmes. It still has a place in step-up authentication and low-friction login, but organisations should not confuse familiarity with adequacy. Where the business needs stronger assurance, OTP should be paired with risk signals, phishing-resistant factors, or tighter session policy. Practitioners should measure where OTP is being used because it is easy, not because it is sufficient.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• That same research says companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, which shows the control gap is not just about spend.
• For a broader identity lens, read the Ultimate Guide to NHIs for how short-lived credentials, rotation, and lifecycle governance fit together.

What this signals

OTP adoption will keep expanding wherever organisations want faster login without a full password reset burden, but the governance question is shifting from “can users enter the code?” to “what trust boundary does the code actually create?” Teams should align OTP use with the assurance level of the account, the recovery path, and the channel risk, then document when the control is only a convenience layer.

Channel-bound credential risk: OTPs show that an authentication control is only as strong as the delivery path and the surrounding recovery workflow. When teams treat SMS and email as interchangeable with app-generated codes, they blur the difference between user convenience and identity assurance. That distinction will matter more as login flows, step-up access, and support-driven recovery become more tightly coupled.

For practitioner programmes, the next step is to connect OTP decisions to the same identity discipline used for NHI and privileged access: secret handling, replay resistance, and fallback governance. The NIST Cybersecurity Framework 2.0 remains a useful way to map where authentication, detection, and recovery responsibilities sit across the programme.

For practitioners

• Map OTP use by assurance level Separate primary login, step-up authentication, and account recovery flows so you know where OTP is compensating for weaker controls and where it is carrying too much of the assurance load.
• Harden the delivery channel Review whether SMS and email OTPs are acceptable for the account population, then document the risk of SIM swap, mailbox compromise, and forwarding before you keep them in scope.
• Test replay and drift handling Validate that the verification service rejects reused codes and behaves predictably under clock skew, resend attempts, and partial desynchronisation.
• Define recovery without weakening the factor Make backup codes, device replacement, and fallback authentication explicit in policy so user support does not become the easiest way to bypass OTP controls.

Key takeaways

• OTPs reduce password reuse risk, but they shift the trust problem into delivery channels, device state, and verification logic.
• The evidence in the implementation details matters as much as the code itself, because replay protection, drift handling, and recovery design determine whether OTPs are actually reliable.
• IAM teams should use OTPs deliberately, matching the factor to the account’s assurance needs instead of treating one-time codes as a universal replacement for stronger identity controls.

Key terms

• One-Time Password: A one-time password is a short-lived code that can be used for a single authentication attempt or within a narrow validity window. It reduces password reuse risk, but the overall assurance still depends on code delivery, secret handling, replay protection, and the strength of the surrounding login flow.
• HOTP: HOTP is a counter-based one-time password algorithm that generates a code from a shared secret and an incrementing counter. It stays valid until used or invalidated, which makes synchronisation the main operational challenge and makes replay protection essential after verification.
• TOTP: TOTP is a time-based one-time password algorithm that derives a code from a shared secret and the current time-step. It is widely used in authenticator apps because it rotates automatically, but its reliability depends on accurate device clocks and careful tolerance for drift.
• Replay Protection: Replay protection is the control that prevents a previously accepted credential from being used again. In OTP systems, it is the difference between a truly one-time code and a short-lived reusable token, and it must be enforced server-side, not assumed by the user interface.

Deepen your knowledge

OTP design, recovery, and verification are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are deciding where one-time codes fit in a broader identity programme, it is worth exploring.

This post draws on content published by WorkOS: One-Time Passwords (OTPs) explained. Read the original.