On 9 April 2026 Google's Chrome team announced that Device Bound Session Credentials (DBSC) is entering public availability for Windows users on Chrome 146, with macOS support coming in a later release. DBSC ties a login session to the device that created it, so a cookie copied off a laptop by malware stops being useful somewhere else.
For years the answer to infostealers was "MFA". MFA does not help once the session cookie exists, because the cookie is the proof that MFA already happened. DBSC attacks that gap.
What's affected
Google's post is the primary source here, and it is specific about scope.
- Browser and OS. Chrome 146 on Windows. macOS is described as coming in an upcoming release.
- How it works. A hardware-backed module generates a key pair that cannot be exported: the TPM on Windows, the Secure Enclave on macOS. Chrome has to prove it holds the private key before the server issues new short-lived session cookies. A stolen cookie expires quickly and cannot be renewed.
- What the site changes. The web app keeps using ordinary cookies. The backend adds dedicated registration and refresh endpoints. The front end can stay as it is.
- Privacy. Each session has its own key, which prevents correlation across sessions or sites, and the protocol does not expose device identifiers beyond that per-session public key.
- Standards. DBSC is being developed as an open standard in the W3C Web Application Security Working Group. Google worked with Microsoft on the design and ran two origin trials, with Okta among the participants.
Google names LummaC2 as an example of malware that extracts session cookies. It also says there is "no reliable way to prevent cookie exfiltration using software alone on any operating system", which is the reason for the hardware key.
How to check if you're exposed
Exposure here means "if one of my users has an infostealer, can the attacker keep the session?" Check three things.
- Session lifetime. Find out how long your session cookie is valid and whether it is renewed silently. A cookie valid for 30 days is a 30 day window for an attacker.
- Where sessions are issued. If sign-in is delegated to an identity provider, the provider owns this protection. Google lists cross-origin binding for federated sign-in as still in development, so do not assume it covers SSO yet.
- Who uses what. Your Windows users on Chrome 146 or later can benefit once a site supports it. Users on other browsers or on devices without a TPM or Secure Enclave cannot. Google says software-based keys for such devices are being explored, not offered.
What to do now
- Shorten session lifetimes for admin and finance roles, and require a fresh sign-in for sensitive actions. This helps with or without DBSC.
- If you build a web app, read Chrome's DBSC developer guide and plan the registration and refresh endpoints. Start with your admin console, not the marketing site.
- Keep the ability to kill sessions. For Microsoft Entra,
Revoke-MgUserSignInSession -UserId $userIdinvalidates a user's refresh tokens and browser session cookies. Microsoft notes a delay of a few minutes. - Add endpoint controls against infostealers. DBSC reduces the value of theft, it does not stop the malware running.
- Watch for impossible-travel and new-device events on sessions that never re-authenticated.
Why it matters
Google says DBSC-protected sessions saw a "significant reduction" in session theft in the early rollout, without giving figures, so treat the effect as real but unquantified. It also does not claim the problem is solved. Malware on the device can still act inside a live session while the user is signed in.
The practical lesson is to stop treating the session as a long-lived secret. Short lifetimes, step-up checks and binding together do more than any single control.
Quick check
Why does a stolen cookie fail under DBSC?
Because the server only issues new short-lived cookies after the browser proves it holds a private key that never leaves the device's TPM or Secure Enclave.
Does DBSC change what the web app's front end does?
No. The app keeps using standard cookies. The backend adds registration and refresh endpoints, per Google.
