Join our Newsletter — 33% off our NHI Course
Home› FAQ› Authentication, Authorisation & Trust› Why do some MFA methods still allow proxy…
Authentication, Authorisation & Trust

Why do some MFA methods still allow proxy betting and account takeover?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 13, 2026 Domain: Authentication, Authorisation & Trust

Because they verify identity at login but do not always preserve identity integrity for the whole session. Passwords can be shared, knowledge questions can be guessed or purchased, documents can be difficult to capture reliably, and a logged-in session can be handed to someone else. The weakness is in reuse, not only in initial authentication.

Why MFA can verify the login and still fail to protect the session

MFA is strongest when it binds the right person or system to the whole access path, not just the moment of sign-in. If a method can be replayed, shared, intercepted, or bypassed through recovery and help-desk flows, an attacker can still end up with a valid session. That is why session integrity matters as much as the initial challenge.

Methods that rely on static secrets, reusable knowledge, or easily transferred tokens may stop a simple password-only login attempt, yet still leave room for reuse after authentication. A broker, helper, or attacker does not need to defeat the factor again if they can obtain or hand off the active session, cookie, device token, or recovery path. For a useful comparison of factor strength and bypass patterns, see MFA Guide and NIST’s Digital Identity Guidelines.

That is also why phishing-resistant methods are better, but not magically complete. Passkeys and security keys reduce relay, phishing, and credential reuse risk, while weaker methods remain vulnerable to code interception, push fatigue, or account recovery abuse. The practical question is not whether MFA exists, but whether the method preserves identity integrity after the login ceremony has finished. NHIMG’s Passwordless and Passkeys Guide explains why stronger authentication narrows this gap.

How proxy betting and account takeover happen after a valid sign-in

Proxy betting works when an attacker or broker gets a legitimate authenticated session and then operates inside it, often without needing to reauthenticate. The login may have been “real,” but the resulting session is being used by the wrong person. The same pattern drives account takeover in other environments: the attacker inherits trust already granted to the session rather than breaking authentication from scratch.

Common paths include password reuse, stolen tokens, session-cookie theft, MFA fatigue, and recovery-channel compromise. In some cases, the victim’s browser or device is not the target at all, only the container that holds the active session. Once the session is live, the attacker can browse, place wagers, change settings, or escalate to additional actions that the original authentication method never rechecks.

This is why incident patterns that involve valid credentials or stolen sessions are so persistent. NHIMG’s Colonial Pipeline ransomware attack and CitrixBleed exploitation 2023 both show the same underlying issue: once an attacker gets a valid access path or a reusable session artifact, MFA at the front door no longer protects what happens inside the session.

Why the control problem is reuse, not just authentication strength

The core control failure is assuming that proving identity once is enough. It is not, if the access model allows long-lived sessions, weak recovery, shared devices, permissive reauthentication, or delegated use of the account by a third party. In practice, proxy betting and account takeover expose a control boundary problem: authentication is treated as the endpoint, when it should only be the start of ongoing access assurance.

Methods that depend on one-time codes, call-backs, SMS, or knowledge-based checks can still be vulnerable when an attacker can observe, relay, buy, guess, or socially engineer the factor. Even strong methods can fail if the session token is stolen, if recovery is weak, or if the account can be used on a device the user no longer controls. For identity lifecycle and access governance, NHIMG’s Workforce Identity Security Guide is useful because it ties sign-in strength to session theft, step-up checks, and recovery design.

Risk and Threat Considerations

When MFA does not protect the session, the exposure is broader than simple login fraud. The attacker can act with the same privileges as the legitimate user, so the failure mode becomes unauthorized activity after access has already been granted. That makes account takeover and proxy use especially dangerous in environments where real-time fraud detection is weak or where session reuse is difficult to distinguish from normal behavior.

Failure mechanism: The method verifies an event at sign-in, but the session can later be reused, relayed, or transferred without proving the same actor still controls it. Weak recovery, replayable factors, and stolen session artifacts create the gap.

Impact: Attackers can place bets, change account details, exfiltrate data, or pivot into higher-value abuse while appearing to be an authenticated user. In regulated or high-value workflows, that also creates fraud, dispute, and audit problems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-63AAL — Authenticator Assurance LevelSession takeover risk depends on authenticator strength and phishing resistance.
Recommendation — Select phishing-resistant authenticators and step-up controls for sensitive actions.
NIST SP 800-53 Rev 5IA-2 — Identification and Authentication (Organizational Users)The question centers on authentication methods that can still be abused after login.
IA-5 — Authenticator ManagementProxy betting and takeover often exploit weak secrets, reuse, or recovery handling.
IA-11 — Re-authenticationThe issue is whether access is revalidated during an ongoing session, not only at login.
Recommendation — Require stronger authenticator checks for user sign-in and reauthentication. Set rotation, storage, and lifecycle rules that reduce replayable credential abuse. Force reauthentication for risky actions and session continuation checkpoints.
NIST Zero Trust (SP 800-207)ZTA — Zero Trust ArchitectureThe answer depends on continuous verification after initial authentication.
Recommendation — Continuously evaluate session trust before allowing sensitive access or actions.

Practitioner Guidance

What to verify: Treat session binding as a first-class control, not an afterthought. If a user can stay authenticated after the original device, factor, or browser state is no longer trustworthy, the control is weaker than it looks.

Common mistake: Do not judge MFA only by whether it stops password-only login. Ask whether it resists relay, token theft, recovery abuse, and handoff of an active session.

What good looks like: Strong methods, short session lifetimes, step-up checks for sensitive actions, and recovery flows that are harder to abuse than the sign-in path itself.

Practitioner takeaway: The right question is not “Did MFA happen?” but “Does the access remain attributable to the same actor after authentication?”

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org