Summary
- Google says Device Bound Session Credentials are generally available in Chrome on Windows and enabled by default for Workspace users.
- The feature binds session cookies to the device used for authentication, reducing the value of stolen cookies.
- The change strengthens post-login identity assurance, especially where malware or token theft threatens MFA-protected accounts.
Google Workspace users on Chrome for Windows now have device-bound session credentials generally available and enabled by default, adding a stronger control against session-cookie theft after login.
Google said Device Bound Session Credentials, or DBSC, bind a session cookie to the device from which a user authenticated. Session cookies allow websites to remember authenticated users, but stolen cookies can let attackers access accounts without needing the password or a fresh multi-factor authentication challenge.
The company’s Workspace update says DBSC is now generally available in Chrome on Windows after a beta period. It is enabled by default for Google Workspace customers, with no administrator or end-user setting required. Rollout began on 25 May and may take up to 60 days for feature visibility.
The security control is also available to Workspace Individual subscribers and users with personal Google accounts. Administrators can view DBSC binding events in audit logs through the security investigation tool, while Google says organisations can combine the feature with context-aware access for more granular account controls.
The change reflects a wider shift in identity defence. Multi-factor authentication remains a baseline control, but account takeover risk increasingly sits beyond the login prompt. Attackers target tokens, cookies, browser sessions, OAuth grants, device trust signals, and the artefacts that prove a user has already authenticated.
Session theft weakens the practical assurance of MFA because it attacks what comes after successful authentication. A user may pass a robust login process, while malware on the endpoint, malicious browser tooling, or token extraction still exposes the authenticated session. Once that session is replayed elsewhere, the attacker may not need to trigger the same authentication flow.
Device-bound sessions reduce that portability. If a cookie is cryptographically bound to the device that authenticated, a copied cookie should be less useful on another machine. The control does not make a compromised endpoint safe, and it does not remove the need for endpoint protection, browser hardening, phishing resistance, and monitoring. It does, however, narrows one route from local theft to remote account access.
Default enablement is also relevant to control coverage. Identity protections often lose effectiveness when they depend on complex administrator configuration or user opt-in. A browser-level feature that ships by default can raise the baseline across managed fleets more quickly, provided it works reliably and produces useful telemetry for security teams.
The Windows-only scope leaves practical gaps. Enterprises run mixed operating environments, and session theft does not limit itself to one platform. Organisations using Google Workspace will need to understand where DBSC applies, where it does not, how binding events appear in logs, and how the control interacts with endpoint management, browser policy, conditional access, and incident response workflows.
Identity security is moving beyond the question of whether a user can log in securely. The integrity of the browser, device, session, access context, and downstream SaaS permissions now shapes account risk. MFA remains necessary, but the defensive centre of gravity is shifting towards continuous assurance after the initial authentication event.
Google’s change places session integrity closer to the core of enterprise identity architecture. As attackers adapt around MFA, the controls around authenticated sessions will carry more of the burden.
