Because MFA proves a user completed a challenge, not that the session was free from interception. When attackers relay the login as it happens, they can capture the authentication material, complete the session, and inherit the trusted context. For executives, that matters because the account’s authority often creates broader business and fraud exposure than the mailbox alone.
Why MFA alone does not stop real-time phishing
MFA raises the bar, but it does not guarantee that the login session was established on the right device, through the right channel, or without interception. In a real-time phishing relay, the attacker forwards the user’s credentials and one-time challenge to the legitimate service as it happens, then reuses the authenticated session context.
The key weakness is not the second factor itself, it is the assumption that proof of challenge completion equals proof of a trustworthy session. For executive accounts, that assumption is especially dangerous because a successfully hijacked session can expose email, approvals, payroll, vendor payments, and other high-impact business actions.
How relay attacks defeat the trust MFA is supposed to create
A real-time phish works because many MFA methods confirm possession or user presence at a moment in time, while the attacker is simultaneously acting as a live middleman. If the login flow accepts relayed credentials, OTPs, or approval prompts, the attacker can complete the authentication exchange and inherit the resulting session token or browser session.
That means the compromise often happens after the visible MFA event. The user may have entered a code, approved a prompt, or completed a push, yet the attacker is the one holding the authenticated session. NIST SP 800-63 Digital Identity Guidelines is useful here because it distinguishes ordinary MFA from phishing-resistant authentication that binds the authenticator to the origin.
When the defender treats all MFA as equivalent, they miss the real control question: can the login be relayed, replayed, or transferred to another endpoint before the session is established?
Why executive accounts are disproportionately attractive
Executives are targeted because the payoff is usually higher than simple mailbox access. A compromised executive session can be used for business email compromise, invoice manipulation, internal approvals, payroll diversion, board material theft, or fraudulent authority signaling to staff and partners.
Those accounts also tend to sit at the center of trust relationships. Mailboxes, calendars, collaboration tools, finance workflows, and delegated access often converge there, so one stolen authenticated session can become a launch point for broader fraud and lateral abuse. NHIMG’s Workforce Identity Security Guide is a good companion on why phishing-resistant MFA and session theft controls matter most where authority is concentrated.
Executive targeting is also operationally effective because attackers can tailor lures to urgent themes, such as board deadlines, travel, finance approvals, or password resets. The more routine and trusted the workflow feels, the easier it is for a relayed session to blend in.
What strong defence has to address beyond the MFA prompt
Defence has to move from “did the user complete MFA?” to “was the session resistant to interception and bound to the authentic client and origin?” That is where phishing-resistant methods, origin binding, shorter session lifetimes, step-up controls for high-risk actions, and anomaly detection around impossible travel or new device use become materially important.
Credential or prompt interception is only one part of the problem. The second part is limiting what a stolen session can do once it exists. MFA Guide helps practitioners separate weaker MFA patterns from phishing-resistant options, while Passwordless and Passkeys Guide is the better path when you need origin-bound sign-in that is much harder to relay in real time.
For executives, the practical standard is not “MFA enabled,” but “can a live relay still produce an authenticated session with authority, and what can that session do before detection or revocation?”
Risk and Threat Considerations
Real-time phishing turns MFA into a timing problem. If the attacker can relay the exchange before the session is established, they can capture a valid authenticated context without ever needing to defeat the factor outright. That makes the risk especially acute for accounts with delegated authority, financial reach, or privileged internal access.
Failure mechanism: The attacker proxies the login flow, harvests the resulting session token or browser session, and reuses it from a separate endpoint while the victim believes the login was legitimate.
Impact: The attacker can act as the executive inside trusted business systems, which can lead to mailbox takeover, transaction fraud, data exposure, and rapid expansion of access through trusted internal workflows.
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 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers phishing-resistant authentication and session binding for this exact login relay problem. |
| Recommendation — Use phishing-resistant authentication and bind sessions to the authentic client and origin. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Real-time relay attacks exploit weak authentication flows that accept intercepted login exchanges. |
| NHI-10 — Human Use of NHI | Executive account compromise often becomes a human-driven abuse path after session takeover. | |
| Recommendation — Adopt phishing-resistant sign-in methods that prevent credential and challenge relay. Limit human-mediated high-risk actions on accounts whose sessions can be hijacked. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The question centres on authentication being accepted while the session is intercepted or replayed. |
| Recommendation — Harden authentication flows so relayed credentials cannot establish trusted sessions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Executive accounts are organizational-user identities needing strong authentication assurance. |
| Recommendation — Require stronger authentication for privileged organizational users and high-impact access. | ||
Practitioner Guidance
What to prioritise: Treat executive sign-in as a session-security problem, not only an MFA-enablement problem. The highest value controls are phishing-resistant authentication, strict session binding, and rapid revocation when a session appears to originate from an unexpected device, network, or geography.
What to verify: Confirm whether the login method resists adversary-in-the-middle relay, whether risky actions require fresh reauthentication, and whether high-authority accounts are monitored for abnormal consent, forwarding, delegation, and payment-related activity.
Common mistake: Teams often stop at “MFA is on” and never test whether the chosen method can be relayed in real time. That leaves a control that looks strong in policy but fails at the exact point attackers exploit.
Practitioner takeaway: For executive accounts, the question is not whether MFA was completed, but whether the resulting session is origin-bound, difficult to relay, and tightly constrained once trust has been granted.
Related resources from NHI Mgmt Group
- How should security teams protect executive accounts from real-time MFA interception?
- What breaks when MFA is present but the login can still be relayed in real time?
- Why do MFA implementations still get bypassed even when organisations believe they are protected?
- Why do ephemeral credentials still leave risk in machine access models?