How DBSC ties session cookies to device hardware
Google's Device Bound Session Credentials (DBSC) is designed to cryptographically bind session cookies to the device from which a user authenticated. The mechanism links user sessions to the machine's security chip — for example, the Trusted Platform Module (TPM) on Windows and the Secure Enclave on macOS. Because the unique public/private keys that encrypt and decrypt the sensitive session material are generated by the security chip, Google says those keys "cannot be stolen," and therefore a stolen cookie alone would not allow an attacker to reuse the session on a different device.
Technical framing: prevention rather than detection
Google framed DBSC as a shift away from detection-based defences toward proactive prevention. In April the company said DBSC "fundamentally changes the web's capability" against session-theft attacks by ensuring that "successfully exfiltrated cookies cannot be used to access users' accounts." This week the company added that DBSC "strengthens account security after users are logged in and helps bind a session cookie — small files used by websites to remember user information — to the device a user authenticated from. Even if malware was present on the user's device, DBSC reduces the risk of session theft and makes it meaningfully more difficult for malicious actors to exploit stolen session cookies."
Rollout: who gets DBSC and what controls exist
DBSC moved from beta to general availability and is "rolling out to all users," according to Google. The rollout covers Google Workspace customers, Workspace Individual subscribers, and users with personal Google accounts. Google said the feature will be enabled by default for all Google Workspace customers when it rolls out and that administrators cannot disable it.
Mitigating known abuse techniques
The release directly addresses techniques and claims that have been used to abuse Google authentication. Threat actors previously abused an undocumented Google OAuth "MultiLogin" API endpoint to generate new authentication cookies after stolen ones expired. Information-stealing malware operations named Lumma and Rhadamanthys also claimed they could restore expired Google authentication cookies stolen in attacks to gain access to infected users' Google accounts.
Google's position is that DBSC should effectively block malicious actors from abusing such stolen cookies because the attackers will lack the device-bound cryptographic keys required to use them. Prior guidance from Google recommended removing malware from infected devices and enabling Chrome's Enhanced Safe Browsing mode to defend against phishing and malware; DBSC is presented as an additional defensive layer that operates after login to reduce the risk of session reuse.
What this means for technologists, Workspace administrators, end users, and adversaries
- Technologists and security teams: DBSC introduces a new, hardware-rooted control that shifts some session protection responsibilities to client devices' security chips. Teams will need to account for device-bound keys when designing incident response and session-revocation workflows.
- Google Workspace administrators: The feature will be enabled by default and cannot be disabled, which changes administrative control over session security settings; administrators should prepare for the operational impact of enforced device-bound sessions on their user population.
- End users: For users of Chrome and Google accounts, DBSC aims to reduce the practical value of stolen session cookies even if malware is present on their device. Users previously advised to remove malware and to enable Enhanced Safe Browsing now have an additional, automatic protection layer rolling out to their accounts.
- Adversaries and malware operators: Techniques that rely on reusing or restoring expired authentication cookies — including exploitation of undocumented endpoints or claims by malware families such as Lumma and Rhadamanthys — face a new technical barrier because attackers cannot access the device-generated cryptographic keys required to make exfiltrated cookies usable on a different device.
Google first announced DBSC in 2024 and made it available in beta since April before the current rollout to all users. The company positions DBSC as a structural change to how web sessions are protected: by binding session state to hardware rather than relying solely on detection and revocation after compromise.
Whether DBSC will materially reduce account takeovers will depend on adoption, device support for hardware keys, and how attackers adapt to the loss of cookie reuse as a reliable technique. For now, Google has moved the feature from concept to default behaviour for Workspace customers and extended it to individual and personal accounts — a clear, measurable change in the platform's session-security posture.
