Google starts rolling out device-bound Chrome sessions to make stolen cookies far less useful
5 min. read 
Published on
Google has started rolling out Device Bound Session Credentials, or DBSC, as a new Chrome security feature designed to cut down session hijacking. In plain terms, it binds a logged-in web session to the user’s device, so a stolen session cookie should not work properly on another machine.
The change targets one of the most abused account takeover methods on the web today. Google says infostealer malware can grab session cookies from browser files or memory, which lets attackers bypass passwords and even multi-factor authentication if the session stays valid long enough.
Access content across the globe at the highest speed rate.
70% of our readers choose Private Internet Access
70% of our readers choose ExpressVPN
Browse the web from multiple devices with industry-standard security protocols.
Faster dedicated servers for specific actions (currently at summer discounts)
Google’s answer is to make Chrome prove it still has a hardware-protected private key before a protected session can continue. That shifts defense away from spotting abuse after the theft and toward stopping stolen cookies from being reused in the first place.
How DBSC works
DBSC uses hardware-backed security on the device to create a public and private key pair during login. On Windows, Chrome stores that private key in the Trusted Platform Module, and Google says macOS support will use the Secure Enclave.
After that, websites that support DBSC can move to short-lived session cookies. When one of those cookies expires, Chrome contacts a refresh endpoint and proves it still holds the private key tied to that session before the server issues a fresh cookie.
That means an attacker who steals the cookie but not the device-bound key gets very little value. Google says those stolen cookies should expire quickly and cannot be renewed on another machine because the attacker does not have the original hardware-backed key.
What Google says about rollout
Google’s security blog says DBSC is now entering public availability for Windows users and will expand to macOS in an upcoming release. Google also says it rolled out an earlier version over the past year and saw a significant reduction in session theft for protected sessions.
There is one version detail worth noting. Google’s Chrome developer blog said DBSC became available in Chrome 145 on Windows, while Chrome Enterprise release notes say the feature rolls out gradually in Chrome 145 on Windows and in Chrome 147 on macOS. That makes the broader point clear even if some reports cite Chrome 146: the Windows rollout is live, and macOS support is next.
This does not protect every site by default on day one. Web services need to add DBSC support on the backend, but Google says the required changes are limited to registration and refresh endpoints, while the browser handles the cryptography and cookie rotation in the background.
Why this matters for users and companies
Session theft has become a favorite tool for cybercriminals because it gives them account access without needing the password again. Google says malware such as LummaC2 has grown more capable at harvesting these tokens, which are then often sold or traded among threat actors.
That makes DBSC important well beyond Chrome itself. If major services adopt it, stolen cookies should lose much of their value, which could weaken one of the biggest business models behind infostealer malware.
Google also built privacy limits into the design. The company says each session uses a separate key, and the protocol avoids exposing device identifiers or attestation data beyond the session public key needed for proof of possession. That is meant to stop DBSC from turning into a cross-site tracking or fingerprinting tool.
Key facts at a glance
| Item | Details |
|---|---|
| Feature | Device Bound Session Credentials |
| Main goal | Make stolen session cookies much harder to reuse |
| Windows support | Public rollout underway; official docs place rollout in Chrome 145 on Windows |
| macOS support | Planned next; enterprise notes place gradual rollout in Chrome 147 |
| Hardware used | TPM on Windows, Secure Enclave on macOS |
| Site changes needed | Registration and refresh endpoints |
| Privacy design | Separate key per session, minimal data sharing |
The rollout details, platform notes, and implementation model come from Google’s security blog, Chrome developer documentation, and Chrome Enterprise release notes.
What stands out
- Google says DBSC moves defense from reactive detection to proactive prevention.
- The feature relies on hardware-backed keys that attackers cannot export from the victim’s machine.
- Websites do not need to rebuild their full sign-in flow to use it.
- Google developed DBSC as an open web standard with the W3C process and says Microsoft and Okta were involved in testing and feedback.
FAQ
Google wants to stop attackers from reusing stolen session cookies to hijack logged-in accounts. The company says cookie theft remains a common and effective attack method.
Not instantly in every case, but Google says protected sessions switch to short-lived cookies that cannot be refreshed without the device-bound private key. That sharply limits what an attacker can do with a stolen cookie alone.
Yes. Google says sites need to add DBSC registration and refresh endpoints before Chrome can use the protection for those sessions.
Windows is first. Google says macOS support is coming in a later release, and Chrome Enterprise notes point to Chrome 147 for a gradual macOS rollout.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
Improve this guide
User forum
0 messages