How should teams decide when one-time codes are still acceptable for MFA?

Why This Matters for Security Teams

One-time codes are often treated as “good enough” MFA because they are easy to deploy, but that convenience creates a false sense of assurance. For low-impact workflows, they can still reduce risk when paired with strong account recovery, device hygiene, and monitoring. For anything that can move into admin tools, customer data, or production systems, the attack path is usually shorter than teams expect. The core issue is that delivery channels like SMS or email are not the same thing as cryptographic possession.

That matters even more when secrets and identities are already overexposed. NHI Mgmt Group research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks with tangible damage in most of those incidents, which makes any reusable or interceptable factor more fragile than it appears. The NIST Cybersecurity Framework 2.0 reinforces the need to reduce credential exposure and align access decisions to risk, not convenience.

In practice, many security teams discover the weakness of one-time codes only after an inbox, phone number, or recovery path has already been compromised.

How It Works in Practice

The practical decision is not “MFA or no MFA,” but whether the factor actually resists the attacker you expect. One-time codes may be acceptable when the protected asset has low privilege, low fraud impact, short session duration, and no meaningful downstream access if the account is taken over. They are most defensible as a compensating control for low-risk user populations, not as a primary safeguard for privileged access, developer tooling, or environments that can mint credentials for other systems.

Teams should classify use cases by blast radius, then require stronger methods where the account can reach sensitive data, rotate secrets, approve payments, alter infrastructure, or impersonate other identities. That means preferring phishing-resistant authentication, hardware-backed authenticators, or tightly scoped access paths for higher-risk workflows. The guidance in NIST Cybersecurity Framework 2.0 is useful here because it pushes organisations toward measured, risk-based access controls rather than one-size-fits-all identity checks.

• Use one-time codes only for low privilege accounts with limited reach.
• Block one-time codes for admin access, production change paths, and secrets management.
• Pair them with step-up controls when access risk increases.
• Review recovery mechanisms, because takeover often happens through the recovery path rather than the login prompt.

This should be read alongside real compromise patterns such as the Microsoft Midnight Blizzard breach and the JetBrains GitHub plugin token exposure, both of which show how quickly identity weakness becomes platform-wide exposure. These controls tend to break down when one-time codes are used to protect accounts that can create, export, or reuse secrets because the attacker only needs one successful interception to pivot into more privileged systems.

Common Variations and Edge Cases

Tighter MFA policy often increases user friction and recovery overhead, so organisations have to balance usability against the real cost of compromise. There is no universal standard for exactly when a one-time code becomes unacceptable, but current guidance suggests treating the decision as a risk threshold rather than a binary policy.

One edge case is customer-facing or legacy systems that cannot support phishing-resistant authenticators. In those environments, one-time codes may remain a transitional control if compensating safeguards are strong: device binding, anomaly detection, rate limiting, monitored recovery, and strict privilege separation. Another is workforce populations with constrained device access, where a temporary exception may be needed while the organisation phases in stronger methods.

That said, one-time codes should not be used where the account can access secrets, delegate to other systems, or approve sensitive business actions. The more downstream authority an account has, the more the organisation should move toward stronger factors and shorter-lived access decisions. The NIST Cybersecurity Framework 2.0 supports this kind of control layering, while the breach patterns in the JetBrains GitHub plugin token exposure case remind teams that once a token or session is exposed, the original factor is no longer the main problem.

Related resources from NHI Mgmt Group

• How should security teams authenticate AI agents in enterprise environments?
• Why do ephemeral credentials still leave risk in machine access models?
• How should security teams implement Client ID Metadata Documents?
• How can teams decide which identities need just-in-time access?