Security teams should treat OTP as a transitional control, not a durable phishing-resistant factor. Prioritise authentication methods that bind the login to a device or cryptographic key, reduce replay risk, and avoid sharing codes over SMS or email. If OTP must remain, add tight rate limits, anomaly detection, and step-up controls for high-risk transactions.
Why This Matters for Security Teams
OTP remains common because it is easy to deploy, but it is not durable against modern phishing, session interception, or help desk-driven social engineering. Security teams reduce risk by moving from shared, replayable factors toward phishing-resistant authentication that binds access to a specific device or cryptographic key. That shift aligns with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, where authentication strength must match system risk, not convenience.
The issue is not just credential theft. OTP codes can be relayed in real time, captured through adversary-in-the-middle kits, or coerced through prompt fatigue and recovery workflows. When security teams keep OTP as the default fallback, they often preserve a control that looks familiar while leaving the account boundary exposed. NHI Mgmt Group has shown how identity risk compounds when secrets and credentials are overused in practice, including the fact that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in its Ultimate Guide to NHIs. In practice, many security teams discover OTP weakness only after an account takeover has already bypassed their intended MFA policy.
How It Works in Practice
The practical goal is to narrow OTP usage to a transitional or recovery path while making stronger methods the normal login. Current guidance suggests prioritising phishing-resistant factors such as FIDO2/WebAuthn passkeys, hardware security keys, or device-bound certificates, because those methods resist code replay and session forwarding better than OTP. Where OTP cannot be removed immediately, teams should reduce its value as a standalone factor by coupling it with device posture checks, step-up prompts for sensitive actions, and risk-based policy decisions evaluated at login time.
Security teams should also clean up the pathways that make OTP dangerous:
- Remove SMS and email delivery where feasible, since both are exposed to forwarding, SIM swap, and mailbox takeover risk.
- Limit OTP to low-risk or one-time recovery scenarios, not as the standard path for privileged access.
- Use short OTP lifetimes, strict rate limits, and anomaly detection to catch replay and brute-force attempts.
- Bind sessions to the authenticating device and revoke tokens when risk changes.
- Prefer central policy enforcement through IAM, PAM, and conditional access rather than per-application exceptions.
This is consistent with broader identity hygiene lessons from repeated compromise patterns, including the Microsoft Midnight Blizzard breach, where identity and access weaknesses compounded operational impact. It also aligns with ISO governance expectations for controlled access and lifecycle management in ISO/IEC 27001:2022 Information Security Management. These controls tend to break down in environments with legacy VPNs, shared admin flows, or third-party apps that only support OTP because the organisation cannot enforce a uniform phishing-resistant standard.
Common Variations and Edge Cases
Tighter MFA controls often increase rollout friction, so organisations must balance phishing resistance against user disruption, device availability, and application compatibility. Best practice is evolving, but there is no universal standard for how quickly OTP can be eliminated across every workforce segment.
Some environments need exceptions. Contractors, break-glass accounts, service desks, and remote field users may still require OTP temporarily when hardware keys are not practical. In those cases, use OTP only with compensating controls such as privileged access management, lower session duration, transaction-level approval, and rapid revocation after the task ends. For high-risk roles, move to passwordless or key-based login first, then retire OTP from privileged workflows.
The main decision point is whether OTP is acting as a backup convenience factor or as the only thing standing between a phished password and account access. Security teams that keep OTP without a migration plan often inherit a control that is easy to use but hard to defend, especially when recovery channels remain weaker than primary authentication. In high-volume environments with many legacy applications, OTP reduction usually fails not because the policy is unclear, but because the exception process becomes the real authentication standard.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Highlights weak credential lifecycle and replay exposure from OTP-like secrets. |
| OWASP Agentic AI Top 10 | Runtime auth decisions and tool-bound access mirror phishing-resistant access design. | |
| CSA MAESTRO | Supports stronger identity binding and step-up controls for sensitive AI and digital workflows. | |
| NIST AI RMF | GOVERN | GOVERN requires accountability for authentication risk decisions and exceptions. |
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and authenticators must match access risk and business context. |
Enforce context-aware access at request time instead of relying on static MFA assumptions.
