The Problem DBSC Targets
Session-cookie theft is the quiet workhorse of modern account takeover. A user signs in, completes multi-factor authentication, and the browser receives a session cookie that proves the session is already authenticated. An infostealer that lands on the device copies that cookie, and the attacker imports it into their own browser. The stolen session is fully authenticated, so it sails past the password and the second factor that were supposed to protect the account. We covered the mechanics of this replay in our earlier note on device-bound session abuse; the short version is that a portable cookie is a portable identity.
This is why infostealers became a growth industry. The value is not the password in the dump, which MFA blunts. The value is the live session cookie, which MFA does nothing to stop once it has been copied. Defenders have spent years treating the symptom: detecting the impossible-travel sign-in, the new-device session, the anomalous mailbox access that follows a replayed cookie. Device Bound Session Credentials attack the cause.
How DBSC Binds the Session
DBSC works by cryptographically linking a browser session to the device's hardware. When a session is established, the device's security chip generates a public/private key pair: the Trusted Platform Module on Windows, the Secure Enclave on macOS. The private key is created inside that chip and cannot be extracted from it. Chrome then periodically proves to the server that it still holds the bound key, refreshing short-lived credentials as it goes.
The consequence for an attacker is decisive. A cookie copied off the machine is no longer sufficient on its own, because the server expects ongoing proof of possession of a private key that never left the original device's security chip. The stolen cookie cannot be replayed from the attacker's browser, because the attacker cannot reproduce the hardware-held key the session is now tied to. Google reported that its internal testing blocked the large majority of attempted cookie-theft scenarios, and that it observed a measurable reduction in session theft as deployment expanded.
The rollout is the part defenders should note. DBSC is generally available for Windows users in Chrome 146, with macOS support arriving in a later release, and it is on by default for Workspace accounts with no administrator action needed to activate it. For most organizations this protection arrives as a browser and platform update rather than a project.
What It Does Not Stop
DBSC removes the payoff from cookie *exfiltration*. It does not remove the attacker from the device, and that distinction defines its limits. Everything that put the infostealer on the machine in the first place is untouched: the phishing message that delivered it, the malicious installer, the compromised extension, the user who ran the thing they should not have. DBSC is a control on what a stolen cookie is worth after the fact, not a control on the initial compromise.
It also does not stop abuse that happens on the bound device itself. If malware is running on the same machine as the legitimate session, it can operate within the context of that session locally rather than exfiltrating a cookie to replay elsewhere. Binding the cookie to the hardware does not help when the attacker is already executing on that hardware. The technique raises the cost of remote replay; it does not evict an on-device adversary.
And it is, for now, partial in coverage. Generally available on Windows with macOS still to come, and dependent on a device actually having and using a hardware security chip, DBSC will protect part of an estate before it protects all of it. An attacker chasing sessions will simply concentrate on the surfaces it does not yet cover: other browsers, unbound sessions, platforms awaiting the feature, and the on-device path above.
What Defenders Should Do With It
Treat DBSC as a genuine and welcome reduction in the value of stolen cookies, and adjust the threat model accordingly rather than declaring session hijacking solved. The right posture is to let DBSC shrink the remote-replay surface while keeping every control that addresses the parts it does not cover.
Keep working the entry point, because that is where the attack still begins. The delivery of an infostealer through a phishing lure, a fake installer, or a malicious extension is the event DBSC does nothing about, and stopping it remains the highest-leverage control. Keep your detections for on-device session abuse, since a bound cookie does not protect a session from malware sharing its machine. And keep server-side session revocation sharp, because the ability to kill a session and its grants centrally is what contains the cases that slip through any client-side binding.
For teams running exercises, the useful question is no longer only "can we steal and replay a cookie." On a DBSC-protected surface that path is meant to fail, and confirming it fails is a worthwhile test in itself. The more revealing exercise is whether the organization can still detect and contain an attacker who operates within a session on the device, or who pivots to the surfaces binding does not yet reach. DBSC moves the contest; it does not end it.