OTP becomes the wrong choice when the access path is high-risk, attacker pressure is likely, or the organisation can support phishing-resistant alternatives. If the business action involves sensitive data, privileged administration, or repeated fraud exposure, a single-use code is usually not enough assurance on its own.
Why This Matters for Security Teams
OTP often feels like a practical middle ground, but it is still a shared secret delivered through a channel that can be intercepted, relayed, or socially engineered. That makes it a weak fit when the business action carries real blast radius. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that attackers usually exploit the identity path, not just the application itself. See the Ultimate Guide to NHIs — Standards alongside the NIST Cybersecurity Framework 2.0 for the broader control context.
The control choice becomes wrong when the organisation is trying to protect privileged actions, repeated approval workflows, or fraud-sensitive customer journeys. OTP may still have a place for low-risk step-up checks, but it does not provide phishing resistance, device binding, or strong assurance that the person presenting the code is the rightful actor. In practice, many security teams discover the weakness only after an adversary has replayed a code, intercepted a reset flow, or abused a help desk exception rather than through intentional control design.
How It Works in Practice
For lower-risk interactions, OTP can be an acceptable compensating control when the user population, channel, and transaction value are tightly bounded. Once the access path involves administration, payments, account recovery, or sensitive data, current guidance suggests moving to phishing-resistant methods such as passkeys, FIDO2-based authentication, or stronger step-up patterns tied to device and session context. That aligns with the direction of the Schneider Electric credentials breach case study, which illustrates how credential compromise can cascade when the control plane is too permissive.
- Use OTP only where the threat model excludes phishing, relay, and help-desk social engineering as primary attack paths.
- Prefer phishing-resistant authentication for privileged admin work, financial actions, and repeated high-value transactions.
- Bind authentication to device, session, or workload context when the decision needs more than a one-time secret.
- Treat OTP as step-up friction, not as proof of identity for durable trust.
OTP also creates operational gaps in shared device environments, SMS-delivery environments with weak telecom assurance, and workflows where users must reauthenticate frequently under time pressure. That is why security teams should map authentication strength to the sensitivity of the action, not just the convenience of the channel. These controls tend to break down in high-churn support desks and distributed admin environments because attackers can exploit reset paths, retry windows, and human exceptions faster than policy can react.
Common Variations and Edge Cases
Tighter authentication often increases user friction and support overhead, so organisations must balance reduced fraud risk against operational continuity. That tradeoff is real, especially where legacy systems, external contractors, or seasonal users cannot yet support phishing-resistant methods. Best practice is evolving here, and there is no universal standard for when OTP must be retired, but high-risk use cases are increasingly expected to justify it explicitly.
Some edge cases still allow OTP with compensating controls. Short-lived OTP may be acceptable for low-value consumer logins, non-sensitive notifications, or a temporary migration period while stronger controls are phased in. But for admin access, repeated approval steps, or any path with material abuse potential, OTP should be paired with stronger assurance or replaced outright. The underlying lesson from NHI governance is the same as in the Ultimate Guide to NHIs — Standards: control strength must match the value and persistence of the identity being protected.
Where attacker pressure is likely, OTP is usually the wrong control choice if it is the only barrier. Use it as a transitional measure, not as the endpoint.
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 | Authentication strength should match transaction and identity risk. |
| NIST SP 800-63 | AAL2 | OTP commonly maps to lower assurance and weaker phishing resistance. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Weak shared-secret controls create exposure similar to poor NHI secret governance. |
Limit OTP to low-risk use cases and prioritize phishing-resistant controls for privileged paths.
