Decide by use case, not by habit. If the journey is low risk, legacy-dependent, or recovery-oriented, OTP may remain acceptable with clear policy limits. If the journey is sensitive, privileged, or exposed to phishing, move to stronger methods and require adaptive signals before granting access.
Why This Matters for Security Teams
OTP is not “secure” or “insecure” in the abstract. It is acceptable only when the organisation can tolerate replay risk, phishing risk, and limited assurance about who is really presenting the code. That decision matters because OTP often survives longer than it should, especially in recovery flows and legacy journeys where stronger authenticators are not yet practical. NIST Cybersecurity Framework 2.0 emphasises risk-based governance, which is the right lens here.
For NHI and access teams, the real question is whether the journey can withstand interception, fatigue attacks, or social engineering without creating business harm. OTP remains common in environments with older applications, external partners, or constrained user populations, but current guidance suggests it should not be the default for sensitive access. NHI Mgmt Group’s research shows how weak identity hygiene compounds the problem: in the Ultimate Guide to NHIs, 79% of organisations report secrets leaks, and 97% of NHIs carry excessive privileges.
In practice, many security teams discover OTP’s limits only after a phishing-led account takeover or help desk recovery abuse has already occurred, rather than through intentional control design.
How It Works in Practice
Most organisations decide OTP acceptability by mapping the journey to risk, not by making a blanket MFA rule. A low-risk internal app may accept OTP temporarily, while administrative access, finance workflows, and privileged operations usually require stronger methods such as phishing-resistant authenticators or step-up controls. The key is to define where OTP is allowed, where it is discouraged, and where it is banned.
Operationally, that means evaluating:
- the sensitivity of the resource being accessed
- the likelihood of phishing, relay, or social engineering
- whether recovery, enrollment, or fallback is the actual use case
- whether session risk signals can trigger reauthentication or block access
For organisations managing NHIs and machine-mediated access, the lesson from incidents such as the Schneider Electric credentials breach and JetBrains GitHub plugin token exposure is that weak or overextended identity assurance can create broad compromise paths. While those examples are not OTP-specific, they show how exposed credentials and poor journey design amplify identity risk.
In stronger implementations, OTP is paired with conditional access, device posture checks, and step-up authentication. NIST guidance and identity standards increasingly favour context-aware decisions, and OTP is best treated as one factor in a broader policy rather than as a standalone proof of trust. These controls tend to break down when legacy apps cannot support step-up challenges because access becomes all-or-nothing and security teams silently widen OTP’s scope to keep operations running.
Common Variations and Edge Cases
Tighter authentication controls often increase operational friction, so organisations have to balance fraud resistance against user support load and application compatibility. That tradeoff is real, especially where recovery journeys, contractors, or shared operational tools still depend on OTP.
There is no universal standard for this yet, but current guidance suggests a few common patterns. OTP may still be acceptable for:
- account recovery and break-glass access with strict logging
- low-risk, low-impact internal applications
- temporary migration periods where stronger methods are being rolled out
OTP is usually a poor choice for privileged admin portals, high-value financial actions, sensitive data access, or any journey that is especially exposed to phishing or real-time relay attacks. For these cases, organisations should prefer phishing-resistant methods and adaptive access decisions aligned to NIST Cybersecurity Framework 2.0.
The most common failure mode is policy drift: OTP starts as a temporary exception and becomes the standard because no one revisits the risk decision after the rollout.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA | Identity assurance and access control guide whether OTP is acceptable by journey risk. |
| OWASP Non-Human Identity Top 10 | NHI-03 | OTP policy often intersects with weak credential handling and recovery-path exposure. |
| NIST AI RMF | Adaptive, context-aware access decisions align with AI-era risk evaluation for dynamic journeys. |
Classify authentication journeys by risk and require stronger controls where access impact is high.
Related resources from NHI Mgmt Group
- How can organisations decide whether environment visibility is acceptable?
- How do organisations decide when to require biometric verification versus other proofing methods?
- How should organisations decide where to use biometric authentication?
- How do teams decide whether possession-based authentication is strong enough?
