Chrome DBSC: cookies linked to hardware to stop account kidnapping

Google has started the overall deployment of Chrome Device Bound Session Credentials (DBSC), a security function that cryptographically ties browser sessions to the hardware of the team to prevent stolen cookies from allowing account hijackings.

DBSC is not a single patch: it links session cookies to non-exportable hardware keys, generated by safe elements such as the Trusted Platform Module (TPM) in Windows or the Secure Enclave in macOS. This association means that, even if an attacker is able to extract a cookie, it cannot be reused from another device because it does not have the private key stored in the chip of the original equipment.

Google explains that the function has been in beta since April and is now activated for all Google Workspace customers, individual subscribers and personal accounts, enabled by default and without option for administrators to disable, which highlights Google's intention to raise the level of protection against this attack vector. You can read the official ad here: Prevent account takeovers with DBSC - Workspace Updates.

The approach of DBSC changes the tactic of many defenses: instead of relying only on post-commitment detection, it seeks make the stolen goods useless. This directly attacks abuses that have been observed in practice, such as the exploitation of undocumented OAuth endpoints or the ability of info-stealers to restore expired cookies, techniques that have been used by malware families and specialized operations.

Although it is a significant improvement, DBSC is not a silver bullet. It protects against the remote reuse of exfiltered cookies, but does not prevent an attacker who controls the device itself from acting during a live session, nor does it replace the need to control endemic malware in endpoints, phishing protection or robust access policies. It is therefore still important to combine DBSC with other measures such as safe navigation, endpoints detection and response and phishing-resistant authentication.

To understand the technical basis it should be remembered that DBSC is based on platform authentication mechanisms: hardware-generated keys and browser APIs that link session credentials to the device. These principles are related to technologies and standards such as WebAuthn and the use of hardware-protected authentication; more technical information can be found in the official specification: W3C WebAuthn and in the documentation on platform TPM modules: Trusted Platform Module (TPM) - Microsoft Docs.

From the perspective of IT and organizations, the mandatory function for Workspace customers reduces the operational risk But it also forces to validate compatibility: old equipment without secure hardware or unupdated browsers could behave differently. It is recommended to test implementation in controlled environments before relying on DBSC as the only shock absorber against incidents.

If you manage security in an organization or are a user concerned about the protection of your credentials, some practical actions are clear: keep Chrome and up-to-date operating systems, check that teams have TPM or equivalent, keep EDR / antimalware solutions active, enable secure browsing modes and promote phishing-resistant authentication mechanisms (e.g., passwords / WebAuthn). It is also good practice to audit active sessions and learn to revoke suspicious access from the Google panel.

In short, DBSC represents a relevant technical advance because it raises the barrier for attackers who profit from stolen cookies, but its maximum effectiveness comes when it is integrated into an in-depth defense strategy: protection of endpoints, solid authentication and coordinated organizational policies will remain essential to reduce the real risk of accountability.