Notifications
Clear all
Topic starter
07/06/2026 8:47 pm
TL;DR: OTPs remain a common passwordless pattern because they are short-lived, easy to understand, and reduce reuse risk, but SMS, email, and app-generated codes each introduce different failure modes, according to WorkOS. The real question is not whether OTPs work, but where their trust model breaks under phishing, delivery delays, and secret handling.
NHIMG editorial — based on content published by WorkOS: One-Time Passwords (OTPs) explained
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- Step-by-step HOTP and TOTP flow diagrams that show how the shared secret, counter, and time-step interact in practice.
- Implementation guidance for replay protection, clock drift allowance, and counter resynchronisation in real login systems.
- Comparative discussion of SMS OTP, email OTP, and authenticator-app OTP flows for product teams choosing an authentication pattern.
- WorkOS's build-vs-buy framing for OTP delivery and validation, including where product teams typically offload the operational edge cases.
👉 Read WorkOS's OTP explainer on HOTP, TOTP, and login trade-offs →
OTP authentication in 2025: are your login controls enough?
Explore further
08/06/2026 8:29 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OTP authentication exposes the trust assumptions in modern login
