OTP authentication exposes the trust assumptions in modern login

At a glance

What this is: This is a practical explainer of OTP authentication that shows how HOTP and TOTP work, where SMS, email, and app-generated codes differ, and why the real security question is the trust assumption behind each flow.

Why it matters: IAM and identity teams need to understand OTP limits because the control can reduce password risk while still leaving delivery, enrolment, and shared-secret governance gaps that affect human login assurance and step-up design.

Context

OTP authentication is a short-lived login pattern, not a guarantee of strong identity proofing. The core governance gap is that different OTP delivery methods depend on different trust assumptions, so the security outcome changes with the channel, the device, and the handling of the shared secret.

For IAM programmes, OTPs sit at the intersection of authentication, recovery, and session issuance. They can reduce password exposure, but they also introduce operational dependencies on email, SMS carriers, authenticator devices, and the server-side validation logic that prevents replay.

WorkOS uses OTPs to illustrate a broader login design problem: teams often treat the code as the control, when the channel and secret lifecycle are doing most of the security work.

Key questions

Q: When should teams step up authentication instead of relying on a password and OTP?

A: Teams should step up authentication when the access request is higher risk than normal, such as a funds transfer, a privileged action, or a login from an unfamiliar location or device. Risk-based authentication improves usability by avoiding extra prompts for routine access while tightening controls when the request, the user, or both look unusual or more valuable to attackers.

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 are the signs that an SMS OTP flow is failing as an authentication control?

A: Common signs include intercepted codes, failed or delayed message delivery, repeated login friction, and customers abandoning authentication because the process is cumbersome. If users frequently report that they never receive a code or that fraudsters still complete transactions, the control is not providing reliable proof of possession. At that point, teams should reassess the factor design.

Q: How should security teams govern OTP secrets and recovery paths?

A: Treat OTP seeds and recovery codes as sensitive authenticators, not convenience features. Restrict access to secret storage, define revocation steps for compromised enrolments, and keep account recovery separate from normal login so the fallback path does not become a weaker bypass route. Good governance assumes recovery is part of the attack surface.

Technical breakdown

How OTP authentication actually works

A one-time password is a short-lived code derived from a shared secret and a verification rule on the server. In HOTP, the moving part is a counter; in TOTP, it is time, usually in 30-second windows. The server must validate the code, reject reuse, and tolerate small drift or counter mismatch. That means the security boundary is not the code itself, but the combination of secret storage, generation logic, replay protection, and the delivery channel used to get the code to the user.

Practical implication: treat OTP as a governed authentication flow, not a standalone credential format.

Why SMS, email, and authenticator apps fail differently

SMS OTPs depend on the mobile network and are exposed to SIM swapping and carrier delays. Email OTPs inherit inbox security, spam filtering, and delivery latency. App-generated OTPs move trust to a local shared secret on the device, which avoids network delivery but creates enrolment and device-loss risk. The mechanism changes the threat surface, but all three patterns still rely on the same foundational assumption: the party receiving the code is the one the system intends to authenticate.

Practical implication: choose the OTP channel based on the failure mode you can absorb, not the one users recognise fastest.

How TOTP and HOTP shape the login trust model

TOTP uses time as the moving input, so code validity expires automatically and the server usually checks nearby time windows to handle drift. HOTP uses a counter, so the server and client must stay aligned or codes desynchronise. Both approaches avoid storing a reusable password, but both still depend on a server-side secret that must be protected like a credential. In practice, the strongest issue is governance of the shared secret: if it leaks, the OTP mechanism can be replayed within its valid window or used to generate new codes.

Practical implication: manage OTP secrets with the same care you apply to other sensitive authenticators.

NHI Mgmt Group analysis

OTP controls expose a trust model problem, not just an authentication mechanism problem. OTPs reduce password reuse and can narrow the value of a captured credential, but the underlying security result depends on whether the channel, device, and shared secret are trustworthy. That makes OTP design a governance decision as much as a technical one, especially when the same login pattern is used for primary access and step-up.

Shared-secret handling is the real control plane for OTP risk. The article shows that the server and client both rely on a secret used to generate ephemeral codes, which means secure storage, delivery, and revocation matter as much as the verification algorithm. In identity terms, this is closer to authenticator lifecycle management than simple login UX. Practitioner focus should be on who can see, move, or recover that secret.

Delivery-channel trust is the weak point in many passwordless programmes. SMS and email OTPs depend on systems outside the IAM boundary, so the assurance level changes with carrier reliability, inbox security, and message interception risk. That makes OTPs useful, but uneven, and it means teams should not treat all one-time codes as equivalent controls.

OTP is a bridge control, not a final state for strong authentication. It can be appropriate where the business wants to reduce password storage and speed adoption, but it does not eliminate phishing, channel compromise, or recovery-path weakness. The governance question is whether OTP is being used as a temporary simplification, a step-up factor, or the long-term assurance model for the application.

Identity programmes need to separate code validity from identity assurance. A valid OTP proves access to a channel or device at a point in time, not necessarily strong user intent or durable identity proofing. For IAM leads, the relevant control question is whether the authentication method matches the sensitivity of the action being authorised.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Channel trust is the deciding factor: OTP adoption only improves login security when the delivery mechanism and recovery process are governed as carefully as the code itself. Teams that treat SMS, email, and authenticator-app flows as interchangeable will end up with inconsistent assurance across applications and user populations.

OTP also highlights a recurring IAM pattern: reducing one form of credential risk often shifts exposure into adjacent lifecycle controls such as enrolment, secret storage, and fallback access. That is why OTP programmes should be reviewed alongside authentication policy, not only as a user-experience decision.

For practitioners

• Define channel-specific OTP policy Set different approval and risk rules for SMS, email, and authenticator-app OTPs instead of treating them as one control. Use the weaker channels only where the business impact of interception, delay, or account takeover is acceptable.
• Protect shared secrets as authenticators Store OTP seeds with the same sensitivity as other credentials, restrict operational access, and establish revocation procedures for compromised enrolments. The server-side secret is the asset that makes the code valid.
• Test replay and drift handling Verify that the login flow rejects reused codes, tolerates only the drift you explicitly allow, and logs abnormal retry patterns. Replay protection and time-window handling are part of the control, not implementation details.
• Separate recovery from primary login Design backup codes, account recovery, and device replacement as distinct governance paths so OTP enrolment loss does not become a bypass route. Recovery workflows often become the real exception path.

Key takeaways

• OTP reduces password reuse risk, but it does not remove the need to govern the channel, the shared secret, and the recovery path.
• SMS, email, and authenticator-app OTPs fail in different ways, so teams should not assign them the same assurance level.
• The most important control question is whether the login method matches the sensitivity of the access being granted.

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.
• 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.
• Shared Secret: Any credential or factor that can be known by more than one party and copied or reused, such as a password, OTP, or recovery code. Shared secrets are fragile because once exposed, they can often be replayed to bypass identity controls.

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.