Because both channels can be undermined in real attack conditions. Email is commonly exposed through phishing and account compromise, while SMS is vulnerable to mobile-provider social engineering and weaknesses in the SS7 ecosystem. NIST 800-63B therefore steers teams toward stronger, impersonation-resistant authenticators that hold up better against credential theft and interception.
Why NIST SP 800-63B treats email OTP and SMS as weak sign-in options
Email OTP and SMS codes fail in the places attackers actually operate. Email codes inherit the security of the mailbox, so phishing, session theft, and account compromise can expose the second factor. SMS codes depend on telecom trust that can be weakened through SIM swap, number porting abuse, and interception in the mobile signalling ecosystem.
The practical consequence is that a code delivered over a separate channel is not automatically a strong authenticator. NIST SP 800-63B pushes teams toward authenticator choices that are harder to intercept, harder to relay, and less dependent on a human-helpdesk or carrier recovery path.
That is why this guidance matters most when organisations are still treating “one-time code” as a security category instead of asking how resilient the delivery path is under phishing, takeover, or recovery abuse. The weakness is not the existence of a second step, it is the attack surface that the second step inherits.
What breaks first in real attacks
Email OTP usually breaks when the attacker already has a path into the user’s mailbox or can trick the user into surrendering it. Once the mailbox is exposed, the attacker can retrieve codes, reset passwords, or capture recovery messages that make the code meaningless as a barrier.
SMS-based authentication breaks differently. The phone number itself becomes a soft target, because mobile-provider support processes, port-out requests, and SIM replacement workflows can be manipulated. Even when the number is not directly taken over, SMS lacks strong binding to the authenticated session, so a forwarded or relayed code can still be abused.
Both methods also create a false sense of assurance in environments that need phishing resistance. They may still work as fallback methods in some designs, but they do not materially solve impersonation of the verifier or interception of the secret in transit.
What NIST SP 800-63B is really optimizing for
NIST SP 800-63B is steering teams away from authenticators that rely on channels with weak resistance to interception or social engineering. The goal is not just “more factors”, but stronger proof that the party completing the authentication ceremony is the intended user and not an attacker reusing a stolen code.
That is why NIST SP 800-63 Digital Identity Guidelines places weight on authenticator strength, phishing resistance, and assurance level. In practice, teams should read the guidance as a signal to prefer authenticators that resist replay, relay, and recovery-path abuse rather than leaning on channels that were designed for convenience.
The same logic is reflected in the broader rollout guidance for stronger sign-in methods. Passwordless and Passkeys Guide is useful here because it shows the alternative direction NIST is favouring: phish-resistant authentication with better binding to the device and the session.
What to use instead when you need stronger assurance
For most modern deployments, the stronger alternatives are phishing-resistant authenticators such as passkeys, security keys, or certificate-based methods where the operational model supports them. The important distinction is not whether the user still enters something, but whether the verifier can trust the authenticator without relying on a deliverable code exposed to interception.
If your environment still needs OTP as a transitional control, use it with strict limits. Pair it with step-up rules, anomaly detection, and recovery controls that assume the code itself may be observed. For teams comparing options, Authenticator Apps and OTP Guide helps separate app-based OTP from email and SMS delivery, which is important because the delivery channel materially changes the risk profile.
For broader programme decisions, it helps to distinguish “acceptable as a fallback” from “good enough for primary authentication”. The former may survive temporary migration needs, while the latter is where NIST’s guidance is clearly pushing teams away from legacy code delivery methods.
Risk and Threat Considerations
Email and SMS OTP create different but equally practical exposure paths. The first is often defeated by account compromise or phishing, while the second can be undermined by telecom account takeover, device-number reassignment, or interception of the code before it reaches the real user.
Failure mechanism: The attacker either gains access to the delivery channel itself or relays the code through a live phishing flow, so the code proves control of a channel rather than strong user presence.
Impact: Authentication can be bypassed even when the user believes a second factor is in play, which raises the likelihood of account takeover, downstream session abuse, and recovery-path exploitation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL2 — Authenticator Assurance Level 2 | AAL guidance underpins the move away from weak OTP channels. |
| AAL3 — Authenticator Assurance Level 3 | AAL3 aligns with the strongest phishing-resistant sign-in expectations. | |
| Recommendation — Prefer phishing-resistant authenticators for accounts that need stronger assurance. Use phishing-resistant authenticators where compromise impact is high. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers authenticator lifecycle choices and replacement of weak OTP methods. |
| IA-2 — Identification and Authentication (Organizational Users) | Applies to workforce sign-in choices and assurance over user authentication. | |
| Recommendation — Manage authenticators so weaker channels are not used for high-risk access. Enforce stronger authentication methods for organisational users. | ||
| OWASP ASVS | V6 — Authentication | Directly addresses stronger authentication design and verification requirements. |
| V10 — OAuth and OIDC | Relevant where sign-in flows depend on federated authentication and step-up. | |
| Recommendation — Verify that authentication methods resist phishing, replay and interception. Review federated sign-in flows for phishing-resistant assurance and recovery weaknesses. | ||
Practitioner Guidance
What to prioritise: Treat SMS and email OTP as migration or fallback controls, not your end state for high-value accounts. Prioritise phishing-resistant authenticators first for administrators, support staff, and any account that can reset others.
What to verify: Confirm that recovery, reset, and help-desk processes are at least as strong as the authenticator itself. A strong sign-in method loses most of its value if a weaker recovery path can re-enroll the attacker.
What good looks like: The authentication method is bound to the intended user or device in a way that cannot be copied from a mailbox, forwarded from a phone, or replayed from a phishing site.
Practitioner takeaway: If a factor can be harvested through common phishing or carrier abuse, it may still improve friction, but it does not deliver the level of impersonation resistance NIST is asking teams to build toward.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org