Google’s Device Bound Session Credentials are a meaningful step forward against infostealer malware. They also have significant limits that security teams need to understand before assuming the problem is solved.
On April 10, 2026, Google made Device Bound Session Credentials (DBSC) generally available to Windows users in Chrome 146. The announcement addresses one of the most dangerous and underappreciated attack techniques in the modern threat landscape: session cookie theft by infostealer malware.
The timing is significant. Constella’s 2026 Identity Breach Report documented that infostealers processed 51.7 million packages in 2025, a 72% year-over-year increase, and that these packages are particularly lethal because they contain live session cookies that allow adversaries to bypass MFA entirely. Google’s DBSC is a direct, hardware-level response to exactly that threat vector.
Security teams should understand both what DBSC does and what it does not cover. The gap between those two things is where Constella operates.
What DBSC Actually Does
The session cookie problem is straightforward. When a user logs into a service, the browser stores a session token. That token represents an authenticated state. Any attacker who obtains the token can import it into their own browser and inherit the full authenticated session, bypassing the login, bypassing MFA, and appearing to all systems as the legitimate user.
DBSC closes that specific window by cryptographically binding session cookies to the hardware of the device where authentication occurred. On Windows, this uses the Trusted Platform Module (TPM). On macOS, when support arrives in a future Chrome release, it will use the Secure Enclave. The private key used to generate and validate session credentials is generated inside the hardware security module and never exported. Even if infostealer malware exfiltrates the session cookie, the cookie is useless without the private key, which cannot leave the device.
Google also built in short-lived session cookie rotation and designed the system to be private by design, meaning it does not leak device identifiers or allow websites to correlate user activity across sessions. During a year of testing with partners including Okta, Google observed a meaningful reduction in session theft events. DBSC is a real, well-engineered control for a real, well-documented attack.
The Limits Security Teams Need to Understand
The announcement deserves measured interpretation. DBSC is a meaningful control, not a complete solution to the infostealer credential threat. The gaps are significant.
- Coverage is limited to Chrome on Windows today. macOS support has been announced for a future Chrome release with no published timeline. Mobile browsers are not supported. Other browsers are not supported. Any employee using Firefox, Safari, Edge, or any mobile browser for corporate access is outside DBSC coverage entirely.
- Website implementation is required. DBSC is a client-server protocol. For session binding to work, the website or SaaS platform the user is authenticating to must implement dedicated registration and refresh endpoints on the backend. Google and Okta have done this. The long tail of enterprise SaaS, internal applications, and corporate portals has not. A user’s Google Workspace session may be protected while their corporate intranet, their cloud DevOps environment, and their industry-specific SaaS tools remain entirely unprotected.
- DBSC does not protect passwords, PII, or other harvested data. Infostealer logs contain far more than session cookies. Constella’s analysis of 51.7 million packages in 2025 found that 98.6% contained active passwords and 99.54% included the specific URLs where those credentials were used. Hardware IDs, email addresses, VPN configurations, SSH keys, and cloud tokens are all part of a typical log. DBSC eliminates the cookie theft vector for supported browsers on supported platforms. The rest of what infostealers harvest is unaffected.
- Credentials already in circulation are not addressed. The infostealer ecosystem does not operate on a prospective basis. The 51.7 million packages Constella processed in 2025 represent credentials, tokens, and session data that are already circulating in underground markets, already being used by initial access brokers, already feeding ransomware pipelines. DBSC prevents new session theft from happening on covered browsers. It does nothing to surface or remediate what has already been harvested.
- Devices without TPM support fall back to standard behavior. If a user’s device does not have the required hardware security module, Chrome gracefully degrades to standard session handling. This includes older hardware that is still widespread in many enterprise environments and virtually all personal devices employees use to access corporate resources outside corporate-managed endpoints.
The Bigger Picture: Why Credential Exposure Monitoring Still Matters
The session cookie theft vector that DBSC targets is one part of a larger infostealer problem. The Constella 2026 Identity Breach Report documents the full scope. In 2025, 78% of recently breached companies had corporate credentials appearing in infostealer logs within six months of their breach. The infostealer infection, in most cases, happened before the breach, on devices outside corporate visibility, outside the perimeter of any enterprise security control.
DBSC, when fully implemented, makes stolen session cookies expire immediately. It does not change the fact that infostealers infected 24.8 million unique devices in 2025. It does not change the fact that those infections harvested 2.3 billion passwords. It does not change the fact that the logs produced by those infections are packaged, sold, and used to enable enterprise compromise on a timeline that outpaces most incident response capabilities.
The organizations that suffered ransomware last year because credentials appeared in stealer logs before the attack would not have been protected by DBSC in most cases. Their credentials were harvested from personal devices, contractor laptops, unmanaged endpoints. Not from managed Chrome browsers on Windows 11 with TPM 2.0.
That is the visibility gap Constella fills.
What DBSC and Constella Do Together
DBSC and Constella’s Infostealer Sentinel are complementary, not competing. DBSC is an authentication-layer control that protects the session on supported browsers after authentication. Constella is an intelligence layer that monitors the adversary ecosystem where stolen credentials, including those harvested from every browser on every device, are packaged and sold.
Security teams that deploy DBSC are making it harder for attackers to misuse stolen session cookies from Chrome on Windows. Security teams that deploy Constella Infostealer Sentinel are seeing when employee credentials appear in infostealer packages in real time, across all browsers, across all devices, across all platforms, including the ones DBSC cannot protect.
Andres Andreu, CEO of Constella, observed in the 2026 Identity Breach Report that the identity perimeter has effectively evaporated. DBSC strengthens one specific door. Constella monitors the entire perimeter for the moment credentials appear in the hands of adversaries, regardless of which door they came through.
What Security Teams Should Do Right Now
- Enable DBSC in Chrome for managed devices immediately. For organizations using Google Workspace, the Workspace Admin console has DBSC configuration available now. Enable it for all users. Do not wait for macOS support.
- Inventory your SaaS and application portfolio for DBSC compatibility. DBSC only protects sessions for applications that have implemented the server-side protocol. Audit your critical applications. For those that have not implemented DBSC, treat session cookie exposure as an active, unmitigated risk.
- Do not assume DBSC replaces credential monitoring. The 98.6% of infostealer packages containing active passwords, the VPN credentials, the cloud tokens, the SSH keys: none of that is addressed by DBSC. Continuous dark web monitoring remains essential.
- Pair DBSC with immediate session invalidation protocols. When Constella identifies that an employee’s credentials have appeared in a stealer log, the response should include immediate session invalidation across all active sessions, not just password rotation. DBSC makes that session invaluable if the cookie was already bound, but unbound sessions on other browsers and devices require active invalidation.
- Extend monitoring to personal and contractor devices. DBSC protects managed enterprise browsers. Infostealers preferentially target personal devices and contractor endpoints outside corporate management. That gap is not closed by any browser feature. It is closed by monitoring the adversary ecosystem where the harvested data surfaces.
The Bottom Line
DBSC is one of the most meaningful browser security improvements in years. It directly addresses a technique that Constella’s data confirms is central to the modern identity breach pipeline. Security teams should deploy it everywhere it is available, push their SaaS vendors to implement it, and plan for macOS support when it arrives.
They should also understand that DBSC is one layer, not the full picture. The infostealer threat is not a browser problem. It is an identity exposure problem that spans every device, every browser, every platform, and every channel where corporate credentials can be harvested and sold. Constella covers the full landscape. DBSC covers an important corner of it.
Deploy both.
Schedule a Demo
See how Constella Infostealer Sentinel delivers real-time visibility into credential exposure across every device and browser, before attackers act on what they have stolen.
Sources: Google Chrome Security Blog (April 10, 2026); The Hacker News (April 10, 2026); BleepingComputer (April 9, 2026). Statistics: Constella Intelligence 2026 Identity Breach Report.