Multifactor authentication requires two or more different factor types to complete sign-in, such as something known, possessed or inherent. Attackers can still bypass weak implementations through phishing, push fatigue or session theft, so prefer phishing-resistant methods where possible and monitor for impossible travel, repeated prompts and anomalous device enrolment.
What multifactor authentication actually verifies
Multifactor authentication strengthens sign-in by requiring more than one factor class, usually combining knowledge, possession, and inherence. The point is not simply adding another checkbox, but making a stolen password or a leaked code insufficient on its own. That is why the most useful implementations pair a primary password with a second factor that is harder to phish or replay.
The practical distinction is between proving that the user knows something, owns something, or is something. A one-time code, push approval, security key, or biometric prompt all sit in different factor categories, and the security outcome depends on how resistant the chosen method is to interception, replay, or social engineering.
Good sign-in design also treats enrollment as part of authentication, not an afterthought. If an attacker can add a new device, approve their own recovery path, or hijack a help desk reset, the second factor may exist but still fail to protect the account.
Why MFA can still be bypassed
MFA reduces risk, but it does not eliminate it. Weak implementations are still vulnerable to phishing, push fatigue, adversary-in-the-middle relay, session theft, and account recovery abuse. In other words, the second factor is only valuable if the attacker cannot cheaply capture, replay, or trick the user into producing it.
That is why the strongest methods are phishing-resistant, especially when the protected account has broad access or sensitive administrative reach. A code sent by SMS or generated in an app can be copied in real time; a prompt can be accepted out of habit; a browser session can be stolen after authentication and used without re-entering the factor again.
Practitioners should also remember that MFA controls the login moment, not every later action. If the session cookie, refresh token, or device trust state is compromised after sign-in, the attacker may bypass the authentication challenge entirely until the session expires or is revoked.
How to think about MFA in day-to-day operations
MFA is best understood as a layered control around identity proofing, access entry, and session continuity. It helps most when paired with least privilege, conditional access, and careful recovery controls. It helps least when organisations rely on weak methods, broad exception lists, or unmonitored enrollment changes that quietly expand attack surface.
Operationally, the most important question is not whether MFA is enabled, but whether the deployed method meaningfully resists the attacks your users actually face. A phishing-resistant method on critical accounts is materially different from a time-based code on a low-risk account, and the gap matters most where attacker payoff is highest.
Telemetry matters as much as the method. Repeated prompts, impossible travel, new device enrolment, unexpected recovery events, and session reuse from unusual locations are all signs that the control may be under stress or already bypassed. The authentication flow should be treated as observable security activity, not just a user convenience feature.
Risk and Threat Considerations
MFA creates a stronger barrier, but weak MFA patterns still leave room for credential phishing, prompt bombing, session hijacking, and abuse of recovery flows. The main risk is false confidence: teams assume the presence of MFA means the account is safe, even when the attacker can still steal the session or socially engineer approval.
Failure mechanism: The attacker either captures both factors in real time, coerces approval through repeated prompts, or bypasses the challenge by stealing an already-authenticated session or enrolling a new trusted device.
Impact: Account takeover can still occur, and once the account is trusted, the attacker may access downstream applications, data, admin consoles, or privileged workflows without needing to repeat the MFA challenge.
Practitioner Guidance
What to prioritise: Use phishing-resistant MFA for high-value users, admin roles, and any account that can approve access, recovery, or privileged actions. That is where the choice of factor type most changes the real-world outcome.
What to verify: Confirm that recovery paths, device enrolment, and help desk resets are at least as strong as the sign-in method itself. Many MFA failures happen outside the login screen, not inside it.
What good looks like: Users complete sign-in with a resistant factor, unusual prompts are visible to defenders, and any new device or recovery event is investigated as an identity-risk signal rather than accepted as routine.
Practitioner takeaway: MFA is only as strong as its weakest adjacent process, so the right question is not “is MFA enabled?” but “can an attacker still phish, fatigue, or recover around it?”