How should organisations decide whether to keep using traditional MFA?

Organisations should keep MFA only where the control matches the risk and where stronger phishing-resistant methods are not yet practical. High-value roles, administrative access, and recovery flows should move first. The decision should be based on attack resistance, user behaviour, and recovery design, not on whether a second factor exists on paper.

Why This Matters for Security Teams

Traditional MFA is still useful, but it is not automatically the right control for every identity path. Security teams need to decide based on resistance to phishing, token replay, push fatigue, session hijacking, and recovery abuse. The key issue is whether the factor meaningfully reduces the attacker’s ability to impersonate the user under realistic conditions, not whether a login screen asks for a second step.

This matters most where MFA is being used as a blanket answer for privileged access, help desk resets, or administrative approval. NIST Cybersecurity Framework 2.0 treats identity assurance as part of broader risk governance, which means the control should fit the threat path and the business process, not the other way around. For identity-specific breach patterns, see Microsoft Midnight Blizzard breach and JetBrains GitHub plugin token exposure, where credential handling and access pathways mattered more than the presence of a nominal second factor.

In practice, many security teams encounter MFA failure only after the attacker has already turned authentication into a recovery or session-abuse problem, rather than through intentional control testing.

How It Works in Practice

The decision to keep MFA should start with a role-by-role and flow-by-flow review. Standard MFA may remain acceptable for low-risk self-service access, but it should be phased out or supplemented where phishing-resistant authentication, device-bound credentials, or step-up controls are feasible. For high-value roles, administrative consoles, and break-glass access, organisations should prioritise stronger controls such as FIDO2 or certificate-backed methods, and align them with NIST Cybersecurity Framework 2.0 expectations for access control and governance.

Operationally, the question is not “does MFA exist?” but “what attack paths still work after MFA is satisfied?” That includes social engineering of push prompts, adversary-in-the-middle proxies, stolen session cookies, and recovery-channel compromise. Stronger assurance also depends on the quality of the underlying identity lifecycle: device posture, joiner-mover-leaver controls, and revocation speed. In NHI-heavy environments, the same principle applies to secrets and service accounts. If long-lived credentials are still exposed in pipelines or code, MFA on the human front door does little to reduce lateral movement. The remediation gaps discussed in the Microsoft Midnight Blizzard breach and JetBrains GitHub plugin token exposure illustrate how access control failures often begin with token or secret exposure, not password theft.

• Keep MFA where the threat is moderate and phishing-resistant replacement is not yet practical.
• Replace it first for admin, developer, and recovery flows that can be phished or socially engineered.
• Use JIT elevation and stronger step-up methods for privileged actions rather than relying on a static second factor.
• Make revocation and recovery part of the control design, because attackers often target those paths.

These controls tend to break down in environments with legacy VPNs, shared admin workstations, or fragmented recovery processes because the weakest path bypasses the MFA check entirely.

Common Variations and Edge Cases

Tighter authentication often increases friction and support cost, so organisations need to balance assurance against user disruption and operational maturity. That tradeoff is especially visible in environments that still depend on legacy protocols, contractor access, or geographically distributed operations.

Current guidance suggests keeping traditional MFA only as a transitional control where stronger methods cannot yet be deployed. There is no universal standard for this yet, but best practice is evolving toward phishing-resistant methods for privileged users and context-aware access for everyone else. In some cases, MFA remains a sensible backup for low-risk workloads or as a fallback during rollout, provided it is not the primary defence for sensitive systems.

For NHI governance, the same decision logic applies to secrets, API keys, and service accounts: long-lived credentials should be reduced, rotated, or replaced with short-lived issuance wherever possible. NIST’s risk-based approach supports this, while identity breach cases show why the issue is usually exposure and persistence, not just authentication ceremony. When a business process depends on help desk resets, shared credentials, or emergency bypasses, traditional MFA can give a false sense of resilience. Organisations should treat those exceptions as redesign candidates, not permanent waivers.

The practical rule is simple: keep MFA where it still lowers risk materially, but move quickly to stronger, phishing-resistant controls where the user, workload, or recovery path can be abused.

Related resources from NHI Mgmt Group

• How can organisations tell whether authentication is actually phishing-resistant?
• How should security teams replace traditional MFA without creating new access friction?
• What is the difference between passwordless authentication and traditional MFA?
• What is the difference between traditional MFA and passwordless authentication?