Can social engineering bypass MFA without breaking the factor itself?

How social engineering can reach past MFA

Social engineering usually does not “break” MFA in the cryptographic sense. It pressures the user into approving a login, handing over a one-time code, or completing a sign-in through a fake or relay page, so the attacker gets an authenticated session rather than defeating the factor itself.

That distinction matters because the security failure is often at the point where the session is created or handed off, not at the point where the factor is verified. Once the attacker has a valid session token, cookie, or device-bound artefact, they may no longer need to touch MFA again.

Why the session is often the real target

Many phishing and adversary-in-the-middle campaigns are built to capture the result of a successful MFA flow, then reuse the resulting session. Workforce Identity Security Guide is useful here because it frames the operational gap between strong sign-in controls and session theft, which is where many real-world compromises land.

Push fatigue, code relay and fake login pages work because they exploit user trust, urgency and routine behaviour. Even when the factor itself is phishing-resistant in theory, a user can still be tricked into approving the wrong sign-in context, especially if the attacker can mimic the familiar identity provider flow closely enough.

Session theft changes the problem from authentication to access persistence. The attacker’s goal becomes keeping the token alive long enough to move laterally, collect data or establish a foothold before the session expires or is revoked.

What defenders should look for when MFA “fails”

When an incident report says MFA was bypassed, the first question should be whether the attacker actually bypassed the factor, or instead captured a valid session after MFA completed. MFA Guide helps distinguish factor weaknesses from relay, fatigue and token theft scenarios, which lead to different response actions.

Look for impossible travel, repeated push prompts, new device enrolment, unfamiliar browser fingerprints, token use from a fresh IP, or a session that continues after a user claims they never approved the login. Those signals point to session compromise, not just weak password entry.

That distinction affects remediation. If the attacker only captured a code, the priority is credential reset and MFA hardening. If the attacker captured an active session, you also need token revocation, device/session invalidation, and a review of whatever the session accessed before it was killed.

Risk and Threat Considerations

Social engineering against MFA is attractive because it avoids having to defeat the factor itself. The attacker only needs one successful approval, one relayed code, or one stolen cookie to turn a legitimate authentication event into unauthorised access.

Failure mechanism: The user completes MFA, but the attacker intercepts or reuses the resulting session token, cookie, or federated artefact, so access continues without re-running the factor.

Impact: Organisations can miss the compromise because the login appears valid, while the attacker quietly gains persistence, performs data access, or moves into higher-value systems through an apparently authenticated session.

Practitioner Guidance

What to prioritise: Treat “MFA bypass” reports as a session-assurance problem until proven otherwise. The key question is whether the attacker got a one-time approval or a reusable authenticated session, because the response differs materially.

What to verify: Check whether your identity stack binds sessions to device state, location, or reauthentication triggers, and whether you can revoke active tokens quickly across all affected applications. A control that only protects initial sign-in is incomplete if session replay remains easy.

Decision rule: If the attacker had any chance to capture a token, cookie, or authenticated browser session, rotate or revoke session material first, then assess password, MFA method, and account recovery exposure. If the only evidence is failed prompt abuse, focus on MFA hardening and user reporting speed.

Practitioner takeaway: The right defensive model is not “Can MFA be broken?”, but “Can an attacker turn a successful MFA event into durable session access?”

Related resources from NHI Mgmt Group

• Guide: MFA Fatigue and Bypass Guide
• Why do social engineering attacks still bypass strong MFA programs?
• What happens when organisations deploy MFA without user training and social engineering awareness?
• Why do phishing-resistant MFA controls still fail against social engineering?
• How can teams migrate from MFA to passwordless without breaking access?