You did everything right. Two-factor is enforced on every account. Nobody reused a password from a 2019 breach. And the attacker still got in, read the CFO's mail for a week, and rerouted a wire.
When this happens, the post-mortem almost never finds a cracked password or a defeated MFA prompt. It finds a stolen browser session. The login already happened, on a legitimate device, by the real user. The attacker just walked in carrying the proof.
Why 2FA quietly stopped being enough
Here is the part most admins were never told plainly. Two-factor authentication protects the moment you sign in. Once you're in, your browser holds a session cookie. That cookie is the "yes, this person is signed in" badge, and your browser shows it on every request so you don't have to type your password and tap your phone forty times a day.
Malware called an infostealer goes after that badge. It runs on an infected laptop, copies the live session cookies out of the browser, and ships them off. The attacker loads those cookies into their own browser and lands inside the account already authenticated. No password prompt. No MFA challenge. There's nothing to challenge, because as far as the system is concerned the session was already approved.
This is not a fringe technique. Constella's identity research found infostealers processed 51.7 million packages in 2025, a 72% jump over the prior year, and a big reason those packages are so valuable is that they carry live session cookies that bypass MFA outright. SpyCloud, working from a different data set, recaptured 8.6 billion stolen cookies and session artifacts from malware infections, and counted 1.17 million malware logs that held both enterprise credentials and active session cookies. The families doing most of this in early 2026 are LummaC2, ACRStealer, StealC, and Vidar. One infected machine in your org can become an authenticated session in someone else's hands.
What Google turned on, and when
On May 28, 2026, Google announced that Device Bound Session Credentials (DBSC) in the Chrome browser on Windows is now generally available and enabled by default for Google Workspace users. The rollout started gradually on May 25 and can take up to 60 days to fully appear across Rapid and Scheduled Release.
The idea behind DBSC is simple once you strip the acronym away. When a session is created, Chrome generates a private cryptographic key and stores it inside the device's TPM, a hardware-backed security chip built into the machine. The session cookie gets tied to that key. From then on, every time the session refreshes, Chrome has to prove it still holds the matching device key. A cookie copied off that laptop is missing the key it was bound to, so on the attacker's machine it simply fails validation. The stolen badge no longer opens the door.
If the system sees that a session doesn't match the device it was bound to, the user is prompted to sign in again. The honest user shrugs and re-authenticates. The attacker is stuck.
Two things matter for your blood pressure here. This is on by default, for all Workspace customers, Workspace Individual subscribers, and personal Google accounts. There is no admin control to disable it and no end-user setting to flip. You don't have to deploy anything to get the baseline protection.
The fine print: where DBSC does not reach
This is one strong control, not a force field. Knowing its edges is the whole job, because attackers move to whatever you left uncovered.
- Chrome and Windows only. It needs Chrome 146 or later on Windows, and a TPM to hold the keys. TPM is standard on most Windows 11 hardware, but older or unmanaged machines may not qualify.
- macOS, mobile, and other browsers are still exposed. A session stolen from Safari, from a phone, or from Firefox or Edge does not get this device binding. Constella's analysis makes the same point: the Chrome-on-Windows scope leaves macOS, mobile, other browsers, and non-browser token theft on the table.
- Non-browser tokens aren't covered. OAuth tokens and app credentials living outside the browser are a separate problem DBSC doesn't touch.
Read that list as a map of where you still need other defenses, not as a reason to wave DBSC off. For the place most credential theft actually happens, the corporate Windows laptop running Chrome, the highest-value cookie just got a lot less useful to steal.
What an admin should actually do
Nothing is required to switch DBSC on. But "nothing required" and "nothing worth doing" are different things. A few moves turn a passive default into something you can see and steer.
Watch the binding events. In the security investigation tool, DBSC writes audit logs you can review. User log events show DBSC key binding and DBSC key validation as Succeeded or Failed. Access Evaluation log events surface denied requests with codes like DBSC_BOUND_COOKIE_MISSING, DBSC_BOUND_COOKIE_CORRUPTED, and DBSC_BOUND_COOKIE_EXPIRED. A spike in failed validations is a signal worth chasing, not noise to mute.
Consider enforcing bound sessions. DBSC works alongside Context-Aware Access. If you want to go further than the default, you can use Context-Aware Access to require a bound session and block non-bound ones from reaching specific apps. Sensible for your most sensitive systems; test it before you point it at everyone, since it can lock out anyone on an unsupported browser, OS, or device.
Standardize the fleet so devices actually qualify. DBSC only helps on machines that meet the bar. Managed Chrome plus Windows 11 with a working TPM and current browser versions is what makes the protection real instead of theoretical. If your fleet is a patchwork of personal laptops and stale Chrome builds, that's the gap to close first.
Keep layering. Phishing-resistant passkeys to harden the login itself, Context-Aware Access to gate by device posture, and basic endpoint hygiene so infostealers can't run in the first place. DBSC takes one weapon out of the attacker's hands. It doesn't take all of them.
The honest takeaway
Session theft was the quiet gap behind a lot of "but we had MFA" incidents, and Google just closed a big slice of it for free on the platform most of your users live on. That's genuinely good news. It is also the kind of change that's easy to misread as "we're done." You're not done. You're better protected on Chrome and Windows, and you now have logs to prove it and a clear list of what still needs covering.
If you'd rather not piece this together alone, this is the sort of audit we do every week: confirm DBSC is actually landing on your fleet, wire up the monitoring so failed bindings reach a human, decide whether Context-Aware Access enforcement fits your risk, and find the macOS and mobile gaps before someone else does. We're an independent Workspace and Cloud team, not a reseller pushing a license. If your last security review predates all of this, it's a fair time for a fresh look.