Should organisations still use one-time passwords for MFA?

Why This Matters for Security Teams

One-time passwords still solve a real problem: they reduce reliance on reusable passwords and can act as a temporary layer during migration. The issue is that OTPs were never designed to withstand modern phishing kits, real-time relay attacks, SIM swapping, or abuse of account recovery paths. Current guidance from NIST Cybersecurity Framework 2.0 points teams toward stronger authentication outcomes, but the practical decision is usually about where OTPs remain acceptable and where they create a false sense of assurance.

That distinction matters because identity attacks rarely stop at the login screen. If an attacker can intercept an OTP, they may still reach email, VPN, admin consoles, or privileged workflows that were assumed to be protected. NHI Mgmt Group research shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which is a reminder that weak recovery and fallback paths often become the real entry point. For a breach example tied to credential abuse and identity compromise, the Microsoft Midnight Blizzard breach illustrates how identity controls fail when trust is too broad and verification is too weak. In practice, many security teams discover OTP weakness only after phishing or recovery abuse has already bypassed the intended control, rather than through intentional testing.

How It Works in Practice

Use OTPs as a transitional control, not as the end state. For general workforce access, they can still add friction against password reuse and credential stuffing, but they should be paired with tighter conditional access, device checks, and rapid account-recovery hardening. For privileged access, current best practice is to move to phishing-resistant methods such as WebAuthn or passkeys, then reserve OTPs for lower-risk recovery scenarios or break-glass paths that are tightly monitored. That approach aligns with the risk-based direction of NIST Cybersecurity Framework 2.0 and with modern identity governance that treats fallback as a controlled exception, not a default.

Operationally, teams should separate authentication from recovery and insist on different assurance levels for each. A practical model looks like this:

• Use phishing-resistant MFA for administrators, finance, developers with production access, and remote access to critical systems.
• Limit OTP use to lower-risk users, legacy applications, or time-bound migration windows.
• Remove SMS OTP where SIM swapping or carrier-channel abuse is a realistic threat.
• Harden recovery with out-of-band verification, help desk scripts, and step-up checks for account resets.
• Monitor anomalous OTP challenges, failed attempts, and repeated recovery events as possible compromise indicators.

For organisations already dealing with identity sprawl, the lesson is consistent with NHI governance concerns highlighted in the Microsoft Midnight Blizzard breach: once attackers get a foothold, weak fallback channels become a privilege escalator. These controls tend to break down when OTP is still allowed for administrator recovery, because help desk processes and legacy apps often override the intended risk model.

Common Variations and Edge Cases

Tighter authentication often increases rollout friction, requiring organisations to balance user convenience against phishing resistance and recovery safety. That tradeoff is real, especially where legacy applications, shared devices, or third-party access make passkeys difficult to deploy immediately. There is no universal standard for every exception, but the direction of travel is clear: use OTPs only where the residual risk is acceptable and the business can tolerate a weaker factor during transition.

SMS-based OTP is the least defensible variant in high-risk environments because the recovery channel is often the attack path. App-based OTP is better than SMS, but it still remains phishable and relayable, so it should not be the final answer for privileged users. In regulated or high-assurance environments, security leaders should document a phased migration path, define explicit exception criteria, and review whether any OTP fallback can be replaced by hardware-bound authenticators or managed device trust. For implementation detail and governance maturity, the identity risk patterns discussed in the Microsoft Midnight Blizzard breach are a useful reminder that recovery design matters as much as the primary login flow.

Where this guidance breaks down is in air-gapped, offline, or deeply legacy environments where WebAuthn and device-bound methods cannot yet be deployed at scale; in those cases, OTP may remain the least-bad option while the migration plan is completed.

Related resources from NHI Mgmt Group

• How should teams decide when one-time codes are still acceptable for MFA?
• What is the difference between passwordless MFA and one-time code MFA?
• One-Time Code MFA
• Why do one-time codes create a false sense of security?