Should organisations use phone OTP for high-risk actions?

When phone OTP is acceptable, and when it is not

Phone OTP can be acceptable as one layer of step-up verification, but it should not be treated as strong assurance on its own. Its value depends on the risk of the action, the value of the account, and whether the organisation can tolerate interception, SIM swap, forwarded calls, or user fatigue. For NIST SP 800-63 Digital Identity Guidelines, stronger authenticator assurance is warranted as the impact of the action rises.

For low-value actions, phone OTP may be a pragmatic friction point when paired with rate limits, anomaly detection, and transaction limits. For high-risk actions, such as adding a new payout destination, changing recovery details, or approving privileged access, the better question is not whether OTP works, but whether it meaningfully reduces account-takeover risk on its own. MFA Guide is useful here because it compares OTP with phishing-resistant methods and explains common bypass paths.

In practice, phone OTP is best treated as a signal, not a final control. That means the flow should combine it with device reputation, behavioural signals, step-up thresholds, and clear fraud handling so that the organisation is not relying on a single factor to protect a consequential action. That distinction matters most where the action is irreversible, externally visible, or immediately monetisable.

Why phone OTP is weaker for high-risk actions

Phone-based OTP is vulnerable to attacks that do not require breaking cryptography. Adversaries often target the telecom layer, the user’s inbox or handset, or the support process that can reset authentication factors. It also creates a usability problem: users may approve prompts or read out codes under pressure, which makes social engineering easier. The risk increases when OTP is the only control protecting actions with direct financial or administrative impact.

Failure mechanism: The attacker intercepts, diverts, or socially engineers the OTP path, then uses the valid code to complete a high-value action before the organisation can detect the fraud.

Impact: Account takeover, payment fraud, privilege abuse, or recovery-channel hijack can follow, and the organisation may be left with a technically successful authentication event that was still unsafe.

For a broader control view, NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because it separates identification, authentication, and access enforcement from general system protection, while MITRE ATT&CK Enterprise Matrix helps teams think about credential access, privilege escalation, and abuse paths after an initial compromise.

That is why many organisations reserve OTP for moderate-risk step-up rather than treating it as sufficient for transaction authorisation. The control may confirm possession of a phone number, but that is not the same as proving the right device state, the right context, or the right intent for a high-risk action.

How to decide what to use instead

The right control depends on the action’s blast radius. If the action changes account recovery, money movement, admin rights, or trusted devices, the organisation should prefer phishing-resistant authentication or a richer approval policy rather than relying on phone OTP alone. Where customer flows are involved, the design should also distinguish between login assurance and transaction authorisation, because those are not interchangeable decisions.

NIST SP 800-63 Digital Identity Guidelines supports that separation by framing assurance around authenticators and the strength of the overall identity event, while NIST Cybersecurity Framework 2.0 is useful when the organisation wants a broader governance lens for access risk and control design.

For organisations that still need OTP in the flow, the safer pattern is step-up plus policy, not OTP alone. That means verifying device continuity, flagging new geographies or impossible travel, checking recent account recovery events, and requiring a stronger challenge when the action materially changes risk. The control should fail closed for the most sensitive actions rather than assuming a phone code is enough by itself.

In assurance terms, OWASP API Security Top 10 is relevant wherever the action is exposed through APIs, because the same principle applies: authorisation must be correct for the specific operation, not just for the session that reached it.

Practitioner Guidance

What to prioritise: Treat phone OTP as a step-up factor only for actions whose downside is limited and reversible. If the action can move money, alter recovery paths, or grant access, require stronger assurance or a separate approval path.

What to verify: Confirm that the flow checks more than the code itself, including device binding, recent risk signals, and transaction context. If those checks are absent, OTP is doing too much work.

Common mistake: Teams often equate “user received a code” with “the action is safe.” That shortcut is usually wrong for high-risk events, especially where the attacker can exploit recovery, telecom, or helpdesk paths.

Decision rule: If a fraudulent execution would be costly, irreversible, or difficult to unwind, move away from standalone phone OTP and require a stronger assurance method plus explicit transaction context.

Practitioner takeaway: Use phone OTP where it is proportionate to the risk, but never let it stand in for assurance about the action itself.

Related resources from NHI Mgmt Group

• Should organisations keep human approval gates for high-risk AI actions?
• Should organisations require human approval for high-risk agent actions?
• How should security teams verify users for high-risk actions instead of OTP?
• Why do organisations replace SMS OTP in high-risk journeys before full account-wide migration?