Chrome is now using your computer's own chip to stop a fast-growing type of account takeover

The token that keeps you signed in to your bank, your email, and your cloud apps now lives behind a lock that no amount of malware can easily copy. Chrome's new device-bound session credentials, rolled out across recent Windows and macOS builds, anchor the "already logged in" cookie to a per-device key stored inside the secure chip soldered to the machine: a Trusted Platform Module on Windows PCs, a Secure Enclave on Macs and iPhones. The change does not stop every form of account takeover, but it does close a specific, fast-growing hole that two-factor codes and passkeys never covered.

That hole is the session cookie. When you sign in to a site, the site writes a small piece of text into your browser that says, in effect, "this user already proved who they are, skip the login box." For years the security industry focused on protecting the moment of sign-in: stronger passwords, then one-time codes, then passkeys tied to a fingerprint or face. Attackers adapted. One of the fastest-growing forms of credential theft in 2024 and 2025 is not password theft at all. It is infostealer malware, a class of program that copies saved logins and, more importantly, the live session cookie out of the victim's browser and uploads it to the attacker. From there, the attacker pastes the cookie into their own browser and inherits the victim's authenticated session, with no password or second factor required, for as long as the cookie is set to last (Ars Technica).

Device-bound session credentials (DBSCs) are a direct answer to that. When a site opts in, Chrome generates a fresh cryptographic key on the user's device the first time they sign in, stores that key inside the platform's secure element (the TPM on Windows, the Secure Enclave on macOS), and uses it to sign a proof every time the browser talks to the site. A cookie file copied off the disk and dropped into a different machine has no matching key, so the site can reject the session. The mechanism is specified in a public W3C editor's draft maintained by the webappsec working group, not a Chrome-only trick (W3C webappsec-dbsc editor's draft).

Independent reporting and Google's own admin documentation place this in a longer rollout rather than a sudden switch. Google documented the feature as generally available for Chrome on Windows inside Workspace in May 2026 and exposed session-binding controls for administrators (Google Workspace Updates, May 2026; Workspace Admin Help: prevent cookie theft with session binding). Security press described the Windows and macOS landings in April and August 2026, and Scott Helme walked through the macOS build in his analysis of how the on-device key functions (Scott Helme, DBSC lands in Chrome on macOS; Corbado explainer on DBSC).

Three things are worth knowing about what this is and is not. First, the protection only matters on the device that generated the key. A user who signs in on a shared family PC and then walks to their own laptop still has a cookie that the family PC can use, exactly as before. Second, the feature is server-side opt-in: a site has to support DBSCs to require it, so coverage will be uneven for months. Google controls some of the largest relying parties in the world, and Workspace admins can already enforce session binding for managed users, but consumer sites, banks, and SaaS tools each have to wire the protocol in. Third, an attacker who compromises the device itself, with malware running at admin level or with brief access to an unlocked screen, can still read the key out of the secure chip. The new design raises the cost of theft; it does not make device compromise impossible.

For most readers, the practical effect is straightforward. Updating Chrome does not, on its own, make any account safe. The sites you sign in to have to roll out support. When a bank or email provider does, the day a stolen cookie file lands on a different machine is the day that stolen cookie stops being a skeleton key, and a standard account takeover from a coffee-shop malware infection becomes a much harder problem to pull off.

The next milestone worth watching is the W3C webappsec editor's draft moving toward Candidate Recommendation. Once other browsers ship interoperable support, the incentive for large relying parties to require the binding on every login will grow, and the current "opt in if you want it" model can shift to a default for high-value sessions.