MFA Isn't Enough Anymore: Why Session Hijacking Is Breaking Your 'Compliant' Security Stack

Your compliance report says MFA is enabled everywhere. Your cyber insurance renewal went through. Your auditor checked the box. None of that tells you whether an attacker sitting in the middle of a login flow can walk away with an employee's authenticated session and skip your MFA prompt entirely, because that is a different problem than the one MFA was built to solve.

No, MFA by itself is not enough anymore. Attackers have shifted from stealing passwords to stealing the session token your browser holds after MFA succeeds, which lets them impersonate an already-authenticated employee without triggering another prompt. That gap is why a fully MFA-compliant stack can still get breached in minutes.

The business cost is not abstract. A stolen session lets an attacker read email, approve wire transfers, and pull sensitive files under an identity your systems already trust, often for hours before anyone notices, because nothing in a standard login log looks unusual. The forensic review, the client notification work, and the insurance claim process that follow a session hijacking event tend to run longer and cost more than a typical phishing incident, because investigators have to reconstruct what happened inside a session that looked completely legitimate from start to finish.

How does an attacker get around MFA if they don't have your password?

They don't need it. In an adversary-in-the-middle attack, a proxy site sits between your employee and the real login page, capturing the password and the MFA approval as the employee enters them, then stealing the session token issued right after authentication succeeds. Microsoft's security team has tracked large-scale campaigns using exactly this technique against more than 10,000 organizations, and once that token is stolen, the attacker opens it on their own device and walks in as an already-logged-in employee.

This matters to your compliance posture because most frameworks ask whether MFA is enabled, not whether the token issued after MFA is protected from theft. A yes on the audit checklist and a wide-open session hijacking gap can coexist in the same environment, and we see this pattern constantly in client environments that passed a SOC 2 review or a cyber insurance questionnaire the same quarter an AiTM kit got them.

Why does my MFA-compliant stack still show up as exposed on a security assessment?

Because most MFA methods your team relies on, SMS codes, push approvals, authenticator app codes, were never built to resist a proxy sitting between the user and the real login page. NIST's digital identity guidelines describe this category of attack as verifier impersonation and specifically call out authentication methods that cryptographically bind the session to the device as the way to resist it, which push notifications and one-time codes do not do. Run Securafy's cybersecurity assessment against your own environment and you will usually find MFA turned on everywhere and session binding turned on nowhere, which is exactly the gap attackers are exploiting right now.

Cyber insurers and auditors are catching up to this. CISA has spent several years telling federal agencies and private organizations that phishing-resistant MFA, meaning FIDO2 security keys or passkeys rather than SMS or push codes, is the standard worth moving toward, and that guidance is increasingly showing up in insurance renewal questionnaires and vendor risk assessments. If your MSP or internal team cannot answer whether your authentication is phishing-resistant, that is a conversation to have before your next renewal, not after a claim gets denied.

What changed is not the technique, it is the availability of it. AiTM phishing kits that automate this proxy-and-steal process have moved from custom attacker tooling to commodity kits traded on criminal forums, which is part of why Microsoft's own investigators found the technique deployed against tens of thousands of organizations rather than a handful of high-value targets. A method that used to require a skilled operator now runs closer to a subscription service, and that shift is what turned session hijacking from a nation-state technique into something any opportunistic criminal group can point at your business.

What happens if a session hijacking attack goes undetected for a few hours?

The attacker acts as your employee, so most of what they do gets logged under a legitimate identity, which is exactly what makes it hard to catch quickly. CISA has described real incidents where a single AiTM attack handed an attacker a working username, password, and MFA-approved session against a well-funded company, showing how fast a live session converts into meaningful access once the token is stolen. Depending on which account gets hijacked, the fallout ranges from a redirected wire transfer to a compromised mailbox used to launch the next phishing wave against your own customers, which turns one incident into a reputational problem as well as a financial one.

What actually stops session hijacking if MFA doesn't?

Two things close the gap: phishing-resistant authentication and session-level controls that limit what a stolen token can do even if one gets taken. Passkeys and FIDO2 security keys are cryptographically bound to the specific site and device, so a proxy site cannot relay the approval the way it can with a push notification, which is why the FIDO Alliance's own research puts the reduction in phishing and credential theft exposure from passkeys in the high nineties percent range.

On the session side, the token protection feature in Microsoft Entra ID binds session tokens to the device that requested them, so a token copied off one machine and replayed from another gets rejected even if the token itself is still technically valid. Shorter session and refresh token lifetimes, conditional access policies that flag impossible travel or a new device, and continuous access evaluation all shrink the window a stolen token stays useful, which matters because most AiTM kits are built to move within minutes of getting a live session.

In the environments we have reviewed, the exposure usually shows up the same few ways:

• MFA is enforced tenant-wide, but every method in use is phishable, SMS, push, or OTP, with no phishing-resistant option even offered to users.
• Session and refresh token lifetimes are set to defaults measured in days, not hours, so a stolen token stays valid long after the theft happened.
• Conditional access policies check device compliance and location but never evaluate token binding or flag session reuse from a new device.
• Security awareness training covers phishing emails but never mentions that a convincing login page can steal a live session even when the user does everything right.

Do you need to replace your entire authentication system to fix this?

No. Most organizations do not need a rip and replace, they need a phased rollout of phishing-resistant methods for high-risk accounts first, admins, finance, and executives, tightened token and session lifetimes across the board, and conditional access rules tuned to catch session reuse rather than just device posture. That is a project most internal IT teams can run alongside a managed partner like Securafy's Essential Care service rather than a multi-quarter platform migration.

A phased rollout like this typically takes weeks for the highest-risk accounts, not months, because most identity providers, Microsoft Entra ID and Google Workspace included, already support phishing-resistant authentication and token protection as configuration changes rather than new purchases. The reason most organizations have not turned these on yet is rarely cost, it is that nobody flagged it as a priority until an assessment or an insurer forced the question.

If you are evaluating a new MSP or renewing an existing contract, the question to ask is not whether they support MFA, it is how they handle phishing-resistant authentication and token lifetimes for your highest-risk accounts. Our cybersecurity buyer's guide walks through the exact questions to put in front of any vendor bidding on your security work, including this one, because an MFA checkbox on a proposal has stopped meaning much on its own.

Attackers are not picking this technique because it is exotic. It works, it scales, and it slips past a security stack that looks compliant on paper. Verizon's Data Breach Investigations Report has tracked stolen credentials as one of the most common ways attackers get into an environment for years, and session hijacking is simply the next version of that same problem, one step past the password.

What should you actually do about this before your next audit or renewal?

Start with the accounts that matter most, not a full rollout. The fix order that works in practice:

1. Turn on phishing-resistant MFA, FIDO2 keys or passkeys, for admins, finance, and anyone with access to email or financial systems first.
2. Cut default session and refresh token lifetimes and require reauthentication for high-risk actions like password resets or payment changes.
3. Turn on token binding or token protection features already built into your identity provider, most organizations have this available and unconfigured.
4. Add session anomaly detection, new device, new location, impossible travel, to your conditional access policies instead of relying on login-time checks alone.

None of this requires waiting for a breach to justify the work. The gap between an MFA checkbox and real resistance to session hijacking is measurable today, and closing it before an insurer, an auditor, or an attacker finds it first is the entire point of doing this now instead of after your next incident report.

This is not a one-time project either. Attackers rotate techniques as defenses improve, so the accounts and policies you lock down this quarter need a scheduled recheck rather than a permanent checkbox, which is the difference between a security program and a compliance exercise that happens to look good on an audit.

Where To Go From Here

Closing the gap between MFA and real session security starts with knowing where your own stack stands, then pairing phishing-resistant authentication with a team that can act fast when a session does get compromised.

If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. Securafy AI University gives your people role-based AI training with security built into the material, not bolted on afterward.

If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.