Despite setting up two-factor authentication and passkeys, reports of accounts being hijacked keep coming in. Behind this lies a technique that targets not the password itself, but the "session cookie" issued after login. Attackers don't break the authentication—they steal the entire authenticated state. Device Bound Session Credentials (DBSC), which Google Chrome began rolling out for Windows starting April 2026 and which reportedly expanded to macOS in August, is a technology designed to render stolen cookies alone unusable. However, the conditions under which it protects users are limited.
Cookies Can Be Stolen, But Signatures Cannot: Where DBSC Hides the Key
At the moment of login, the browser generates a public-private key pair on the spot. The private key is stored in the TPM (Trusted Platform Module—a security feature built into PCs, sometimes implemented as a discrete chip and other times as fTPM built into the CPU) on Windows, or in a dedicated isolated area called the Secure Enclave on macOS, and cannot be extracted by either the OS or any application. This is the decisive difference from conventional cookie-theft countermeasures. However, Chrome's developer documentation notes that if malware was running on the device at the exact moment a session was registered, key extraction cannot be completely ruled out.
The cookies that maintain a session are themselves designed to expire quickly. Every time one expires, Chrome sends proof signed with the private key to a refresh endpoint to obtain a new cookie. Even if malware steals the entire cookie file from a browser profile, it cannot produce this signature—because the private key remains locked inside the hardware.
For this exchange to function, browser-side support alone is not enough. The web service implementing it must also support the refresh endpoint. Google has built this mechanism into its own services, but whether other web services adopt the same mechanism depends on each provider's own implementation plans.
Scott Helme, founder of Report URI, explains the core of this mechanism as follows: "Attackers cannot steal the private key from the device" and "even if they steal the cookie, they cannot sign a response to the DBSC challenge using the private key stored on the device." What this points to is that DBSC's defensive strength rests not on complex cryptographic theory, but on the simple principle of never letting the private key leave the device physically. The challenge-response scheme based on public-key cryptography is nothing new in itself. Passkeys replaced the login-time authentication step with this scheme, while DBSC brings the same idea to maintaining sessions after login. The difference is that the scope of protection has expanded from "the entrance" to "the time after entering."
Keeping cookie lifetimes short has long been one defensive measure. But if reissuing an expired cookie relies on the human act of logging in again, convenience suffers. DBSC replaces that reissuance with automatic signing via the private key, raising security without sacrificing user experience.
What Attackers Targeted Instead of the Entrance Passkeys Had Locked Down: The Session Itself
Phishing aimed at stealing passwords is said to have become harder to pull off as two-factor authentication and passkeys spread. Attackers next turned to stealing the authenticated state itself, rather than breaking through authentication. Information-stealing malware known as infostealers, along with AiTM (Adversary-in-the-Middle, a man-in-the-middle style of phishing), extract session cookies stored in browsers wholesale, allowing intruders to enter logged-in accounts without going through passwords or two-factor authentication. AiTM inserts an attacker's server between the user and the genuine login page, relaying traffic while intercepting the exchange of passwords and two-factor codes as-is. If the attacker duplicates in real time the session cookie generated the instant authentication completes, they can inherit the entire logged-in state without the trouble of defeating two-factor authentication.
According to research by threat intelligence firm Flashpoint, infostealers stole more than 1.8 billion credentials from 5.8 million devices in just the first half of 2025—an 800% increase since the start of the year. Verizon's 2025 Data Breach Investigations Report (DBIR) states that credential misuse accounts for 22% of initial access vectors in breach incidents, making it the single most common entry point.
Dividing these six-month figures per device makes the scale easier to grasp: 1.8 billion divided by 5.8 million works out to roughly 310 login credentials leaked per device on average. Counting up the SNS, e-commerce, banking, and work-application accounts tied to a single email address, that's a figure covering the bulk of the credentials a single device uses in daily life.
The cookies and login information infostealers steal are often resold as-is on dark web marketplaces. Buyers who use these resold sessions can enter accounts without the trouble of defeating passwords or two-factor authentication. Even when the origin of a breach is a single phishing email, the resale market causes the damage to spread on an entirely different order of magnitude. This is precisely the pathway DBSC targets. By designing the system so that even if the cookie file itself is stolen, that alone cannot produce the signature needed to continue a login, it blunts the primary tactic of infostealers.
Windows Rollout Began in April—How Far Has macOS Progressed?
According to Google's official blog (dated April 9, 2026), after going through Origin Trial (limited-release testing), DBSC rollout to Windows users began on Chrome 146, which reached stable release in March 2026. Since then, it has been distributed progressively to eligible devices via the browser's automatic update mechanism. An Origin Trial is a system for releasing a new feature to a limited set of developers and sites, gathering feedback from real-world use before broader rollout. Having gone through this trial period, DBSC has been elevated from an experimental browser-only feature to part of the everyday authentication foundation.
For the enterprise-focused Google Workspace, phased rollout began on May 25, 2026, with a design that expands default enablement to all customers—including free personal accounts—over as long as 60 days (Google Workspace Updates frames this rollout start as reaching general availability, or GA). No configuration action is required on the administrator's side. In large-scale tenants like Workspace, rolling out a feature to accounts worldwide all at once can cause server load and support demand to spike, so a phased rollout spread over several weeks is the standard approach.
Ars Technica (August 11, 2026) cites Chrome 147 (Windows) and 150 (macOS) as the versions carrying this feature, and reports that the rollout remains limited to a subset of users. This doesn't match the GA version for Windows (Chrome 146) that Google's official blog states explicitly. This discrepancy appears to reflect either a simple difference from a later patch version distributed after GA, or it may point to a limited additional rollout aimed at a subset of users, such as those on macOS. As of the time of the Ars article, Secure Enclave integration for macOS remained confined to a limited set of Chrome 150 users and had not reached the broad rollout seen on Windows.
Okta and Microsoft Entra Hold the Same Key—But It Isn't Free
The idea of protecting sessions with a device-bound key is not unique to Google. The identity platform Okta offers device-bound SSO (single sign-on) functionality, with a mechanism that evaluates sign-on policy and pins the session when accessed from a registered device (an Early Access feature as of August 2026). The direction of "a session that can't be used even if stolen" overlaps with DBSC.
Microsoft offers a similar defense through a feature called Token Protection in Entra ID (formerly Azure AD). Through Conditional Access policies, it pins sign-in tokens to a specific device—the same goal as DBSC, namely making a stolen token unusable on a different device. However, its scope is limited to Windows devices that are joined or registered with Entra, along with supported apps and resources, and the feature itself is available only to subscribers of the paid Entra ID P1 license.
Google has made the same underlying technical philosophy free and default-enabled for all users, including personal accounts, while Microsoft has placed it in a paid add-on menu aimed at enterprises. Even as the identity management industry as a whole converges on the same answer—a hardware-bound key—who gets free access to that answer differs by provider. The beneficiaries are vendors like Google, Okta, and Microsoft along with users on supported devices, while dark web markets reselling stolen cookies and infostealer operators are the ones shut out. However, as discussed below, users who continue using devices without TPM or third-party web services that don't support DBSC remain outside this benefit.
This Key Has a Blind Spot Too: The Limits W3C Itself Acknowledges, and the People Left Behind That the Sources Don't Mention
The spec README (published on GitHub) of the W3C Web Application Security Working Group, which is standardizing DBSC, spells out explicitly the range this technology cannot protect against. It states plainly that DBSC cannot prevent temporary session access while an attacker has already compromised a device and continues to operate that device's user agent. Taking remote-access malware that keeps running on an infected device as an example: since the private key never leaves the device, it cannot be stolen, but the attacker—having hijacked the authority to use the key on the device itself—can keep operating while impersonating a legitimate browser session. What DBSC prevents is theft of the kind where "only the cookie is taken and used from a different device"; it does not cover a situation where the device itself remains hijacked and continues to be used.
There's also a cutoff point for when protection begins. DBSC applies only to newly started sessions—users who were already signed in at the moment the feature was enabled will not have their session bound to a key until they sign out and sign back in. On devices left signed in without interruption, this protection may not yet be active.
Neither the Ars Technica article nor Google's official announcement dwells much on the fact that this protection presupposes specific hardware—the TPM or Secure Enclave. Older PCs that lack a TPM, or that have it disabled in the BIOS, fall outside DBSC's protection even after Chrome updates to a supported version. A line similar to the one Windows 11 draws with its TPM 2.0 requirement effectively reappears here.
The treatment of users on browsers other than Chrome also remains unresolved. DBSC is a feature implemented in the Chromium engine, and Firefox or Safari users remain exposed just as before, unless the services they use take separate measures on their own. DBSC is still at the stage of being standardized at the W3C and has not yet been finalized as a Recommendation. There's no official word yet on when Mozilla or Apple might follow suit.
What Workspace-Using Companies Should Do Next: Inventory Their Devices
For Japanese companies using Google Workspace, Windows DBSC is one of the rare security enhancements that delivers benefits without requiring any special setup work. Administrators don't need to toggle anything in the console—as long as eligible devices have a TPM and have updated to Chrome 146 or later, protection kicks in for newly started sessions. However, devices that were already signed in before the feature was enabled won't be covered until they sign out and sign back in.
If devices without TPM are mixed in among long-used laptops or BYOD devices, employees who are protected and employees who aren't will coexist on the same corporate network. Departments with longer refresh cycles are especially likely to still have TPM-less machines in circulation. The first thing IT departments should check, even before Workspace settings, is whether their device inventory even tracks TPM availability.
The same logic applies to web services a company operates itself. Even if the browser supports DBSC, nothing happens unless the service side implements the refresh endpoint. Companies that offer login functionality to external users would do well to check, at their next review, whether their own authentication infrastructure has a plan to support this mechanism. For environments outside Chrome and Workspace—employees who continue using Firefox or Safari, for instance—companies need to assume this protection doesn't reach them, and continue conventional measures such as thorough two-factor authentication in parallel.
Passkeys protect the moment of authentication; DBSC protects the time after login—both using keys pinned to the device. Only when the two are combined do we come close to a session that can't be breached, whether the attacker has stolen credentials or cookies. But outside that boundary—on devices without a TPM and on unsupported browsers—the same attack surface as before remains untouched.