Myth
“MFA means accounts are safe”
MFA reduces password replay. It does not prevent token theft, session hijack, or privileged policy changes made using already-authenticated access.
Research Note · MFA & Session
The MFA Mirage
Strong authentication, weak security
MFA dramatically reduces commodity credential attacks. But modern compromises often avoid “beating MFA” entirely; by abusing sessions, tokens, OAuth consent, and legacy authentication paths that sit outside the login challenge you think you’re enforcing.
Token theft
Session abuse
Consent & legacy paths
MFA is necessary. It is not sufficient.
Executive summary
Most identity incidents occur after authentication
When leadership hears “MFA enabled,” they assume identity risk is largely mitigated. In modern environments, attackers increasingly target what MFA does not govern: existing sessions, refresh tokens, app permissions, service principals, and “allowed” access paths.
Reality
Attackers avoid new logins
The quietest path is to reuse what already works: active sessions, refresh tokens, OAuth grants, and trusted devices.
Outcome
Programs defend the wrong layer
Teams optimize for login challenges while leaving long-lived access and consent paths under-instrumented and under-governed.
Abuse paths
How attackers “walk around” MFA
These patterns vary by environment, but the strategic goal is consistent: avoid triggering MFA at all.
Token theft and refresh token persistence
If an attacker obtains tokens, they can act as the user without a fresh authentication event. Tokens often outlive password resets and many “containment” actions.
Session replay and device trust
Trusted device states and session cookies can preserve access. If your detection relies on “new login events,” session abuse can remain low-signal.
OAuth consent and delegated permissions
Malicious or over-privileged apps can retain access without interactive login. Consent is often reviewed less rigorously than user accounts, despite equivalent impact.
Legacy authentication paths
Protocols and older clients can bypass modern policy enforcement. If legacy auth remains enabled for compatibility, it becomes a permanent weak lane.
Defender gap
Why organizations miss MFA-adjacent compromise
MFA is visible and easy to report. Session and consent risk is harder to explain, and often ignored.
Monitoring focuses on failures, not successes
Teams alert on blocked sign-ins and suspicious failures, but do not baseline or monitor successful access patterns and token behavior.
App permissions are treated as “IT plumbing”
OAuth grants, service principals, and API tokens often live outside security review, despite their ability to access mail, files, and administrative functions.
Privileged role hygiene is weak
MFA does not help if privileged roles are over-assigned, used for daily work, or operate from unmanaged devices and networks.
Containment ignores token revocation
Password resets and account disablement may not invalidate all access paths quickly enough. Without token strategy, attackers persist through “remediation.”
Program direction
From “MFA enabled” to “identity resilient”
The objective is to govern sessions, consent, and privilege; not just logins.
Priority
Instrument token and session signals
Track anomalous token usage, device trust patterns, impossible travel signals, unusual app access, and role changes; especially successful ones.
Priority
Govern OAuth and app permissions
Require approval for high-privilege consents, enforce periodic review, and alert on new grants and permission escalation.
Priority
Eliminate legacy auth lanes
Identify and remove legacy authentication dependencies. Where removal is impossible, isolate and monitor those paths as high-risk exceptions.
Priority
Separate privileged identity from daily identity
Admin accounts should be isolated, time-bounded, and constrained by device and location. Privilege is the actual risk surface.