When does password-based MFA create more risk than it removes?

Why This Matters for Security Teams

Password-based MFA fails most obviously when it changes the attacker’s job from breaking authentication to manipulating the user. Push fatigue, prompt bombing, OTP relay, and weak recovery workflows can turn a second factor into a second channel for compromise. That is why guidance from NIST Cybersecurity Framework 2.0 and current NHI research both emphasise assurance, not ceremony. The broader NHI picture is not reassuring: Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 91.6% of secrets remain valid five days after notification, which shows how often weak controls persist long after they should have been removed.

For human users, MFA is meant to raise the cost of compromise. But if the second factor can be socially engineered, intercepted, or bypassed through fallback support paths, it increases workflow complexity without materially improving assurance. Teams often miss that the real control objective is not “MFA present” but “MFA resistant to the dominant attack path.” In practice, many security teams encounter the failure only after an adversary has already trained users to approve prompts or abuse recovery flow, rather than through intentional testing.

How It Works in Practice

The practical test is whether the factor remains bound to the authentic user in a way the attacker cannot easily proxy. OTPs sent by SMS or email are vulnerable to interception, SIM swapping, mailbox takeover, and forwarding rules. Push MFA can be undermined when users are overwhelmed by repeated prompts. Recovery paths such as help-desk resets, backup codes, and unenforced device re-enrolment often become the easiest route around the control. That is why many practitioners now treat password-based MFA as a transitional measure, not a high-assurance end state.

For NHI and agentic environments, the same lesson becomes even sharper. If a workload or agent can hold long-lived secrets, reuse tokens, or inherit broad privileges, MFA does nothing to constrain post-authentication abuse. Better patterns combine strong workload identity with short-lived credentials, JIT issuance, and policy enforcement at request time. The OWASP NHI Top 10 highlights how autonomous systems need runtime controls, not just login gates, while Top 10 NHI Issues shows why excess privilege and poor secret hygiene keep compounding risk.

• Prefer phishing-resistant factors over OTPs where business risk is material.
• Use recovery that is identity-verified, audited, and tightly rate-limited.
• Pair MFA with PAM, RBAC, and JIT so approval is not the only barrier.
• For workloads, use cryptographic workload identity and short TTL secrets instead of user-style MFA.

These controls tend to break down when legacy applications require SMS or email fallback because the organisation cannot enforce modern authentication end to end.

Common Variations and Edge Cases

Tighter authentication often increases user friction and operational support costs, so organisations must balance assurance against availability and help-desk load. There is no universal standard for this yet, but current guidance suggests that risk should drive the factor choice: low-risk consumer login flows can tolerate weaker MFA more readily than privileged admin access, financial operations, or machine-to-machine trust.

One edge case is step-up MFA for sensitive actions. That can still be useful if the step-up is phishing-resistant and the recovery path is not easier to exploit than the primary path. Another is shared devices, where persistent sessions and weak local controls can quietly undo a strong second factor. For administrative access, Microsoft Midnight Blizzard breach remains a reminder that identity controls fail when attackers can turn operational exceptions into access. External guidance from NIST Cybersecurity Framework 2.0 is still useful here because it frames authentication as part of a broader risk-management program, not a standalone checkbox.

For autonomous agents, the tradeoff is clearer: when behaviour is goal-driven and unpredictable, password-based MFA is usually the wrong abstraction altogether. Best practice is evolving toward intent-based authorisation and workload identity, because a prompt that proves “someone approved” does not prove the agent should act. In practice, password-based MFA creates more risk than it removes when the second factor becomes the attacker’s preferred path into the account.

Related resources from NHI Mgmt Group

• How should security teams phase out password-based authentication without disrupting operations?
• What is the difference between passwordless authentication and password-based access?
• How should organisations reduce MFA-related account takeover risk?
• How should security teams use context-based authentication in high-risk environments?