Cookie theft follows a well-established pattern. Infostealer malware infiltrates a device, extracts authentication cookies, and exfiltrates them to an attacker-controlled server. Because cookies often have extended lifetimes, attackers can access accounts without passwords, then bundle and sell the stolen credentials. Once malware gains access to a machine, it can read the local files and memory where browsers store authentication cookies.
What DBSC does
Google’s Device Bound Session Credentials (DBSC) is now entering public availability for Windows users in Chrome 146, with macOS support coming in a subsequent release.
The protocol cryptographically binds authentication sessions to a specific device using hardware-backed security modules: the Trusted Platform Module (TPM) on Windows and the Secure Enclave on macOS. These modules generate a unique public/private key pair that cannot be exported from the machine.
An overview of the DBSC protocol showing the interaction between the browser and server (Source: Google)
When a session is active, Chrome must prove possession of the corresponding private key to the server before the server issues new session cookies. Those cookies are short-lived. An attacker who exfiltrates them will find they expire quickly and cannot be renewed without the private key, which cannot leave the device.
“This design allows large and small websites to upgrade to secure, hardware-bound sessions by adding dedicated registration and refresh endpoints to their backends, while maintaining complete compatibility with their existing front-end. The browser handles the complex cryptography and cookie rotation in the background, allowing the web app to continue using standard cookies for access just as it always has,” Google researchers explained.
Google has been running an earlier version of the protocol across its own properties over the past year. For sessions protected by DBSC, Google observed a measurable reduction in session theft since deployment began.
Privacy properties
Each DBSC session is backed by a distinct cryptographic key. That architecture prevents websites from using the credentials to correlate a user’s activity across different sessions or sites on the same device. The protocol does not transmit device identifiers or attestation data to the server; it shares only the per-session public key needed to verify proof of possession. That constraint keeps DBSC from functioning as a device fingerprinting mechanism or enabling cross-site tracking.
Standardization and industry involvement
DBSC was developed through the W3C process and adopted by the Web Application Security Working Group. Google worked with Microsoft on the standard’s design. Google also ran two Origin Trials over the past year to gather feedback from the broader web community. Okta was among the web platforms that participated in those trials and contributed feedback on whether the protocol meets their operational requirements.
What comes next
Google’s ongoing development work on DBSC covers three areas. The first is federated identity: in enterprise environments where Single Sign-On is common, the team is building cross-origin bindings so that a relying party session stays continuously bound to the same device key used during the initial identity provider login, preserving the chain of trust across the federated process.
The second area is advanced registration. Some environments need stronger guarantees at the moment a session is first created. Google is developing mechanisms to bind DBSC sessions to pre-existing trusted key material, such as mTLS certificates or hardware security keys, at registration time.
The third area is broader device support. Google is exploring software-based keys to extend protections to devices that lack dedicated secure hardware.
Download: Picus Security’s Red Report 2026
