Google is rolling out Device Bound Session Credentials (DBSC) for all Chrome 146 users on Windows, positioning the feature as a major step forward in protecting web sessions against stolen cookies and account takeover attacks. By cryptographically tying session tokens to a specific device, DBSC is designed to make exfiltrated cookies effectively useless to attackers.
Why stolen cookies remain a critical session hijacking risk
Session hijacking remains one of the most effective techniques used in modern cybercrime. Instead of breaking passwords or bypassing multi-factor authentication, attackers target session cookies stored in the browser. Once a cookie is stolen, it can often be reused to access the victim’s account without triggering additional security checks.
The primary driver of this problem is info-stealer malware, typically distributed via pirated software, malicious “cracks,” trojanized installers, or phishing attachments. Well-known malware families such as Atomic Stealer, Lumma, and Vidar Stealer are built specifically to collect:
— authentication cookies and session tokens;
— saved passwords and browser autofill data;
— browsing history and form data;
— cryptocurrency wallets and other sensitive information.
Stolen session tokens are particularly valuable because they often have a long lifetime. As a result, attackers can access email, cloud storage, banking, or corporate systems for weeks or months. A 2023 report by Group-IB estimated that info-stealers were responsible for more than 2 billion sets of credentials stolen between 2020 and 2023, many of which are traded on underground markets and used for large-scale account takeover campaigns.
How Device Bound Session Credentials work in Chrome
Originally announced in April 2024, Google’s Device Bound Session Credentials aim to break the economic model behind stolen-cookie markets. The core idea is to bind each session to a single device through cryptography, so that even if cookies are extracted, they cannot be reliably reused elsewhere.
Hardware-backed keys: TPM and Secure Enclave
DBSC relies on hardware-backed security modules where available. On Windows, Chrome uses the Trusted Platform Module (TPM); on macOS, it will use Secure Enclave once support is rolled out. These components generate a unique public/private key pair for session protection. The private key never leaves the device and cannot be exported, even if the operating system is compromised at the user level.
When a user signs in, Chrome requests not just traditional cookies but session credentials tied to this key pair. The public key acts as a marker that the browser can prove possession of the corresponding private key, which is securely stored in the TPM or Secure Enclave.
Short-lived cookies and continuous key proof
With DBSC enabled, the browser no longer relies on a single long-lived cookie. Instead, short-lived session cookies are issued and refreshed only after Chrome proves to the server that it controls the correct private key. This proof is based on standard cryptographic operations, such as signing a challenge from the server.
This architecture changes the threat model for attackers. Even if an info-stealer successfully extracts cookies from the victim’s browser, those tokens will expire quickly and cannot be renewed, because the attacker does not possess the protected private key. The stolen cookie becomes, at best, a short-lived artifact rather than a persistent backdoor into the account.
If a device does not support secure key storage, DBSC gracefully falls back to traditional session handling. This ensures that authentication flows continue to work while allowing gradual adoption of the new standard across diverse hardware and operating systems.
Deployment in Chrome 146 and impact on enterprises
Google has now enabled DBSC by default for all Chrome 146 users on Windows, with macOS support planned for an upcoming release. According to Google’s early telemetry from public testing, the company has already observed a measurable reduction in successful session hijacking incidents, indicating that the approach is effective in real-world environments.
The technology requires implementation both in the browser and on the server side. Web applications must support the new session issuance and verification model in order to fully benefit from DBSC. As more major cloud providers, SaaS platforms, and identity providers adopt DBSC, its cumulative impact on the cybercrime ecosystem is expected to increase, particularly in enterprises where session tokens can unlock highly sensitive resources.
Privacy safeguards and open web standard ambitions
Device Bound Session Credentials are being developed jointly by Google and Microsoft with the explicit goal of becoming an open web standard. This would allow other browsers and vendors to implement compatible protections, making DBSC a cross-ecosystem defense rather than a vendor-specific feature.
From a privacy perspective, the architecture is intentionally designed to avoid device tracking and fingerprinting. Key principles include:
— websites cannot use DBSC session credentials to track users across different sites or long-term sessions;
— servers receive only the public key and minimal metadata needed to verify possession of the private key, without persistent device identifiers or attestation blobs;
— DBSC is not intended as a device fingerprinting mechanism and is engineered to minimize cross-site tracking capabilities.
This combination—stronger protection against session theft without expanding tracking capabilities—aligns with growing regulatory expectations around data protection, transparency, and privacy-by-design, especially in jurisdictions with strict compliance requirements such as the EU and UK.
For organizations, DBSC represents a practical opportunity to directly reduce the value of stolen cookies on underground markets and to disrupt account takeover campaigns. Security teams should begin assessing their web applications for DBSC compatibility, prioritizing services that expose high-value data or administrative access. In parallel, it remains essential to harden endpoints against info-stealer malware, enforce regular browser updates to at least Chrome 146, and educate users on the risks of untrusted downloads. Combined, these measures can significantly raise the cost of session hijacking for attackers and improve the overall resilience of both consumer and enterprise environments.
