Google has officially moved Device Bound Session Credentials (DBSC) to general availability in the Chrome browser on Windows, delivering one of the most significant browser-level defenses against session cookie theft in recent memory. Previously available in beta for Google Workspace users, DBSC is now enabled by default across all Workspace customers, Individual subscribers, and personal Google accounts.

Why Session Cookie Theft Matters

Session cookies are small files that websites use to remember authenticated users between requests. They have long been among the most coveted targets for threat actors because stealing them effectively hands attackers the keys to an active, authenticated session — bypassing even multi-factor authentication entirely.

This technique, commonly known as a pass-the-cookie attack, is exploited by an entire ecosystem of malware. Infostealer trojans such as Raccoon, RedLine, and Lumma routinely harvest browser session cookies from compromised endpoints and sell them on criminal marketplaces, where buyers use them to immediately hijack email accounts, cloud services, SaaS platforms, and corporate environments.

How DBSC Works

Device Bound Session Credentials counter this attack by cryptographically binding a session cookie to the specific device the user authenticated from. The binding is achieved using the device’s Trusted Platform Module (TPM) chip, which generates and stores a private key that never leaves the device. When a session is established, the server issues a credential that can only be validated using that device’s TPM-backed key.

The practical implication is decisive: even if malware successfully exfiltrates a session cookie from a compromised endpoint, that stolen cookie becomes essentially useless on any other machine. The attacker cannot replay the credential elsewhere, because session validity requires a cryptographic proof that only the original device can produce. This fundamentally breaks the pass-the-cookie attack model and significantly raises the operational cost for threat actors relying on stolen session tokens.

Integration with Context-Aware Access

Google has amplified DBSC’s defensive value by integrating it with Context-Aware Access (CAA). Organizations leveraging both capabilities can enforce more granular access policies based on device attributes, user behavior, network signals, and environmental context — adding a continuous layer of verification that extends well beyond the initial authentication event.

For enterprise security teams, this combination means that sessions are not simply validated once at login but are continuously verified throughout their lifecycle. This is a meaningful architectural shift away from perimeter-based trust models and toward zero-trust session management.

Visibility and Auditability

Workspace administrators can now monitor DBSC binding events directly through the security investigation tool’s audit logs. This enables security teams to detect anomalies, track session integrity across the environment, and flag deviations that may indicate active session hijacking attempts — even in cases where the attacker obtained a valid cookie through means other than direct malware exfiltration.

Notably, DBSC requires no administrative action to enable — it is active by default and cannot be disabled through the Admin console, ensuring consistent coverage across the managed user base without requiring policy configuration.

Rollout Timeline and Availability

Google began a gradual rollout on May 25, 2026, covering both Rapid Release and Scheduled Release domains. Full feature visibility is expected within 60 days. DBSC is broadly available to:

• All Google Workspace customers (all tiers)
• Workspace Individual subscribers
• Users with personal Google accounts on supported Windows devices

What Security Teams Should Do

For enterprise security teams, the most immediate action is to review audit logs within the Google Admin console to establish a baseline of normal DBSC binding behavior. Any deviations — such as unexpected binding failures, anomalous geographic patterns, or sessions authenticated on one device suddenly appearing to originate from another — should be treated as potential indicators of session compromise and investigated accordingly.

DBSC represents a meaningful and overdue architectural evolution in post-authentication security. As infostealer malware and cookie-theft-as-a-service operations continue to proliferate, hardware-backed session binding closes one of the most persistent and damaging gaps in enterprise identity security.