Why do SMS and email OTPs create different risk profiles?

Why This Matters for Security Teams

SMS and email OTPs are often treated as “good enough” because they look like low-friction second factors, but the delivery channel is part of the trust boundary. That means the control is only as strong as the mailbox or mobile account protecting it. NIST’s NIST Cybersecurity Framework 2.0 emphasises identifying where assets and dependencies actually sit, and OTP delivery is a dependency that is easy to underestimate.

The practical risk difference is simple: SMS can be redirected through SIM swap, port-out fraud, or carrier-level compromise, while email OTPs inherit inbox takeover, message forwarding, and delayed delivery problems. Security teams also get tripped up by recovery workflows, where the same channel used for OTP verification is also used to reset access. NHIMG research on Why NHI Security Matters Now and the Top 10 NHI Issues shows how quickly trust breaks when credentials travel through weak or overextended channels. In practice, many security teams discover OTP weaknesses only after account recovery abuse or mailbox compromise has already occurred, rather than through intentional testing.

How It Works in Practice

SMS and email OTPs are not equivalent because they fail in different places. SMS depends on the mobile ecosystem, so an attacker who can convince a carrier to move a number, or who can intercept SMS through a compromised device, can often receive the one-time code without touching the target application. Email OTPs depend on the security of the inbox, the device sessions already signed into that inbox, and any forwarding rules or aliases that quietly duplicate messages. In both cases, the OTP becomes a soft token attached to another system’s security posture.

For practitioners, the right way to evaluate the channel is to ask what has to be compromised before the code can be read, and how quickly that compromise can happen. This is why guidance increasingly points toward risk-based authentication and phishing-resistant methods for sensitive actions, rather than assuming any one-time code is equally strong. NIST identity guidance and the broader Ultimate Guide to NHIs — Key Challenges and Risks both reinforce the same operational lesson: the factor is only meaningful if the delivery path is resilient.

• Use SMS only where user convenience matters more than assurance and the action is low risk.
• Use email OTP cautiously if mailbox hardening, MFA, and forwarding-rule monitoring are already mature.
• Prefer phishing-resistant factors for high-value accounts, especially admin, finance, and recovery paths.
• Separate account recovery from the same channel used for routine login whenever possible.

These controls tend to break down in organisations that still rely on shared mailboxes, weak telecom account protections, or legacy recovery processes that treat the OTP channel as proof of identity by itself.

Common Variations and Edge Cases

Tighter OTP controls often increase user friction and support overhead, so organisations have to balance convenience against account-takeover exposure. Current guidance suggests that the “better” channel is not universal; it depends on the threat model, the sensitivity of the action, and whether the organisation can actually monitor the surrounding channel.

There are several edge cases worth calling out. SMS may be acceptable for low-risk consumer sign-in or step-up verification when no stronger option is practical, but it is a poor fit for privileged admin access, financial approval, or recovery of high-value accounts. Email OTP can be reasonable in environments where email itself is strongly protected with phishing-resistant MFA, device binding, and mailbox rule auditing, but it becomes fragile when users forward mail externally or access inboxes on unmanaged devices. For organisations tracking NHI and secrets exposure, the State of Secrets in AppSec provides a useful reminder that security assumptions often fail faster than teams expect; the average time to remediate a leaked secret was reported at 27 days, which is long enough for an OTP compromise pattern to spread before detection.

Best practice is evolving, but the direction is clear: treat OTPs as a convenience control, not a strong identity proof, whenever the channel can be subverted more easily than the application can detect.

Related resources from NHI Mgmt Group

• Why do third-party connector patterns create NHI risk even when tokens are refreshed automatically?
• Why do brokered access tokens still create identity risk?
• Why do JWTs create risk when used as bearer tokens?
• Why do shared client secrets create more risk than asymmetric client authentication?