Chrome ties sessions to devices
Google rolled out Device Bound Session Credentials in Chrome 146 to cryptographically bind session cookies to a user’s device, a move aimed at blocking session‑stealing malware. The feature is shipping on Windows now and rolling toward macOS, shifting browser evolution toward security-first changes that nonetheless affect how session‑based signals are collected. (helpnetsecurity.com, techradar.com)
A browser cookie is the little pass that tells a site you already proved who you are, so you do not have to type your password on every click. The problem is that if malware steals that pass, the thief can often walk straight into the account without repeating the login or the two-step check. (developer.chrome.com, blog.chromium.org) Google’s fix is to make that pass work only on the device that created it, the way a hotel key card stops working if you copy the room number onto paper. In Chrome, that system is called Device Bound Session Credentials, and Google said on April 9, 2026 that it is entering public availability for Windows users in Chrome 146. (security.googleblog.com, developer.chrome.com) The trick is a private key, which is a secret cryptographic key the browser keeps like a house key that never leaves your pocket. The site gets the matching public key, and later asks Chrome to prove it still holds the private key before it refreshes the session. (developer.chrome.com, security.googleblog.com) On Windows, Chrome can anchor that private key in the Trusted Platform Module, which is a security chip built to keep secrets from being exported as plain files. Google said the Windows rollout is live now, and macOS support is planned for an upcoming Chrome release. (security.googleblog.com, developer.chrome.com) This matters because old cookie protection mostly defended against the wrong thief. Google wrote in 2024 that the Data Protection API on Windows can protect cookies from other users on the same machine or from offline theft, but not from malware already running as you, because that malware can call the same system interfaces as the browser. (security.googleblog.com, blog.chromium.org) The new system does not replace passwords, and it does not replace multi-factor authentication, which is the extra code or prompt you approve after typing a password. It tries to stop the specific shortcut where infostealer malware grabs a live session after those checks are already done. (developer.chrome.com, security.googleblog.com) Websites have to opt in. Chrome’s developer documentation says a site registers a device-bound session with response headers, then asks the browser for proof of key possession when it renews the session, so protection appears only on services that wire it into their login flow. (developer.chrome.com, developer.chrome.com) Google started this in public testing before this week. Chromium announced the idea in April 2024, Chrome opened an Origin Trial in Chrome 135, and Chrome 136 beta listed Device Bound Session Credentials as a new web platform feature before the wider Chrome 146 release on Windows. (blog.chromium.org, developer.chrome.com, developer.chrome.com) That changes one quiet assumption of the web: a logged-in session is no longer just a string stored in a browser profile, but a string plus a hardware-backed proof tied to one machine. If other browsers and major sites follow Chrome’s lead, stealing a cookie file will stop being enough for a large class of account takeovers. (developer.chrome.com, security.googleblog.com)
