Organisations should assume the second factor is only as strong as the weakest delivery path. If the business still relies on phone numbers or email inboxes, it should add stronger verification for sensitive steps and reduce OTP exposure in recovery and transaction flows.
When a second factor is delivered by phone or email, what is really being trusted?
The control is no longer just “something you have”, it is the security of the delivery path that reaches the phone number or inbox. If that path can be forwarded, reset, ported, phished, or recovered too easily, the second factor becomes a convenience layer rather than a strong proof of possession.
That is why organisations should treat SMS and email OTPs as weaker authenticators for higher-value actions, especially when account recovery, password resets, or payments can be completed through the same channel.
Why recovery and transaction flows matter more than login alone
The highest risk is often not the initial sign-in, but the steps that re-issue access or authorise value transfer. If a user can regain access with a phone number or inbox that is already exposed, the organisation has effectively made account recovery the easier attack path.
This is also where step-up checks matter most. For sensitive actions, add a stronger verifier that is independent of the delivery channel, such as phishing-resistant authentication, out-of-band approval, or an internal risk check tied to the action rather than the message.
Organisations that still allow OTPs in recovery should reduce their blast radius by shortening validity windows, limiting retry attempts, and separating recovery assurance from ordinary session renewal. The goal is to make the second factor useful for friction, not for full account re-establishment.
How should organisations reduce OTP exposure without breaking the user journey?
Start by classifying which journeys actually need the second factor and which can use a stronger step only at escalation points. Everyday access may remain acceptable with a weaker factor in some environments, but recovery, password change, payout, profile change, and support-assisted reset flows need tighter verification.
Where possible, move from OTP-only design to layered assurance. A sensible pattern is to keep the phone or inbox as a delivery channel for low-risk notifications, while using a different authenticator or verification step for anything that changes credentials, redirects funds, or alters recovery routes.
Operationally, the safest change is usually to remove OTP from the highest-risk branches first, not to attempt a wholesale replacement in one release. That gives teams time to measure failure rates, support load, and abandonment before tightening more broadly.
Risk and Threat Considerations
Phone numbers and inboxes are attractive attack surfaces because they are widely reused, can be socially engineered, and often have their own recovery paths. When they become the second factor, compromise of the mailbox, SIM, forwarding rule, or support process can turn into direct account takeover.
Failure mechanism: An attacker does not need to defeat the primary password if they can intercept or reissue the OTP through telecom abuse, email compromise, forwarding, or recovery abuse. The weak point is the delivery and recovery chain, not the code itself.
Impact: Successful abuse can lead to account takeover, fraudulent transactions, recovery lockout, and persistence through changed contact details or reset routes. In high-value environments, that can also become a stepping stone to lateral fraud or privileged access abuse.
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, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authenticators and assurance levels fit second-factor strength. |
| Recommendation — Prefer phishing-resistant authenticators for sensitive actions and recovery. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OTP lifecycle, validity, retry limits and recovery exposure are authenticator-management concerns. |
| IA-2 — Identification and Authentication (Organizational Users) | Sensitive access still requires strong user authentication beyond weak delivery-based factors. | |
| Recommendation — Limit OTP lifetime, retries, and recovery use for high-risk flows. Apply stronger authentication for users before permitting sensitive changes. | ||
| OWASP ASVS | V6 — Authentication | ASVS authentication controls address second-factor strength and recovery hardening. |
| V7 — Session Management | OTP weakness often affects re-authentication, reset, and session renewal flows. | |
| Recommendation — Verify authentication flows use stronger verification for privileged or sensitive actions. Reauthenticate sensitive actions instead of reusing weak recovery paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Restricting high-risk access paths aligns with limiting OTP-based account recovery exposure. |
| Recommendation — Restrict and review access paths that permit OTP-based account recovery. | ||
Practitioner Guidance
What to prioritise: Prioritise the journeys where an OTP can unlock durable access or financial impact, then tighten those first. If the same phone number or inbox can both receive the code and recover the account, treat that path as high risk by default.
What to verify: Verify that recovery, transaction approval, and contact-detail changes do not rely on the same factor being protected. A good test is whether a user can still complete the sensitive action after losing control of the inbox or number, without falling back to a weaker reset loop.
Common mistake: The usual error is to keep OTP everywhere because it is familiar, then add one stronger control only at login. That leaves the highest-risk actions exposed to the weakest route.
Practitioner takeaway: If phone or email is still part of the second factor design, the real control question is whether sensitive actions are gated by a stronger, independent verifier, not whether the OTP was delivered successfully.
Related resources from NHI Mgmt Group
- Who is accountable when organisations keep using weak second-factor methods that are known to be vulnerable?
- How should organisations implement TOTP so it actually strengthens authentication instead of becoming a weak second factor?
- How should organisations secure MFA self-enrollment when accounts have not yet registered a second factor?
- How should organisations choose a second-factor method when they want stronger account protection without adding too much sign-in friction?