MFA Isn't Enough Anymore: Why Session Hijacking Is the New #1 Threat

Sep 19, 2026

0 Comments

MFA Isn't Enough Anymore: Why Session Hijacking Is the New #1 Threat

Multi-factor authentication is still essential. Every small business should use it.

But MFA protects the login event. It does not always protect the active session that comes after the login.

That gap is driving a serious rise in session hijacking. An attacker may not need your password. They may not need to defeat your MFA prompt. They only need to steal the browser cookie or token that proves you already authenticated.

Once stolen, that session can provide access to email, cloud applications, customer data, financial systems, and administrative tools.

For small and mid-size businesses, this makes session security a core cybersecurity priority: not an advanced concern reserved for large enterprises.

WHY MFA DOESN’T STOP SESSION HIJACKING

When you sign in to a web application, the service verifies your password and MFA challenge. After that, it creates an authenticated session.

The application usually remembers you through a session cookie or token stored in your browser. That token is sent with future requests so you do not have to complete MFA on every page.

In practical terms:

  • MFA proves that you completed the authentication challenge.
  • The session token proves that you are already authenticated.
  • The application often trusts that token until it expires or is revoked.
  • Anyone who obtains the token may be able to reuse the session.

OWASP explains that an authenticated session token is temporarily equivalent to the strongest authentication method used by the application. If an attacker captures it, they can impersonate the user inside the application.

This is not always a failure of MFA. The attacker may never defeat the MFA technology. Instead, they steal the result of a successful login.

That is why MFA must be part of a broader identity and access strategy.

HOW SESSION COOKIES GET STOLEN

Illustration showing a browser session cookie intercepted through phishing and endpoint malware

Session hijacking usually begins with a compromised browser, endpoint, or login process. The most common paths include the following.

ADVERSARY-IN-THE-MIDDLE PHISHING

In an adversary-in-the-middle phishing attack, the employee receives a convincing message and clicks a link to a fake login page.

The fake page may sit between the employee and the real application. It relays the login in real time.

The employee enters a username and password. They complete MFA correctly. The attacker captures the authenticated session cookie as the legitimate service creates it.

The attacker then replays the cookie from another device.

This is why modern phishing messages can be dangerous even when your team uses MFA. CISA recommends looking for urgent language, suspicious links, unusual sender addresses, and requests for sensitive information. Employees should report suspicious messages rather than clicking through them. Read CISA’s phishing guidance for practical awareness steps.

INFOSTEALER MALWARE

Infostealer malware searches browsers and devices for valuable information. Depending on the malware, it may target:

  • Saved passwords
  • Browser cookies
  • Access tokens
  • Refresh tokens
  • Cryptocurrency wallets
  • Autofill data
  • Browser history

A user may install the malware through a fake software update, malicious attachment, pirated application, or convincing business document.

The attacker may then use stolen cookies to access Microsoft 365, Google Workspace, a CRM, a financial application, or another SaaS platform without triggering a new MFA prompt.

MALICIOUS OR OVERPERMISSIONED BROWSER EXTENSIONS

Browser extensions can read or change data on websites. Some require broad permissions to function.

A malicious extension: or a legitimate extension that has been compromised: may be able to access sensitive browser data. Even when an extension is not intentionally malicious, unnecessary permissions increase your exposure.

Small businesses should maintain an approved extension list and review extensions that can “read and change all your data on websites.”

WEAK APPLICATION SESSION CONTROLS

Applications create additional risk when they use:

  • Long-lived sessions
  • Weak logout behavior
  • Poorly configured cookies
  • No device or location checks
  • No reauthentication for sensitive actions
  • Inadequate session monitoring
  • Tokens stored in insecure browser storage

For applications you own or manage, cookies should use appropriate Secure, HttpOnly, and SameSite attributes. Authentication tokens should not be stored in browser localStorage or sessionStorage, where scripts may access them.

WHAT SMALL BUSINESSES SHOULD DO NOW

You do not need to build a security operations center from scratch. You do need layered controls that make stolen sessions harder to use, easier to detect, and faster to revoke.

1. SET PRACTICAL SESSION POLICIES

Work with your IT provider or application administrators to review session settings.

For critical applications, consider:

  • Idle timeouts of approximately 15–30 minutes for sensitive workflows
  • Absolute session lifetimes of approximately 4–8 hours for high-value systems
  • Shorter lifetimes for administrative consoles
  • Reauthentication after password changes or account recovery
  • Reauthentication before payroll, banking, data exports, or permission changes
  • Automatic session revocation after suspected compromise
  • Sign-out from all devices when an account is investigated

These are starting ranges, not universal rules. A finance application may need tighter policies than a low-risk scheduling tool. The goal is to balance security with productivity.

OWASP recommends both idle and absolute timeouts. An idle timeout limits inactive sessions. An absolute timeout limits how long any session can remain active, even if an attacker keeps using it.

2. REQUIRE DEVICE TRUST

MFA confirms something about the user. Device trust adds context about the device.

You should know whether the request comes from:

  • A company-managed laptop
  • A current operating system
  • An encrypted device
  • An endpoint with active security tools
  • An approved browser
  • A device that meets your baseline configuration

Use conditional access policies where your identity provider supports them. Require additional verification: or block access: when a user connects from an unknown device, unusual geography, risky network, or unapproved operating system.

Device trust is not perfect. It should not be treated as a single security decision. It is one more signal that helps you make better access decisions.

3. COMBINE MFA WITH MONITORING

MFA without monitoring leaves you with limited visibility after the login.

Monitor for:

  • New devices or unusual locations
  • Concurrent sessions from distant regions
  • Impossible travel patterns
  • New inbox forwarding rules
  • Unusual file downloads
  • Large data exports
  • Unexpected administrative changes
  • Long-running sessions
  • New OAuth applications
  • Browser or endpoint activity associated with cookie theft

Your identity platform may already include some of these capabilities. If not, a managed monitoring service can connect identity, endpoint, cloud, and network signals.

Our security services focus on vulnerability management, incident response planning, cloud and infrastructure security, and ongoing monitoring. We help you prioritize the controls that match your risk and budget.

4. USE ZERO-TRUST NETWORK ACCESS

Traditional network access often works like this: connect to the corporate network, then trust the user and device.

Zero-trust network access takes a different approach. It evaluates each request based on identity, device posture, application, location, and risk. Access is granted to the specific application or resource: not automatically to the entire network.

For a small business, ZTNA can reduce the damage caused by a stolen session or compromised laptop.

A practical ZTNA rollout may include:

  • Starting with remote access to critical applications
  • Removing broad network-level access where it is unnecessary
  • Requiring managed devices for sensitive systems
  • Applying separate policies to administrators and regular users
  • Reviewing access logs regularly
  • Expanding coverage after the first group is stable

ZTNA implementation depends on your current identity provider, cloud applications, network design, and endpoint management. We can assess those dependencies before recommending a platform.

Layered security illustration showing MFA, device trust, monitoring, and zero-trust access protecting a cloud identity hub

WHAT TO DO IF YOU SUSPECT A HIJACKED SESSION

Treat unusual account activity as a possible session compromise: not only as a password problem.

Follow this order:

  1. Revoke all active sessions and refresh tokens. Use the identity provider or application administrator controls.
  2. Reset the account password. Do this after session revocation.
  3. Review MFA methods. Remove unauthorized devices, recovery methods, or security keys.
  4. Inspect email rules and OAuth access. Look for forwarding rules, new applications, or unexpected permissions.
  5. Check administrative activity. Review changes to users, policies, billing, and security settings.
  6. Isolate the endpoint. Run an endpoint investigation and remove suspicious extensions or malware.
  7. Preserve evidence. Keep relevant logs before making broad changes.
  8. Notify affected parties. Determine whether customer, financial, or regulated data was accessed.

Incident response illustration showing a monitored abnormal login and a revoked session

Do not assume that changing the password ends the incident. A stolen session may remain active unless you explicitly revoke it.

HOW FIVE 9 CAN HELP

Session hijacking sits at the intersection of identity, endpoint security, cloud administration, network management, and employee awareness.

That makes it difficult to solve with one tool.

We can help you:

  • Review identity and session policies
  • Assess Microsoft 365, Google Workspace, and SaaS access controls
  • Evaluate device trust and conditional access
  • Tighten browser and endpoint security
  • Improve network visibility
  • Plan a practical ZTNA rollout
  • Build session-compromise response procedures
  • Monitor for unusual identity and application behavior
  • Document controls and transfer knowledge to your internal team

A focused security assessment typically takes 1–2 weeks, consistent with the assessment timeline described in our security practice. Broader implementation timelines vary. A limited policy review may take days, while a multi-application identity and endpoint project may take several weeks.

We do not recommend a fixed package before understanding your environment. We will scope the work, explain priorities, provide a written estimate, and tell you honestly if a requested capability falls outside the right solution.

Our consulting services are designed to solve the immediate problem while helping your team understand the solution. You should become more capable: not more dependent: after the engagement.

THE BOTTOM LINE

MFA remains one of the most important controls your business can deploy.

It is not the entire identity defense.

If an attacker steals an authenticated session, they may bypass the login process without defeating MFA. The right response is layered protection:

  • Strong MFA
  • Shorter and better-managed sessions
  • Trusted devices
  • Risk-based access policies
  • Endpoint and browser protection
  • Continuous monitoring
  • Zero-trust application access
  • A practiced incident response plan

Start with an honest review of your current environment. We can help you identify the highest-risk gaps, prioritize practical improvements, and support your team as requirements change.

Contact Five 9 for a no-pressure conversation about your security posture and next steps.

Five 9 Assistant

Automated · not a live person