MFA stops simple credential replay, but it does not stop an attacker who can proxy the live login flow and inherit the resulting session. The broken assumption is that successful authentication proves the right person is in control. In real-time phishing, the identity provider sees a valid user, while the attacker owns the workflow that produced it.
Why This Matters for Security Teams
Real-time relay breaks the security value of MFA because the attacker does not need to defeat the factor, only to borrow the live session outcome. That shifts the problem from password theft to session hijacking, and it means access reviews that only ask whether MFA is enabled can miss the actual failure mode. NIST’s NIST Cybersecurity Framework 2.0 treats identity assurance as part of a broader control system, not a checkbox.
This is especially dangerous in environments where identity providers, SaaS apps, and browser sessions are tightly integrated. Once a relay succeeds, downstream systems often trust the assertion without re-checking device state, user intent, or transaction context. NHIMG research on the Microsoft Midnight Blizzard breach is a reminder that identity compromise often becomes operational compromise long before defenders see a clear alert. In practice, many security teams encounter session abuse only after mailbox access, token theft, or lateral movement has already begun, rather than through intentional detection of the relay path.
How It Works in Practice
In a real-time phishing relay, the attacker sits between the user and the legitimate service. The victim enters credentials and approves MFA on a fake or proxied login page, while the attacker forwards each step to the identity provider in real time. The provider sees a valid authentication flow, issues a session cookie or token, and the attacker captures the authenticated session. From that point, the attacker may no longer need the password or the second factor.
That breaks the common assumption that MFA alone proves the login is trustworthy. Current guidance suggests adding controls that make the login outcome harder to reuse outside the original context:
- Use phishing-resistant authenticators where possible, especially FIDO2/WebAuthn, because they bind authentication to the origin.
- Reduce the value of stolen sessions with short-lived tokens, conditional access, and device binding.
- Step up authentication for sensitive actions, not just at initial sign-in.
- Detect impossible travel, new device enrollment, abnormal consent grants, and token reuse from unfamiliar networks.
- For high-risk applications, require transaction-level verification rather than relying on a one-time login event.
For identity-heavy environments, the bigger lesson is that authentication must be evaluated alongside session integrity and workload trust. NHIMG’s Ultimate Guide to Non-Human Identities shows why persistent credentials and weak lifecycle controls create long-lived exposure, and the same logic applies when human sessions are being relayed in real time. These controls tend to break down when legacy apps accept bearer sessions without device or phishing-resistant binding because the session becomes the only proof the app ever checks.
Common Variations and Edge Cases
Tighter login controls often increase user friction and support overhead, so organisations have to balance phishing resistance against deployment complexity. That tradeoff matters because not every app, directory, or device fleet can support strong session binding yet. Best practice is evolving, and there is no universal standard for every application type.
Some environments are especially hard to protect:
- Legacy SSO integrations that accept any valid browser session without additional checks.
- Help desk or admin workflows where users are trained to complete logins quickly under pressure.
- Bring-your-own-device scenarios where endpoint trust is weak or inconsistent.
- High-volume SaaS environments where conditional access is broad but not transaction-aware.
Another edge case is that MFA fatigue or push-based approval abuse can look like relay when the root problem is social engineering rather than a proxy tool. The right response depends on whether the attacker is relaying the session, harvesting tokens after sign-in, or coercing approval. Where possible, pair phishing-resistant authentication with device posture checks and stronger session revocation. If an attacker can present a live login flow back to the service, then the factor was never the last line of defense, only one step in a chain that still ended in a stolen session.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Covers authentication bypass and session abuse patterns attackers use in real-time relays. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Session and secret misuse parallels the broader problem of credential replay and token theft. |
| CSA MAESTRO | TRUST-02 | Highlights trust validation for agentic and automated access paths that may be hijacked. |
| NIST AI RMF | Risk management requires assessing whether authentication truly proves user control. | |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and authentication controls must address session relay and phishing resistance. |
Prefer phishing-resistant auth and bind sessions to origin, device, and context at request time.
Related resources from NHI Mgmt Group
- What breaks when MFA still depends on human approval and one-time prompts?
- What breaks when MFA does not evaluate user risk in real time?
- Why do access certifications still feel weak even when reviews are completed on time?
- What breaks when MFA recovery is handled by the same team that grants account resets?
