Chrome 146 Deploys Device-Bound Sessions to Defeat Cookie Theft

Google has activated Device Bound Session Credentials (DBSC) for all Windows users of Chrome 146, marking one of the most consequential shifts in browser authentication in years. The feature, which cryptographically binds session cookies to a specific device’s hardware, renders stolen authentication tokens useless the moment they are carried off to another machine.

The rollout, confirmed on April 9–10, 2026, arrives months after an extended open beta. DBSC is now live by default for Chrome 146 users on Windows 10 (version 1903 and later) and Windows 11. A macOS release is expected in a future Chrome update, though Google has not announced a specific timeline.

The Problem: Session Cookies as Bearer Tokens

For decades, web authentication has depended on session cookies — small files written to the browser after a successful login. These cookies act as bearer tokens: whoever holds them can authenticate as the user, no password required. The simplicity that makes them convenient also makes them catastrophically easy to steal.

A class of malware known as infostealers — including prolific families like LummaC2 — has evolved specifically to harvest these cookies from browser storage. Once exfiltrated, a stolen cookie can be replayed on any machine anywhere in the world, granting attackers full account access and bypassing multi-factor authentication entirely.

How DBSC Works

DBSC addresses this vulnerability by moving the root of session trust into hardware. When a user authenticates on a DBSC-enabled site, Chrome generates a unique cryptographic key pair directly inside the device’s Trusted Platform Module (TPM) on Windows, or Secure Enclave on macOS. The private key is generated within the chip and is architecturally incapable of being exported — malware cannot read it, and no software operation can extract it.

The server stores only the corresponding public key. From that point forward, every time a short-lived session cookie expires — which happens frequently by design — Chrome must prove to the server that it still holds the private key before a new cookie is issued. Attackers who steal a cookie gain nothing: without the private key locked in the original hardware, they cannot refresh the session, and it quickly becomes invalid.

Open Standard, Collaborative Development

DBSC was first announced by Google in April 2024 and was co-developed with Microsoft with the goal of establishing it as an open web standard. The specification is published through the World Wide Web Consortium (W3C) Web Application Security Working Group, and identity providers including Okta participated in origin trials over the past year.

Google has stated that its telemetry from early deployments shows a measurable reduction in successful session hijacking attempts on services that implemented the protocol — an early signal of real-world effectiveness.

Privacy by Design

A natural concern with device-bound credentials is fingerprinting: if a server can confirm “this is the same device,” it could potentially track users across sessions or sites. Google’s architects anticipated this. Each session is backed by a unique, independent key — there is no persistent device identifier shared with servers. The only information exchanged is the per-session public key used to prove ownership.

“This minimal information exchange ensures DBSC helps secure sessions without enabling cross-site tracking or acting as a device fingerprinting mechanism,” Google explained in its announcement. The standard was explicitly designed so that websites cannot use DBSC to correlate user activity across different sessions on the same device.

What Website Developers Need to Do

DBSC is additive — sites that take no action continue to work exactly as before, and users on those sites receive no DBSC protection. To enable the feature, backend developers must implement two new endpoints: a registration endpoint that associates a public key with a session, and a refresh endpoint that validates key possession before issuing a new short-lived cookie. Frontend code requires no changes.

Devices Without a TPM

Not every Windows machine has a TPM 2.0 chip. Google estimates that DBSC-capable hardware covers approximately 85 percent of active Windows Chrome installations. For the remainder, DBSC gracefully degrades to standard session cookie behavior — authentication still works, the hardware binding layer simply is not available. No user action is required in either case.

Platform Rollout Status

What Comes Next

Google has outlined several planned enhancements to DBSC beyond the initial Windows release. These include support for federated identity systems — ensuring device-bound security persists across Single Sign-On workflows — and deeper integration with pre-existing trusted credentials such as hardware security keys and mutual TLS certificates. The company is also exploring software-based fallback implementations for devices that lack dedicated secure hardware.

The announcement represents a substantial milestone in the long effort to move web authentication beyond the inherent fragility of bearer tokens. Whether DBSC achieves the broad website adoption necessary to make cookie-theft attacks genuinely obsolete will depend on how quickly the web development community integrates the required server-side endpoints — and on whether other browser vendors follow Chrome’s lead.

Sources: Google Chrome Security Team announcement (April 10, 2026); The Hacker News; BleepingComputer; gHacks Tech News; Cyber Insider; Google Chrome Developer Documentation (developer.chrome.com).