Google just shipped one of the most consequential web-security upgrades in years, and most users will never see it. Chrome's Device Bound Session Credentials (DBSC) are now generally available and rolling out to all users, cryptographically tying a browser session to the specific device it was created on. The point is to defeat cookie theft, the attack where criminals steal your session token and replay it to walk straight past your password and multi-factor authentication. With DBSC, a stolen cookie is dead weight on any other machine.

  • What shipped. DBSC is now generally available in Chrome and rolling out to all users, not just an experiment.
  • The mechanism. Session cookies are bound to a device-held private key, backed by the TPM where available, that never leaves the machine.
  • The target. Infostealer malware and session-hijacking that bypass passwords and MFA by stealing live session tokens.
  • The catch. It protects the session, not the device; malware on your machine while you are logged in is still a separate problem.
Stolen cookie, with and without DBSC Without device binding a stolen cookie replays successfully on the attacker device; with DBSC the session requires a device-held key the attacker does not have. Without DBSC stolen cookie attacker PCreplays it account taken With DBSC stolen cookie attacker PCno device key rejected genztech.blog
Fig 1 DBSC turns a stolen session cookie into a useless token off the original device, because the session now demands a private key the attacker cannot exfiltrate.

Why is cookie theft such a big deal?

Passwords and MFA protect the moment you log in, but once you are authenticated, the browser holds a session cookie that says "this user is already signed in." Steal that cookie and you inherit the logged-in session directly, no password and no MFA prompt required. This is exactly how modern infostealer malware works: it scrapes session tokens from browsers and sells them, and account-takeover crews replay them to hijack email, cloud, and enterprise accounts. It has become one of the most effective attack techniques precisely because it sidesteps the defenses everyone has spent a decade deploying. You can have a strong password and a hardware key and still lose the account to a stolen cookie.

RelatedEU Finds Instagram, Facebook Addictive Design Breaks DSA

How does DBSC close the gap?

DBSC binds the session to a private key generated on your device, stored in secure hardware such as the TPM where available, that never leaves the machine. Periodically, the server challenges the browser to prove it still holds that key before the session stays valid. A cookie copied to another computer cannot answer the challenge, because the key is not in the cookie, it is locked in your device's hardware. So even if malware exfiltrates the session token, the token is inert anywhere else. It converts a portable, replayable secret into one that is cryptographically chained to a single machine, which is the property session security has always lacked.

What does it not fix?

DBSC protects the session from being stolen and replayed elsewhere. It does not make your device itself safe. If malware is already running on your machine while you are actively logged in, it can still abuse that live session locally, and DBSC does not change that. It also depends on server-side adoption: sites and identity providers have to implement DBSC support for their logins to benefit, so the protection spreads only as fast as the ecosystem adopts it. And it is a Chrome capability first, meaning full cross-browser coverage will take time. It is a major structural improvement, not a magic shield, and it should sit alongside endpoint security rather than replace it.

What does it mean for the web?

For everyday users, the win is silent and automatic: as sites adopt DBSC, one of the nastiest account-takeover techniques quietly stops working against you. For enterprises, it is a meaningful reduction in the blast radius of infostealer infections, which have driven a wave of breaches that began with a single stolen token. For the broader platform, it signals where web security is heading: away from portable bearer secrets and toward hardware-bound, device-anchored credentials, the same philosophy behind passkeys. Cookies have been the soft underbelly of web authentication for thirty years. Binding them to hardware is one of the first serious attempts to fix that at the platform level.

RelatedChrome will warn on every HTTP site by default in 2026

What to watch · 2026
  • Server adoption. How quickly Google, Microsoft, and major identity providers turn DBSC on for their logins.
  • Infostealer response. Whether stolen-cookie marketplaces shrink as replay stops working.
  • Cross-browser support. If Firefox and Safari adopt a compatible device-binding model.
  • Passkey convergence. How DBSC and passkeys combine into a fully hardware-bound login flow.

Our take

This is the kind of security work that matters most and gets noticed least. Cookie theft quietly became one of the highest-leverage attacks on the internet because it walks around every defense users were told to trust, and DBSC attacks the root of it by making the session credential non-portable. It will not end account takeover on its own, and its value scales only as servers adopt it, but the direction is unambiguously correct: bearer tokens should be bound to hardware, not floating in files that malware can scoop up. If you run a service with logins, DBSC support should be on your roadmap now. The era of the freely replayable session cookie is finally, and rightly, starting to close.

Primary sources

Original analysis by GenZTech. Reporting via BleepingComputer.