MFA didn't fail. Your session cookie did.

Most of the "we have MFA, we're covered" conversations I get pulled into end the same way: someone shows me a login that shouldn't have worked, from a country nobody on the team has visited, with no MFA prompt in the logs. The attacker didn't beat the second factor. They walked around it.

The thing they stole wasn't a password. It was a cookie.

The part nobody puts on the security slide

When you log in and clear MFA, the server hands your browser a session cookie — a small token that says "this person already proved who they are, don't ask again." Every request after that trusts the token, not you. That's what makes the web usable. It's also the soft underbelly.

If an attacker copies that cookie onto their own machine, the server sees a fully authenticated session. No password. No MFA. This is called a pass-the-cookie attack, and it has quietly become one of the most reliable ways into a company's cloud.

The delivery mechanism is usually infostealer malware — families like LummaC2, RedLine, Raccoon, and Vidar. Someone downloads a cracked app, a fake "meeting" installer, or a poisoned browser extension, and within minutes the malware has scraped every cookie in the browser's local storage and shipped it to a server for sale. In 2025 the volume of stolen browser cookies traded on criminal markets was measured in the tens of billions. This is not a boutique attack.

A concrete example

In April, BleepingComputer covered a proof-of-concept from Varonis called Cookie-Bite. It's worth understanding because it's boringly practical, which is exactly why it works.

The technique targets two Microsoft Entra ID cookies:

• ESTSAUTH — a session token that says you're authenticated and have completed MFA. Valid for the browser session, up to about 24 hours.
• ESTSAUTHPERSISTENT — the "Stay signed in" version. Valid for up to 90 days.

Grab the persistent one and you can have three months of access to Microsoft 365, Outlook, and Teams — silent, MFA already satisfied. The attacker imports the stolen cookie with an ordinary tool like the legitimate Cookie-Editor extension, refreshes the page, and Entra treats them as the real user.

MFA protects the moment you log in. It does nothing about what happens for the next ninety days. The session cookie is what carries your identity after that — and it was never designed to defend itself.

Why this is finally changing

For years the honest answer to "how do we stop pass-the-cookie" was "you mostly can't — you shorten the blast radius." That changed this spring.

In April 2026, Google shipped Device Bound Session Credentials (DBSC) to general availability for Windows users on Chrome 146, following the April 2024 announcement. The idea is simple and correct: bind the session to the device's hardware.

When DBSC is on, the browser generates a public/private key pair and stores the private key in a hardware security module — a TPM on Windows, the Secure Enclave on macOS (coming in a later Chrome release). The key cannot be exported. To keep the session alive, Chrome has to periodically prove it still holds that private key. A stolen cookie moved to another machine can't produce the proof, so it expires into uselessness fast. Google reports a significant drop in session theft for DBSC-protected sessions.

This is a real fix, not a press release. But read the fine print: it's Windows-with-a-TPM first, it only helps where both the site and the browser support it, and malware already resident on the machine with the right privileges is a different threat model. DBSC raises the cost of cookie theft dramatically. It does not retire the problem.

What I'd actually do this quarter

You don't need a project plan. You need a short list, done properly.

1. Turn on DBSC where you can. If you run Google Workspace, the Admin console exposes DBSC configuration now — enable it. If you build the web app, add the DBSC registration and refresh endpoints; your front end doesn't have to change.
2. Shorten persistent sessions. A 90-day "stay signed in" window is a 90-day skeleton key. Tighten session lifetimes for anything that touches money, customer data, or admin consoles.
3. Bind sessions to context, then enforce it. Conditional Access that checks device compliance and location turns a raw stolen cookie into a much weaker artifact. Alert on impossible travel and new-device sign-ins that skipped an MFA prompt.
4. Go phishing-resistant on MFA. FIDO2 security keys and passkeys don't stop post-login cookie theft, but they kill the adversary-in-the-middle phishing that steals the cookie in the first place. Push-approval MFA is the weakest common option; treat it as a stopgap.
5. Assume infostealers, defend the endpoint. EDR that flags credential-dumping from browser storage, an allowlist for browser extensions, and browser isolation for high-risk work (finance, cloud admin) attack the root cause instead of the symptom.
6. Make revocation a muscle. When a device is suspected compromised, you should be able to revoke every session for that user in one action and force reauthentication. Practice it before you need it.

The uncomfortable summary

MFA is necessary and you should keep it. But "we have MFA" has become the security equivalent of "we have a lock on the front door" — true, reassuring, and irrelevant to the person climbing through the window with a copy of your house key.

The attackers moved on from your password years ago. The defense that matters now is protecting the token that proves you already logged in. DBSC is the first mainstream tool that does that at the browser level. Turn it on, shorten your sessions, and stop treating the login screen as the finish line.