What breaks when SaaS identities are phished even with MFA in place?

Why MFA still breaks at the session layer

Phishing-resistant sign-in and push-based MFA are not the same thing. If an attacker runs an adversary-in-the-middle flow, the victim may complete the MFA prompt correctly while the attacker captures the authenticated browser session or token. At that point, the identity provider is no longer being “bypassed” at login, it is being used exactly as designed, but against the wrong party.

The practical failure is that many SaaS platforms trust the session after issuance more than they trust the original MFA step. A valid session can outlive the challenge, be replayed from another device, and sometimes remain usable until it expires or is revoked. That is why session token theft bypasses MFA in real incidents, and why defenders have to treat session handling as part of authentication security, not a separate convenience layer.

In other words, the protected asset shifts from the password or MFA challenge to the post-authentication session. If the session is not strongly bound to the device, browser, or proof-of-possession mechanism, the attacker only needs one successful login relay to inherit the user’s access.

Where SaaS control assumptions fail

The common control assumption is that MFA proves the user is legitimate, so subsequent SaaS access is safe. That assumption breaks when the attacker steals the bearer token, refresh token, or session cookie after authentication. The SaaS app may still see a valid identity, a valid tenant, and a valid token, which means conditional access can be satisfied even though the original login was mediated by the attacker.

This matters most where SaaS sessions are long-lived, reauthentication is infrequent, and sensitive actions are allowed without additional step-up checks. A session can remain active across email, file storage, admin consoles, and API-backed workflows, so one phished sign-in can become broad account takeover. The pattern is the same across workforce identity security guidance: the session, not just the prompt, is the control boundary that needs protection.

That is also why push MFA alone is weak protection against phishing. It authenticates the prompt response, not the origin of the request. A relay attack preserves the illusion of a successful login while transferring the authenticated state to the adversary.

What to protect instead of relying on the prompt

Defenders need to protect the session lifecycle: issue stronger authenticators, shorten token lifetime where possible, revoke active sessions quickly, and prefer phishing-resistant methods that reduce relayability. A more resilient model combines device-bound or proof-of-possession style authentication with session monitoring so a stolen token cannot simply be replayed elsewhere.

For SaaS environments, the best indicator that the control is working is not whether users can complete MFA, but whether stolen sessions can be detected, contained, and invalidated before an attacker performs meaningful actions. The difference is operational: a good login flow can still fail if session revocation, token binding, and reauthentication policy are weak. NIST SP 800-63 Digital Identity Guidelines is useful here because it distinguishes authenticator strength from session assurance and phishing-resistant authentication.

Risk and Threat Considerations

Phishing that steals a session instead of a password can turn a single successful login into durable account compromise. The user may never realise the login was relayed, which makes this a high-confidence threat path for SaaS access, especially where tokens are reusable across multiple apps and administrative actions.

Failure mechanism: The attacker proxies the login, captures the authenticated session artifact, and replays it from a separate device or network location while the SaaS provider still trusts the session as legitimate.

Impact: The attacker can read data, move laterally through SaaS integrations, change settings, create persistence, or abuse delegated access even though MFA was completed.

Practitioner Guidance

What to verify: Check whether your SaaS stack supports session invalidation, token revocation, device or browser binding, and reauthentication for sensitive actions. If it does not, assume MFA completion alone is not enough to contain a phished login.

Common mistake: Treating “MFA enabled” as equivalent to “phishing resistant.” Push prompts reduce some risk, but they do not stop adversary-in-the-middle token theft unless the login method and session model resist replay.

Decision rule: If a session can be reused from a different endpoint after the user finishes MFA, prioritise phishing-resistant authentication and session hardening before adding more user training. The control gap is usually in the session, not the user’s willingness to approve a prompt.

Practitioner takeaway: The right question is not whether the MFA prompt was approved, it is whether the resulting session can be stolen, replayed, and abused before you can detect and revoke it.

Related resources from NHI Mgmt Group

• Why do weak SaaS posture settings create risk even when SSO and MFA are in place?
• Why do machine identities create risk even when MFA is enabled?
• What breaks when SaaS integrations are not governed as non-human identities?
• What breaks when orphaned machine identities are left in place?