Why do passwords remain a problem even when MFA is deployed?

Why Passwords Still Matter After MFA

Passwords remain a live security problem because MFA adds a second check, but it does not remove the weakness of a shared secret that can be phished, reused, guessed, or stolen from a browser, endpoint, or database. If the password is already exposed, the attacker is halfway in before the second factor is challenged. That is why password-based access still expands attack surface even in environments that claim strong MFA coverage.

For security teams, the practical issue is not whether MFA exists, but whether the first factor is still exploitable at scale. A single reused password can unlock email, VPN, SaaS, and admin portals, and the blast radius grows when users store credentials in unmanaged tools or when secrets leak into code and logs. NHIMG research on Microsoft Midnight Blizzard breach shows how identity abuse can persist long after initial compromise, while the NIST Cybersecurity Framework 2.0 continues to emphasise strong identity, access control, and recovery discipline rather than reliance on one control alone.

In practice, many security teams discover password weakness only after token theft or account takeover has already turned MFA into a speed bump instead of a barrier.

How MFA Fails in Real Attacks

MFA fails most often when the attacker does not need to defeat it directly. Password spraying, credential stuffing, help-desk impersonation, session hijacking, adversary-in-the-middle phishing, and push fatigue all target the human and operational layer around the login flow. The control is still useful, but it is not a guarantee of account integrity.

Current guidance suggests treating MFA as one layer in a broader identity strategy. That means reducing password dependence where possible, adding phishing-resistant factors, and binding sessions more tightly to device posture and risk signals. A password that is reused across services or recovered from a breach can still become a valid entry point unless the surrounding controls stop reuse, detect impossible travel, and revoke suspicious sessions quickly. The DeepSeek breach is a useful reminder that exposed credentials and secrets do not stay theoretical for long, especially once attackers can automate discovery and login attempts.

• Use phishing-resistant MFA where possible, not only SMS or one-time codes.
• Block known breached passwords and enforce strong password hygiene.
• Reduce standing access and shorten session lifetimes for sensitive systems.
• Monitor for impossible travel, anomalous device fingerprints, and token replay.

These controls tend to break down in legacy applications that only support passwords plus a single second factor, because the session remains usable even after the original credential has been exposed.

Where the Real Tradeoffs Show Up

Tighter identity controls often increase user friction and help-desk load, so organisations have to balance security gains against operational disruption. That tradeoff is real, but the larger risk is treating MFA as a finish line when it is really a compensating control.

There is no universal standard for this yet, but best practice is evolving toward passwordless authentication, phishing-resistant MFA, and stronger lifecycle control over secrets. For environments that still depend on passwords, the key question is not simply whether MFA is enabled, but whether passwords can be phished, reused, or extracted from adjacent systems. In regulated or high-risk environments, the safest path is to combine MFA with NIST Cybersecurity Framework 2.0 identity governance, rapid revocation, and continuous monitoring rather than assuming a one-time login check is enough.

That matters most when privileged users, service accounts, or shared administrative portals still accept static passwords, because those accounts concentrate access and are the hardest to recover from after compromise.

Related resources from NHI Mgmt Group

• What is the difference between MFA and zero trust authentication?
• How should security teams replace traditional MFA without creating new access friction?
• Why do session tokens create risk even when passwords are unchanged?
• Why do OAuth tokens create a larger NHI governance problem than passwords?