Teams often assume the code itself is the control, when the real weakness is the channel carrying it. SMS and email can be intercepted, redirected, or abused through account recovery abuse, so they should not be treated as equivalent to device-bound methods. Their convenience is real, but so is their lower assurance.
Why This Matters for Security Teams
SMS and email OTP fail most often because teams treat a one-time code as if it were a strong authenticator, when it is really only as trustworthy as the delivery channel. That distinction matters in phishing, SIM swap, mailbox takeover, help desk abuse, and account recovery flows. NIST guidance has long emphasized that authentication assurance depends on the overall authenticator type and binding, not the presence of a short code alone, and the NIST Cybersecurity Framework 2.0 reinforces the need to match controls to risk.
For practitioners, the real mistake is using OTP as a default second factor for privileged access, workforce SSO, or recovery paths that can reset stronger factors. That creates a false sense of coverage while attackers target the weakest step in the chain. NHIMG research on Schneider Electric credentials breach and the DeepSeek breach shows how quickly exposed credentials and weak identity workflows are operationalized once adversaries find a path in. In practice, many security teams discover OTP weakness only after an account reset or inbox compromise has already given attackers the same access path users were meant to trust.
How It Works in Practice
SMS and email OTP can still reduce opportunistic abuse, but they should be understood as low-assurance, channel-dependent controls. SMS inherits the security of the mobile network, the device, and the carrier account lifecycle. Email OTP inherits the security of the mailbox, forwarding rules, recovery settings, and any session already established on the email account. If any of those layers are compromised, the OTP offers little meaningful resistance.
Operationally, the strongest improvement is to separate “proof of possession” from “message delivery.” Device-bound methods, phishing-resistant authenticators, and passkeys bind the login to a cryptographic key on a trusted device rather than to a code that can be read, forwarded, or replayed. Where SMS or email remains necessary, current guidance suggests limiting it to low-risk enrollment, step-up only for non-sensitive actions, or short-term fallback with tighter monitoring. That usually means:
- Do not use SMS or email OTP for privileged admin access or recovery of strong authenticators.
- Shorten session lifetime and require re-authentication after sensitive actions.
- Harden mailbox and carrier accounts with separate controls and alerts.
- Log OTP use, recovery events, and factor changes as security signals, not routine user activity.
- Prefer phishing-resistant methods where the assurance requirement is high.
NIST’s digital identity guidance and the The State of Secrets in AppSec research both point to the same operational lesson: compromise tends to happen in the surrounding identity and secrets ecosystem, not in the code entry field itself. These controls tend to break down when attackers already control the user’s inbox, phone number, or recovery channel because the OTP is then delivered directly into the attacker’s hands.
Common Variations and Edge Cases
Tighter authentication often increases user friction and support volume, requiring organisations to balance assurance against operational accessibility. That tradeoff is especially visible for contractors, frontline staff, and consumer-facing services where device ownership and enrollment quality vary. Best practice is evolving, and there is no universal standard for when SMS or email OTP should be fully retired versus constrained, so policy should reflect risk tier rather than convenience alone.
A common edge case is legacy application access where MFA options are limited. In those environments, SMS or email OTP may remain temporarily acceptable if paired with compensating controls such as IP restrictions, anomaly detection, and fast revocation paths. Another edge case is account recovery: if recovery can be completed through the same email address or phone number used for OTP, the factor chain is circular and much weaker than teams assume. Security teams also underestimate how often forwarding rules, shared mailboxes, or number porting events create quiet bypasses that never appear as a visible login failure. The practical rule is simple: if the channel can be redirected without defeating the authenticator, the OTP is not the control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-7 | Addresses user authentication and access control weaknesses in OTP-based login flows. |
| NIST SP 800-63 | AAL2 | Defines assurance limits of SMS and email OTP versus stronger authenticators. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Highlights credential weakness when secrets or recovery paths are exposed or reused. |
Use the identity assurance level to decide when OTP is acceptable and when phishing-resistant MFA is required.
