Security teams should use one-time passwords as a second factor for login, password resets, and other sensitive actions. The strongest pattern is to pair a unique password with a time-limited OTP from an authenticator app or password manager. SMS and email can work, but they add more interception risk and should not be treated as equally strong options.
Why This Matters for Security Teams
One-time passwords are meant to reduce account takeover risk, but they only help when the second factor is easy to use, hard to bypass, and matched to the sensitivity of the action. Teams often get this wrong by overvaluing SMS convenience, forcing repeated prompts, or applying the same MFA step to every login and workflow. NIST’s control guidance on authentication and access enforcement is clear that stronger factors should be used where risk is highest, not layered indiscriminately.
For NHI-heavy environments, the lesson is familiar: friction is not just a user-experience problem, it becomes a control failure when people route around it. NHIMG’s research on secret exposure shows how often weak operational habits persist, and the same pattern appears with OTP fatigue, backup-code misuse, and reset flows that become the easiest target. In practice, many security teams encounter OTP bypass only after account recovery abuse has already been used to defeat the intended MFA step.
Relevant references include Ultimate Guide to NHIs and NIST SP 800-53 Rev 5 Security and Privacy Controls.
How It Works in Practice
The most usable OTP pattern is simple: require a unique password plus a time-limited code from an authenticator app or password manager for login, password reset, and other high-risk actions. The goal is to keep the second factor predictable for legitimate users while making replay and interception harder for attackers. Security teams should prefer app-based OTP over SMS or email where possible, because those channels are more exposed to interception, mailbox compromise, and SIM-swap abuse.
To reduce avoidable friction, OTP should be reserved for moments when additional assurance is actually needed. Common practice is to trigger it on new devices, unusual geographies, risky session behavior, privileged actions, and recovery events. That approach aligns with current guidance in ISO/IEC 27001:2022 Information Security Management, which emphasizes proportional controls rather than blanket disruption.
- Use authenticator-app OTP as the default second factor, with SMS only as a fallback.
- Keep OTP lifetimes short and prevent code reuse across sessions or actions.
- Apply step-up prompts only when risk changes, instead of every time a user authenticates.
- Protect recovery flows with the same or stronger controls than primary login.
- Offer backup options such as recovery codes or phishing-resistant methods for users who cannot use OTP reliably.
NHIMG guidance on Twitter Source Code Breach is a useful reminder that one weak recovery or access path can undo otherwise sound authentication design. These controls tend to break down when legacy help desk processes can reset factors without strong identity proofing, because attackers then target the path of least resistance rather than the login form.
Common Variations and Edge Cases
Tighter OTP enforcement often increases help desk load and user frustration, so organisations have to balance stronger verification against recovery speed and productivity. The best practice is evolving toward risk-based prompts, but there is no universal standard for exactly when to ask for OTP versus another second factor. That means policy should reflect the real sensitivity of the action, not a one-size-fits-all rule.
Some environments also need exceptions. Shared workstations, frontline users with poor mobile coverage, and regulated operations may need hardware tokens, offline backup codes, or stronger phishing-resistant methods where OTP is too fragile. Password managers that generate and store OTPs can improve usability, but they also concentrate risk if the device or vault is compromised. For that reason, teams should treat backup-code storage, recovery contact changes, and factor enrollment as protected events rather than routine admin tasks.
In high-assurance programmes, OTP is often acceptable as a transitional factor, but it should not be the only answer for administrators, finance, or remote-access pathways with elevated impact. Organisations with mature security controls usually combine OTP with device trust, conditional access, and monitored recovery steps so friction is placed where attackers are most likely to exploit it.
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, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-7 | Supports MFA strength and access enforcement decisions for sensitive actions. |
| NIST SP 800-63 | AAL2 | OTP is commonly used as a second factor, but assurance level depends on channel strength. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Recovery and secret-handling mistakes often undermine MFA and OTP protections. |
| NIST AI RMF | Risk-based OTP prompts map to AI RMF risk evaluation and proportional controls. |
Harden enrollment, reset, and backup-code handling so OTP cannot be bypassed through weak recovery paths.
Related resources from NHI Mgmt Group
- How should security teams use fingerprint verification in multi-factor authentication without creating weak fallback paths?
- How should security teams implement multi-factor authentication for sensitive access without creating user workarounds?
- How should security teams implement stronger authentication without creating more user friction?
- How should security teams implement just-in-time access without creating too much friction?
