The move gives Chrome users and organisations a stronger layer of protection after login, where many account takeovers now occur even when passwords and multi-factor authentication have already been passed. DBSC links a user’s authenticated web session to the device on which it was created, making stolen cookies far less useful when copied to another machine.
The feature, previously tested in beta for Google Workspace environments, is now enabled by default for Google Workspace customers using Chrome on Windows. It is also being made available to Workspace Individual subscribers and personal Google account users, with a gradual rollout that began on May 25 and may take up to 60 days to become visible across eligible environments.
Session cookies allow websites to remember that a user has already signed in, reducing the need for repeated logins. That convenience has also made them a prime target for information-stealing malware. Once attackers obtain valid cookies, they can sometimes bypass password prompts and additional authentication checks, gaining access to email, cloud storage, financial dashboards, business tools and social media accounts without needing the victim’s password.
DBSC changes that model by using cryptographic proof tied to the original device. During a protected session, Chrome generates a public and private key pair, with the private key stored in hardware-backed security where available, such as the Trusted Platform Module on Windows. Servers can then require Chrome to prove possession of that private key before issuing or refreshing short-lived session cookies.
The practical effect is that a stolen cookie alone should no longer be enough to maintain access from a separate device. Attackers attempting to reuse exfiltrated cookies would face an additional barrier because they would not have the non-exportable private key held on the victim’s machine. That makes large-scale resale or automated abuse of stolen session tokens more difficult.
Google has framed the shift as a move from reactive detection to preventive defence. Traditional anti-abuse systems often rely on spotting suspicious activity after session theft has occurred, using signals such as device changes, unusual locations, behavioural anomalies or risk scoring. DBSC seeks to reduce the value of stolen tokens before they can be used elsewhere.
The update arrives as session theft has become a central concern for enterprise security teams. Infostealer malware families have grown more capable at harvesting browser data, credentials, authentication tokens and cookies from infected machines. Such tools are commonly distributed through phishing, fake software downloads, malicious advertisements, compromised websites and deceptive files sent to employees or creators.
For Workspace administrators, the general availability release removes the need to manually enable DBSC through the Admin console. The feature is on by default, and there is no end-user setting to switch it on. Administrators can monitor DBSC binding events through audit logs in the security investigation tool, giving security teams more visibility into when session binding is applied.
The feature can also work alongside context-aware access controls, allowing organisations to apply more granular account protections based on device, user and session signals. That combination is likely to appeal to large enterprises, schools and public-sector bodies seeking to reduce the risk of account compromise without adding visible friction for users.
DBSC is designed to be additive rather than disruptive for websites adopting the technology. Developers can integrate it into existing authentication systems by registering a device-bound session, using short-lived cookies and adding a refresh mechanism that validates possession of the device-held key. Where secure key storage is not available, the system can fall back to standard behaviour rather than breaking the user’s login flow.
The standard is still developing through the Web Application Security Working Group, and broader adoption will depend on implementation by browsers, identity providers and major web platforms. Google has indicated that support will expand to macOS in a forthcoming Chrome release, where secure hardware such as the Secure Enclave can be used for key protection.
Security specialists are likely to treat DBSC as an important hardening measure rather than a complete answer to account takeover. It does not remove the need for endpoint protection, patch management, phishing-resistant authentication, malware detection and user training. If malware remains active on a user’s machine, attackers may still be able to act locally inside the live session, even if they cannot easily export the session for use elsewhere.
The technology also does not replace passkeys or multi-factor authentication. Instead, it addresses a different stage of the attack chain. Passkeys and strong authentication help protect the login process, while DBSC focuses on protecting what happens after login by limiting the portability of session credentials.
For businesses, the change could reduce the impact of credential theft campaigns that target cloud accounts and browser-stored tokens. Compromised business accounts are often used to access sensitive files, reset passwords, launch invoice fraud, steal customer data or pivot deeper into corporate systems. Tying sessions more closely to trusted devices makes such attacks harder to scale.
Chrome’s large share of the browser market gives the rollout broader significance. If more web services adopt DBSC and other browsers implement compatible protections, session binding could become a standard part of web authentication architecture. That would mark a shift away from long-lived bearer cookies, which have long remained valuable to attackers precisely because possession of the token can be treated as proof of identity.
Follow Arabian Post
Select Arabian Post as your preferred source on Google and MSN News for trusted business news and Arab politics and updates.
