A one-time password is a short-lived authentication code used once, then discarded. It usually supplements a primary password as a second factor, but its security depends heavily on how the code is generated, delivered, and recovered if the user loses access.
Expanded Definition
A one-time password, or OTP, is a short-lived code used to prove possession of an authenticator during login, step-up verification, or transaction approval. In NHI and IAM practice, it is best understood as an authentication control, not an identity by itself, and not a substitute for robust lifecycle governance.
Definitions vary across vendors because OTP can be delivered by SMS, email, authenticator apps, hardware tokens, or generated for machine workflows. No single standard governs this yet across every use case, so practitioners should separate the code format from the assurance level of the channel and recovery process. NIST guidance on digital identity, especially NIST Cybersecurity Framework 2.0, reinforces that authentication outcomes depend on the full control stack, not just the presence of a code.
For NHI operations, OTPs often appear in admin sign-in, emergency access, and high-risk approval flows. The most common misapplication is treating an OTP as strong security by default, which occurs when delivery channels, replay resistance, and recovery paths are weak.
Examples and Use Cases
Implementing OTP rigorously often introduces user friction and recovery overhead, requiring organisations to weigh faster access against the risk of account takeover and support burden.
- An administrator signs in to a privileged console with a password plus OTP, reducing exposure if the primary secret is phished.
- An agent operator uses a time-bound code to approve a sensitive action, creating a stronger checkpoint before execution authority is granted.
- A recovery workflow issues a temporary code after device loss, but the process must be tightly governed to avoid bypassing stronger controls described in the Ultimate Guide to NHIs.
- A high-risk API administration portal requires step-up OTP for configuration changes, aligning with the principle that access decisions should reflect current risk rather than static trust.
- A SOC analyst validates a transaction using OTP after anomalous behaviour is detected, which supports targeted verification without forcing every action through the same control path.
Where OTP is used for non-human access, it should be paired with strict entitlement review, short session lifetimes, and clear recovery rules. For organisations applying NIST Cybersecurity Framework 2.0, the key question is whether the OTP improves verification without creating a hidden exception path.
Why It Matters in NHI Security
OTP matters because compromise rarely starts with the code itself; it starts with weak enrollment, over-broad recovery, or a delivery channel that attackers can intercept. In NHI environments, those weaknesses can expose service accounts, admin sessions, and approval gates that protect sensitive automation.
NHI Mgmt Group research shows that 91.6% of secrets remain valid five days after notification, which illustrates how slow remediation can leave authentication dependencies exposed long after an incident begins. That same lag matters when an OTP-dependent workflow relies on old devices, stale phone numbers, or fallback emails. The broader lesson from the Ultimate Guide to NHIs is that lifecycle control, rotation discipline, and recovery design all influence whether an OTP strengthens assurance or merely adds a superficial extra step.
Organisations typically encounter the operational limits of OTP only after a phishing event, device loss, or emergency access abuse, at which point OTP governance becomes operationally unavoidable to address.
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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL2 | OTP is commonly used as an authenticator factor within NIST assurance levels. |
| NIST CSF 2.0 | PR.AA-1 | Authentication control design and verification map directly to identity assurance. |
| NIST Zero Trust (SP 800-207) | AC-2 | Zero Trust requires continuous verification, not trust based on a single code. |
Use OTP only where the authenticator and recovery path satisfy the required assurance level.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
