When is an OTP still acceptable in an MFA strategy?

Where OTP Still Fits in a Modern MFA Stack

OTP remains a reasonable control when the access path is low impact, the user base is still moving off legacy factors, or the code is serving as a temporary step-up or recovery method. In those situations, it is better than password-only authentication, but it should be treated as a transitional control rather than the end state for accounts that can materially affect systems or data.

That distinction matters because OTP solves one problem, proving possession of a second factor, while leaving other weaknesses in place. A code delivered by SMS, email, or an authenticator app can still be phished, relayed, intercepted, or reused if the attacker can influence the delivery or capture path. For higher-value access, the safer target is phishing-resistant authentication such as passkeys or security keys, as described in the NIST SP 800-63 Digital Identity Guidelines.

In practice, OTP is most defensible when the blast radius is small and the business can tolerate a temporary control that is weaker than the eventual design. It is also common in mixed estates where some users or applications cannot yet support stronger authenticators, provided the organisation is actively narrowing that exception over time.

When OTP Becomes a Poor Fit

OTP should stop being the default when the account can unlock privileged administration, payment flows, customer data, production consoles, or remote access into the enterprise. Those are the cases where credential replay, social engineering, mfa fatigue, and adversary-in-the-middle phishing become materially more dangerous. OTP also becomes weaker when the delivery channel itself is the weakest link, such as SIM swap risk for SMS or mailbox compromise for email-based codes.

That is why many of the most instructive incidents involve “valid factor” authentication that still failed under real attack pressure. The pattern is not that MFA was absent, but that the chosen second factor could still be bypassed once the attacker controlled the user interaction, the session, or the recovery path. NHIMG’s MFA Guide is useful here because it distinguishes OTP from phishing-resistant methods and shows where OTP bypasses are most likely.

A practical example is when an organisation keeps OTP for an account that can approve sensitive actions or manage production access. In that case, the factor may satisfy a policy checklist while still leaving a meaningful exposure window, especially if step-up decisions are based on convenience rather than transaction sensitivity.

How to Decide Whether OTP Is Acceptable

The right decision rule is to match the factor to the privilege and the threat model, not to the authentication budget. OTP can be acceptable when the account is low risk, the access is temporary, or the organisation needs a bridge while rolling out passkeys, FIDO2 security keys, or stronger device-bound authentication. It is usually not acceptable where compromise would enable privilege escalation, lateral movement, or high-confidence impersonation.

For migration and fallback use, OTP should be paired with strong controls around recovery, enrollment, and session management. Otherwise, the weakest point often shifts from sign-in to account reset, help desk workflows, or token replay after a successful login. NHIMG’s Passwordless and Passkeys Guide is the cleaner destination when the goal is to replace OTP with a phishing-resistant path rather than to preserve it indefinitely.

Where OTP remains in use, keep the scope explicit: define which applications, user groups, and transaction types are allowed to rely on it, and revisit that list as stronger authenticators become available. The key question is not whether OTP works at all, but whether it still matches the current exposure level.

Risk and Threat Considerations

OTP introduces a residual risk that is acceptable in some contexts and unsafe in others. The main issue is that many OTP deployments protect the initial login, but not the attacker’s ability to intercept the factor, trick the user into entering it, or reuse the resulting session after authentication.

Failure mechanism: OTP can be captured through phishing, relay, SIM swap, mailbox compromise, push abuse, or session theft, which means the second factor may confirm the attacker’s session instead of the legitimate user’s.

Impact: The consequence is account takeover that can scale from nuisance access to privileged compromise, fraudulent transactions, or lateral movement, especially when OTP is used on high-value accounts or as a fallback for recovery.

Practitioner Guidance

What to prioritise: Reserve OTP for lower-risk or transitional use cases, and remove it first from privileged access, admin workflows, remote access, and sensitive transaction approval. If you cannot remove it immediately, confine it to a narrowly defined exception path with compensating monitoring.

What to verify: Check whether the OTP is SMS, email, or app-based, because the acceptable risk changes with the delivery path. Also verify whether the same account can use OTP for enrollment, reset, and recovery, since those paths often matter more than the sign-in flow itself.

Decision rule: If a successful login would let the user change security settings, reach production systems, or approve money-moving actions, treat OTP as temporary only and move to phishing-resistant MFA as the target state.

Practitioner takeaway: OTP is acceptable only when the residual phishing and replay risk is genuinely tolerable, and the organisation has a clear path to replace it before the account’s privilege or exposure level outgrows it.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• Why can SMS and OTP-based MFA still be attacked?
• How should teams decide when one-time codes are still acceptable for MFA?
• How do organisations decide whether OTP is still acceptable?