Stolen browser cookies have become one of the most traded commodities on criminal marketplaces, letting attackers slip into accounts without ever needing a password. With the release of Chrome 146 in May 2026, Google is trying to break that economy at its root. The update introduces Device Bound Session Credentials (DBSC), a feature that cryptographically locks authentication cookies to the hardware where they were created, rendering them useless if copied to another machine.
The rollout is live on Windows and enabled by default, meaning users who keep Chrome up to date are already protected for Google account sessions without changing a single setting.
How Device Bound Session Credentials work
When a user signs into a website that supports DBSC, Chrome generates a public-private key pair and stores the private key inside the device’s Trusted Platform Module (TPM 2.0) or, on machines that lack one, a software-based secure store. Google first outlined this architecture in a 2024 Chromium blog post describing the DBSC proposal, which specified TPM 2.0 on Windows as the primary key store with a software fallback for devices without a compatible module. The session cookie issued by the server is then bound to that key. Every subsequent request includes a cryptographic proof that the cookie is still on the original device.
If an infostealer exfiltrates the cookie file and an attacker tries to replay it from a different computer, the server checks for the hardware proof, finds none, and kills the session. The cookie, once a skeleton key, becomes a dead token.
That matters because session cookies have long been the preferred loot for malware families like RedLine, Vidar, and Raccoon Stealer, all of which remained among the most active infostealer families tracked by threat intelligence firms through early 2025. A valid session cookie lets an attacker bypass both passwords and multi-factor authentication entirely, effectively cloning a logged-in session. According to BleepingComputer’s reporting, DBSC targets that exact vector, starting with Google’s own services and opening the protocol for third-party sites to adopt. BleepingComputer attributes the initial Google-account focus to its own analysis of the rollout rather than to a named Google spokesperson, so the precise scope of the first phase has not been confirmed by an official Google statement.
Why Google chose this approach
Most defenses against cookie theft are reactive: endpoint detection tools try to catch the malware before it exfiltrates, or security teams revoke sessions after a breach is discovered. DBSC flips the model. Rather than racing to detect every new stealer variant, it devalues the stolen goods themselves. Even if malware successfully grabs a cookie database, the tokens inside cannot be monetized on underground markets because they will not authenticate anywhere else.
The scale of the problem Google is responding to is substantial. Security firm SpyCloud reported in its 2024 Annual Identity Exposure Report that billions of stolen credentials and session tokens circulated on criminal forums, with infostealer-harvested cookies representing a fast-growing share of the underground economy. Google’s decision to enable DBSC by default reflects that urgency. Browser security options that require manual activation tend to reach only a fraction of users. By shipping DBSC as an automatic upgrade, Chrome ensures that every Windows user on version 146 or later benefits immediately.
As Hackread emphasizes, DBSC is not a replacement for password managers or multi-factor authentication. It protects the session token that exists after a successful login. Users still need strong, unique passwords and MFA on critical accounts; DBSC simply closes a gap those tools were never designed to cover.
What DBSC does not cover
Cookies are only one item on an infostealer’s shopping list. These malware families also harvest saved passwords, autofill data, cryptocurrency wallet files, desktop application tokens, and local documents. DBSC neutralizes the cookie category but leaves the rest untouched. Anyone running an infected machine still faces serious exposure beyond session hijacking.
Platform coverage is the other major limitation. Google has confirmed DBSC only for Windows so far. Chrome runs across macOS, Linux, ChromeOS, Android, and iOS, and attackers will predictably shift focus toward platforms where the binding does not yet exist. Google has not published a timeline for broader support, which leaves mixed-OS environments partially exposed.
Server-side adoption adds another layer of uncertainty. DBSC requires participating websites to verify the hardware-bound proof during session validation. Google can enforce this for Gmail, YouTube, and Workspace, but banks, social media platforms, and SaaS providers would each need to integrate the protocol into their own authentication stacks. Until that happens, protection outside Google’s ecosystem depends on third-party willingness to adopt.
Open questions for security teams
Independent researchers have not yet published controlled tests pitting DBSC against active infostealer toolkits. Google’s cryptographic design is sound on paper: without the private key held in the TPM, replay should fail. But malware authors adapt quickly. Potential attack surfaces include attempts to extract TPM-resident keys, abuse of debugging interfaces, or race conditions that target sessions before binding completes. Outside validation will be critical in the coming months.
Performance impact is another gap in the public record. Generating and verifying cryptographic proofs for every protected session adds computational steps. Google has not released engineering benchmarks detailing latency or resource consumption. For enterprise IT teams managing thousands of endpoints, especially those with older hardware, concrete numbers will matter for capacity planning.
Edge cases also need clarification. Organizations that rely on virtual desktop infrastructure, remote browser isolation, or roaming user profiles may find that device binding behaves unpredictably when the underlying hardware abstraction shifts. Until Google publishes detailed deployment guidance, administrators will have to test behavior in their own environments.
All confirmed details about DBSC in Chrome 146 currently come from secondary reporting by outlets such as BleepingComputer, GBHackers, and Hackread rather than from a dedicated Google engineering blog post or official Chrome 146 release notes specific to the feature. The technical descriptions are consistent across those independent publications, which increases confidence in the core facts, but a formal specification covering cryptographic primitives, fallback behavior, and interaction with existing cookie policies has not yet appeared. Security professionals evaluating DBSC for enterprise deployment should monitor the official Chromium blog and Chrome Releases channel for primary documentation.
How DBSC changes the calculus for cookie-theft defenses
For individual Chrome users on Windows, the immediate step is to update to Chrome 146 and confirm the browser is current. DBSC activates automatically. Multi-factor authentication, unique passwords, and caution with unfamiliar software remain essential, because an infected machine still leaks plenty of data beyond cookies.
For users on macOS, Linux, or mobile platforms, standard defenses remain the front line: keep operating systems and browsers patched, run reputable security software, limit browser password storage on shared machines, and favor hardware security keys or app-based authenticators over SMS verification.
Enterprise security teams should watch Google’s official Chromium channels for a full technical specification, administrative policy controls, and a cross-platform roadmap. DBSC’s value at scale hinges on three factors: expansion beyond Windows, predictable behavior in virtualized and managed environments, and broad server-side adoption by the external services employees use daily. Until those pieces fall into place, DBSC is best understood as a strong, targeted mitigation that shrinks the payoff of cookie theft on supported systems rather than a blanket fix for the infostealer problem.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
