Google first had the security community humming with its announcement of Device Bound Session Credentials (DBSC) for Chrome in 2024. The standard has since reached general availability in Chrome on Windows in 2026, shipping in Chrome 146. macOS support, backed by the Secure Enclave, has been announced as the next target, and Google has signaled software-based keys for devices without secure hardware on its roadmap. Other browsers have not yet shipped it as of the time of writing.
The core idea behind DBSC is to bind the browser’s session to a private key stored in the device’s Trusted Platform Module (TPM) on Windows, or the Secure Enclave on macOS as that support lands. The private key never leaves the secure hardware. When a session is bound this way, an attacker who steals the session cookie can’t replay it, because using the session requires periodically proving possession of a key the attacker doesn’t have. Without that key, the stolen cookie is cryptographically useless.
In this blog, we’ll dig into the latest with DBSC and its implications for defenders, including:
What is Google Chrome DBSC?
DBSC is a browser security standard developed by Google. The idea is straightforward: tie an authenticated session to the device that established it. When a session is registered, the browser generates a public-private key pair, stores the private key in hardware-backed storage like the TPM, and then periodically proves possession of that key to refresh a short-lived cookie. The pairing of a non-exportable key with a short cookie lifetime is what makes the difference; a cookie copied off the device can’t be refreshed and expires quickly, so it’s worthless on any machine but the one that holds the key. In short, it makes it far more difficult for cybercriminals to leverage stolen session cookies to carry out session hijacking attacks.
How Google DBSC aims to prevent cookie theft
There’s no question – Google’s DBSC is a meaningful control. Here at SpyCloud, we have the world’s largest database of proof showing just how bad the session hijacking problem is today. In 2025 alone, we recaptured 8.6 billion stolen cookie records from the criminal underground, so we are big fans of anyone and anything that shares our mission of disrupting cybercrime.
DBSC narrows a real attack surface: infostealer malware that copies the browser’s cookie database and AiTM kits like Evilginx, Tycoon2FA, and FlowerStorm that intercept session cookies in transit. Where a session is device-bound, the stolen cookie is useless to an attacker without the private key. This step forward by Google is a welcome newcomer to this fight.
That being said, much like token binding, it’s not a perfect solution, and we expect the road to reaping the potential benefits to take a while. Attackers are also already working other ways around it, which we get into below.
Chrome DBSC requirements and implementation
| Platform | DBSC status |
|---|---|
| Chrome on Windows | Generally available (2026, Chrome 146; account rollout began May 25, 2026) |
| Chrome on macOS | Announced; Secure Enclave-backed, in a future Chrome release |
| Other browsers (Firefox, Safari, Edge) | Not yet shipped |
| Mobile devices | Not yet supported |
What this means for enterprise coverage today
Teams wanting to rely on DBSC will need the Google Chrome browser on Windows, since that’s where the standard is generally available today. If your workforce runs Chrome on Windows, DBSC is available — but only where website owners have implemented the necessary server-side changes to issue device-bound sessions. Adoption requires both browser support and application-layer upgrades; a Chrome update alone doesn’t activate DBSC for a given site.
Adoption requires both browser support and application-layer upgrades; a Chrome update alone doesn’t activate DBSC for a given site.
Devices without secure hardware sit outside DBSC’s protection for now. On a machine with no TPM or Secure Enclave, Chrome falls back to standard cookie behavior without breaking the session, so there’s no disruption, but there’s also no device binding. Google has said software-based keys are planned to widen coverage to hardware that lacks a secure element. While most business laptops manufactured from 2018 onward include TPM 2.0, older hardware, non-Windows devices, and mobile remain real coverage gaps in a heterogeneous enterprise environment.
History teaches us that technology innovations like 2FA, MFA, FIDO, passkeys – and now Google Chrome DBSC – don’t happen overnight and often take many years to become widespread. Broad implementation with mass coverage of consumer devices may happen by 2030. If competing standards appear or website owners are slow to implement the necessary software changes, the adoption timeline could stretch further into the future.
What DBSC protects against – and what it doesn't
DBSC protects against:
- Cookie theft by infostealer malware: When malware copies the browser’s SQLite cookie database, any stolen DBSC-protected cookie cannot be replayed. Without the hardware-bound private key, the cookie is cryptographically useless to the attacker on another machine.
- AiTM kit interception of session cookies in transit: Tools like Evilginx, Tycoon 2FA, and FlowerStorm intercept session cookies as part of reverse-proxy phishing attacks. Where the device binding reaches the victim's browser, the intercepted cookie is bound to the victim's device and can't be replayed from the attacker's machine. Two caveats matter here: a reverse proxy can strip the registration header to prevent the binding from happening at all, downgrading the session to an ordinary bearer cookie, and in most AiTM flows the attacker also walks away with the refresh token, which DBSC does not bind (see below).
- Replay of previously exported cookies: Against DBSC-protected Chromium sessions on hardware-backed devices, previously stolen cookie databases become worthless.
- Cookies decrypted after an App-Bound Encryption bypass: Chrome's App-Bound Encryption raised the cost of reading the cookie store at rest, and attackers have already built bypasses for it. DBSC backstops that control. A cookie successfully decrypted and exfiltrated still can't be replayed off the device that holds the key.
DBSC does not address:
- Refresh token theft: Once an attacker holds a refresh token – from device code phishing, from an AiTM phishing kit, or from infostealer malware that exfiltrated browser-stored auth data – DBSC has no authority. Refresh tokens operate outside the browser session cookie lifecycle. In most enterprise environments (Microsoft Entra ID, Okta, Google Workspace), refresh tokens persist for extended periods by default, surviving password resets and MFA re-enrollment.
- Device code phishing: This attack abuses the OAuth 2.0 Device Authorization Grant to obtain refresh tokens directly through the IdP's token endpoint. An attacker never touches a session cookie, making DBSC irrelevant to this vector.
- Environments where DBSC hasn’t been deployed: As of mid-2026, DBSC has reached GA only in Chrome on Windows. macOS support is the announced next step; other browsers have not yet shipped it.
- Devices without secure hardware: Machines lacking a TPM or Secure Enclave fall back to standard cookie behavior, with no device binding, until software-based keys arrive.
- Primary Refresh Tokens (PRTs): Microsoft-specific credentials issued to Entra ID-joined devices that enable silent SSO across Microsoft services. PRTs are high-value targets for infostealers and device code phishing escalation; DBSC does not protect them.
- Kerberos Ticket-Granting Tickets (TGTs): The on-premises Active Directory equivalent of a PRT. Valid TGTs allow an attacker to request service tickets for any domain resource without the user's password. Infostealers harvest TGTs directly from memory.
- Browser-stored OAuth tokens: Access tokens and refresh tokens stored in browser local storage are harvested by infostealers in the same sweep as session cookies. DBSC says nothing about these.
- A live session abused by malware resident on the device: DBSC stops remote replay, not local abuse. An attacker with code execution on the device can use the authenticated session in place, or drive cookie refreshes through the browser while resident, because the proof-of-possession signing happens locally even though the key never leaves secure hardware. DBSC's real effect is converting "steal once, replay anywhere, anytime" into "maintain presence on the device," which is more detectable and time-bound.
- Native app and non-browser sessions: DBSC governs browser session cookies. Tokens held by desktop and mobile native apps, CLI tools, and thick clients sit outside it entirely.
The gaps DBSC leaves open: Refresh tokens and device code phishing
DBSC is designed to stop a specific attack: session cookie theft and replay. For that attack, it works. But modern identity-based threats extend well beyond session cookies, and two vectors in particular operate entirely outside DBSC’s authority.
The refresh token problem
In any modern enterprise identity environment, the refresh token is also a high-value theft target, not just the session cookie.
When a user authenticates through an identity provider like Microsoft Entra ID, Okta, or Google Workspace, the browser doesn’t just receive a session cookie. It receives an access token, an ID token, and a refresh token. The refresh token is the long-lived credential that silently generates new access tokens without requiring the user to log in again.
In most enterprise deployments:
- Microsoft Entra ID: Refresh tokens persist for 90 days by default
- Okta: Refresh token lifetime is configurable, with the validity window set by policy
- Google Workspace: Refresh tokens are essentially non-expiring unless explicitly revoked or inactive for 6 months
An attacker who obtains a valid refresh token – for example, through infostealer malware that exfiltrated browser-stored auth data, or from a successful AiTM phish – maintains silent access even through a password reset and MFA re-enrollment. DBSC has no authority here because the refresh token is not a session cookie. It lives in browser storage or a server-side cache, outside the browser session lifecycle that DBSC governs.
Device code phishing
Device code phishing has emerged as one of the most effective MFA-bypass techniques in the attacker’s toolkit, and it was never something DBSC was designed to address.
The attack abuses a legitimate OAuth 2.0 flow called the Device Authorization Grant, originally designed for input-limited devices like smart TVs.
- The attacker sends an unauthenticated request to the identity provider's device authorization endpoint, requesting the offline_access scope – which signals the server to issue a refresh token on authentication.
- The server returns a short user code. The attacker sends it to the target through social engineering, directing them to a legitimate URL (like microsoft.com/devicelogin). Because the URL is real, the target completes their normal login and MFA steps without suspicion.
- While the target is logging in, the attacker's system is polling the token endpoint.
- The moment authentication completes, the server delivers an access token (typically valid 60–90 minutes) and a refresh token (valid up to 90 days) directly to the attacker's machine. No session cookie was involved at any point, and the process took place entirely within the legitimate M365 ecosystem.
- With the refresh token, the attacker maintains silent access. In advanced scenarios, they can use it to register a rogue device in the tenant, potentially even acquiring a Primary Refresh Token (PRT) that provides SSO access across the entire organization.
An attacker who knows a target has deployed DBSC can simply pivot to this method, which doesn’t involve a session cookie at all. Note that while other providers support RFC 8628-compliant device code flows, Microsoft’s Device Code Grant is the one currently being abused at scale by PhaaS kits.
SpyCloud’s phishing and infostealer telemetry covers both vectors. When refresh tokens obtained through device code phishing surface in recaptured criminal infrastructure, SpyCloud surfaces them to defenders, providing the detection and automated remediation layer that corresponds to this type of attack.
What you can do today to prevent session hijacking
DBSC’s general availability in Chrome on Windows is a positive step. But as the sections above make clear, it addresses one layer of a multi-layered identity threat landscape.
Here’s what security teams should be doing today, regardless of DBSC deployment status:
Prioritize refresh token visibility and remediation.
Refresh tokens are a highest-value theft target in any OIDC environment, and they’re invisible to most security stacks until an attacker uses them. SpyCloud surfaces stolen refresh tokens and infostealer-exfiltrated auth data from criminal infrastructure, enabling automated remediation before attackers can act. For Okta and Microsoft Entra ID environments, SpyCloud’s Identity Guardian integrations automate session revocation and re-authentication signals directly through the IdP’s API.
Close the device code phishing gap.
Don't assume the IdP handles everything.
Treat the device as the attack surface.
DBSC protects session cookies. It does not protect the PRTs, Kerberos TGTs, browser-stored OAuth tokens, and saved credentials that infostealers can harvest in the same pass. SpyCloud’s infostealer telemetry is the signal layer that corresponds to device-level compromise, surfacing all artifact classes that infostealers target, not just cookies.
Implement layered session hijacking prevention.
Get early warning for your users who are victims of phishing attacks and infostealer malware – before criminals can leverage stolen cookies to access their accounts.
FAQs about Chrome DBSC session protection
Not yet. DBSC is generally available in Chrome on Windows as of Chrome 146 (April 2026), with macOS support using the Secure Enclave rolling out next. Mobile browser support hasn’t been announced. Google’s published roadmap also includes software-based keys for devices without secure hardware, which would eventually extend protection beyond machines with a TPM or Secure Enclave.
Yes. DBSC stops a stolen cookie from being replayed on a different machine, because the binding key never leaves the device’s secure hardware. It does nothing about malware already running on that device. Local malware can use the live session in place, or steal authentication artifacts DBSC doesn’t cover, including refresh tokens, Primary Refresh Tokens (PRTs), and saved credentials.
It varies. Google has shipped it for its own services, and Workspace admins can already turn on session binding for Google sessions. Every other site has to build the server side itself: a registration header in the login flow and a refresh endpoint that validates key possession and renews the cookie. That’s a real development effort, so broad adoption across the web will likely take months to years.
No. DBSC binds a session to a device after authentication. It doesn’t stop a user from entering credentials on a phishing site, and it doesn’t stop an attacker who captures credentials from creating a new session on their own device. It closes one path, replaying a stolen cookie somewhere else, not the act of phishing itself.
It depends on how the site implements DBSC. If the server keeps a long-lived cookie alongside the short-lived bound one, the session falls back to that cookie and continues; if it doesn’t, Chrome sends the request with no cookie and the user has to sign in again. In practice the TPM more often gets busy or rate-limited, since it’s shared across system processes and excessive refreshes can hit its rate limits, which causes a temporary fallback rather than a hard logout. This is separate from a device that has no secure hardware to begin with, where Chrome falls back to standard session handling on its own without breaking the login flow.
Keep reading
