Subscribe to the Non-Human & AI Identity Journal
Home FAQ Authentication, Authorisation & Trust Why do password-based MFA controls still get bypassed…
Authentication, Authorisation & Trust

Why do password-based MFA controls still get bypassed in practice?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated June 24, 2026 Domain: Authentication, Authorisation & Trust

They still depend on reusable secrets or coercible approvals, which attackers can steal, relay, or pressure users into accepting. OTPs, SMS codes, email codes, and push prompts can all be manipulated if the attacker controls the login path or the user is fatigued. That is why phishing-resistant design matters more than adding another factor.

Why This Matters for Security Teams

Password-based MFA often fails because it still anchors trust to something the attacker can intercept, replay, or coerce. OTPs, SMS, email codes, and even push approvals can be defeated when the login channel is already compromised or when the user is manipulated into approving the request. This is why current guidance increasingly favors phishing-resistant methods and better session controls, not just more factors. NHI Management Group has also documented how weak credential hygiene amplifies this problem, including the finding that 96% of organisations store secrets outside of secrets managers in vulnerable locations.

The security issue is not only authentication strength, but where the factor is consumed, how long it remains valid, and whether the user can be tricked into completing the flow on behalf of an attacker. The NIST Cybersecurity Framework 2.0 treats identity assurance, access control, and detection as linked outcomes, which is the right lens for MFA bypass analysis. Teams that treat MFA as a checkbox often miss the real failure mode: the adversary is not breaking the factor, but exploiting the human and protocol path around it. In practice, many security teams encounter MFA bypass only after valid sessions have already been abused, rather than through intentional design review.

How It Works in Practice

Bypass usually happens at the boundary between identity proofing, factor delivery, and session establishment. If an attacker phishes a password and then relays the login in real time, OTPs and push prompts can authenticate the attacker’s session instead of blocking it. If the factor is delivered over the same channels the attacker has already compromised, the second step provides little additional resistance. This is why modern guidance prefers phishing-resistant methods, such as FIDO2 or passkeys, because they bind the assertion to the origin and device rather than simply to a reusable secret.

Operationally, teams should look at MFA as a set of controls, not a single control. Strong practice usually includes:

  • Phishing-resistant authenticators for high-risk users and privileged access
  • Conditional access that evaluates device state, location, and risk at runtime
  • Short-lived sessions with reauthentication for sensitive actions
  • Step-up checks for admin changes, money movement, or data export
  • Monitoring for push fatigue, token replay, and impossible-travel patterns

For non-human identities, the lesson is even sharper. NHI Management Group notes in the Ultimate Guide to NHIs — Standards that identity assurance depends on lifecycle control, rotation, and visibility, not merely initial authentication. The same principle applies to human MFA: if the factor is static, reusable, or easily relayed, the attacker only needs to win once. Frameworks such as CISA Zero Trust guidance and passkeys reflect the industry shift toward origin-bound, phishing-resistant authentication.

These controls tend to break down in hybrid environments with legacy SSO, SMS fallback, shared admin accounts, or help desk-driven resets because the weakest recovery path becomes the real bypass path.

Common Variations and Edge Cases

Tighter MFA often increases user friction and support overhead, requiring organisations to balance resistance to bypass against operational usability. That tradeoff matters because the most secure factor is still bypassable if recovery, enrolment, or exception handling is weak. Best practice is evolving, and there is no universal standard for every environment yet.

One common edge case is step-up MFA for privileged actions. This can help, but only if the session is revalidated against the action being requested. Another edge case is legacy email or SMS recovery, which can silently defeat a strong primary factor. Organisations should also treat fatigue attacks, browser-based token theft, and adversary-in-the-middle kits as distinct threats, because each one breaks MFA in a different way.

The practical takeaway is that password-based MFA is still useful as a baseline, but it should not be the final trust decision for sensitive access. For high-value systems, current guidance suggests moving toward phishing-resistant authentication, stronger recovery governance, and runtime risk evaluation aligned with the NIST Cybersecurity Framework 2.0. In real incidents, bypass usually succeeds because the organisation trusted the fallback path more than the factor itself.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AA-1Identity assurance and authentication strength are central to MFA bypass risk.
OWASP Non-Human Identity Top 10NHI-03Reusable secrets and weak rotation enable credential replay and bypass.
NIST SP 800-63IAL/AAL guidanceDefines assurance levels and phishing-resistant authenticator expectations.

Use phishing-resistant authentication and tighten recovery paths for high-risk access.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org