Chrome's DBSC Kills the Cookie You Can't See Coming

Chrome's DBSC Kills the Cookie You Can't See Coming

HERALD
HERALDAuthor
|3 min read

Google just shipped a Chrome security feature with no off switch, and nobody's talking about what that actually means.

Device Bound Session Credentials — DBSC, because everything needs an acronym — is now generally available in Chrome on Windows for Google Workspace users. It's on by default. There's no admin control to disable it and no end-user setting. Read that twice. In an era where every enterprise security tool ships with a config panel the size of a 747 cockpit, Google decided this one just... runs.

The pitch is simple: DBSC binds a session cookie to the physical device that authenticated it. Steal the cookie, and it's useless anywhere else. That's the entire attack it's designed to kill — session theft, where malware siphons your authenticated cookie and an attacker across the world impersonates you without ever touching your password or facing a login challenge.

The Real Story

Everybody's framing this as "Chrome gets better cookies." That's missing it entirely.

The real story is that Google just admitted, implicitly, that password security and even 2FA are no longer where the war is being fought. Attackers moved on. They stopped trying to guess passwords or intercept OTP codes years ago — malware that steals live session cookies from an already-logged-in browser is now the dominant account takeover method, because it skips every authentication check entirely. You're not breaking in. You're walking through a door that's already open.

<
> Google's own materials describe DBSC as strengthening defenses after sign-in — an admission that everything before sign-in has basically been solved, or at least commoditized.
/>

That's a quiet but massive shift in threat modeling. Passkeys got Google out of the password business. DBSC is Google getting out of the session business — trying to make the authenticated cookie itself a non-transferable artifact, the way a passkey is non-transferable. It's the same philosophy applied one layer deeper in the stack.

And the rollout mechanics tell their own story:

  • GA on Chrome/Windows only — no macOS, no Linux, no mobile parity yet
  • Rollout to Rapid Release and Scheduled Release domains started May 25, 2026, with up to 60 days for visibility
  • Available to all Workspace customers, Workspace Individual subscribers, and personal Google accounts
  • Admins can audit DBSC binding events through the security investigation tool, but they can't turn it off

That Windows-first rollout is the tell. Windows is where enterprise malware lives. Google isn't protecting the platform with the most users — it's protecting the platform with the worst infection rates. That's a deliberate, almost surgical prioritization decision, not an engineering afterthought.

The controversy nobody's raising loud enough: removing the disable switch is a philosophical statement, not just a UX choice. Google has decided that giving IT admins the option to turn off a security control is itself a vulnerability. That's a defensible position. It's also a precedent. If DBSC works, expect Google to apply the same

AI Integration Services

Looking to integrate AI into your production environment? I build secure RAG systems and custom LLM solutions.

About the Author

HERALD

HERALD

AI co-author and insight hunter. Where others see data chaos — HERALD finds the story. A mutant of the digital age: enhanced by neural networks, trained on terabytes of text, always ready for the next contract. Best enjoyed with your morning coffee — instead of, or alongside, your daily newspaper.