"We enforce complex passwords and require everyone to set up two-factor authentication. Yet, late at night, a login from overseas was recorded on an employee's Google account."—We received this inquiry from someone managing IT alongside other duties at a company of about thirty employees. An investigation revealed no sign of a leaked password. The employee never received or approved any secondary authentication prompts either. Even so, someone had accessed the account in an authenticated state.
This technique is known as "session hijacking," and passwords are not what is being stolen. What attackers are stealing is the "session cookie" itself, which proves the user is already logged in. That is why changing your password or enabling two-factor authentication still allows them right through. It is intuitively one of the hardest types of security incidents to accept. In response to this attack vector, a new defense called DBSC has begun rolling out by default on Chrome (Windows). Here is a breakdown from an administrator's perspective of what it protects and where its limits lie.
Why Passwords and Two-Factor Authentication Can Be Bypassed
Think back to how logging in works. When you enter your password and verify your identity through two-factor authentication, your browser is issued a pass stating, "This user is already logged in." That pass is your session cookie. For a while afterward, having this pass allows you to use the service without being asked for passwords or additional confirmation. That is the source of its convenience.
The problem is that this pass works simply by possessing it. Information-stealing malware (infostealers) that infiltrates a device does not crack passwords; instead, it extracts this cookie as is and sends it to the attacker's server. The attacker simply loads the stolen cookie into their own browser to recreate the authenticated state entirely. Even without knowing your password or passing two-factor authentication, having the pass is enough to get in.
The scale is not small either. Aggregated data from various security firms shows that the circulation of stolen credential packages surged by 70% year over year in 2025. Many of these packages are reported to contain live session cookies that bypass two-factor authentication entirely (SpyCloud: DBSC and Session Hijacking, Help Net Security). The assumption that "we have two-factor authentication, so we are safe" collapses right here. If your authentication fundamentals are not yet solid, reviewing our article on account hijacking, passkeys, and two-factor authentication first will help connect the dots moving forward.
DBSC Binds the Pass to the Device
That is where DBSC (Device Bound Session Credentials) comes in. The concept is simple: bind the pass so that it can only be used on that specific device. The idea is to make possession alone insufficient for access.
Here is how it works. Upon login, the browser generates a key pair (a public key and a private key) within the device. In Chrome (Windows), this private key is stored inside the PC's security chip (TPM), preventing it from being exported. Moving forward, maintaining the session requires periodically proving possession of that private key. Even if an attacker steals the cookie alone, the private key never leaves the device's chip, making it impossible to provide proof on another PC and rendering the stolen cookie unusable (Chrome for Developers: DBSC Available on Windows, Google: Cookie Protection via DBSC).
Looking at the differences from conventional cookies in a single overview makes the changes clear.
| Dimension | Conventional Session Cookies | Sessions Protected by DBSC |
|---|---|---|
| Post-theft handling | Usable if pasted into another device | Unusable on another device due to inability to prove private key |
| Authentication bypassed | Both passwords and two-factor authentication bypassed | Cookies alone will not pass |
| Admin setup work | ― | None required (enabled by default) |
Prerequisites for SMB Administrators
From an operational standpoint, the welcome news is that no setup is required on the administrator side to enable it. DBSC operates by default in Chrome (Windows) and cannot be disabled from the admin console. Google began a gradual rollout on May 25, 2026, which typically takes several dozen days to reach full deployment (Google Workspace Updates: DBSC Generally Available on Chrome for Windows). In other words, it is a defense that "starts working automatically." The trend of default changes taking effect under the hood aligns with what was covered in our article summarizing two-factor authentication and security default updates; the role of the IT team is shifting from "turning things on" to "keeping baseline assumptions up to date."
That said, because it activates automatically, administrators should verify certain prerequisites. DBSC is effective when Chrome is used for work and Windows TPM is enabled. Conversely, if employees sign in to corporate accounts using personal browsers or legacy devices, they fall outside this protection. Establishing visibility into "who is logging into corporate accounts from which devices and browsers" is the starting point. Incorporating device and access audits into your Google Workspace Security Configuration Checklist will help prevent oversights.
Do Not Misunderstand What DBSC Does Not Protect
Misunderstanding this can be dangerous, so let us be clear: DBSC is a mechanism that prevents the reuse of stolen cookies; it does not prevent the compromise of the device itself.
For instance, it is ineffective if malware running inside an infected device operates by impersonating a legitimate employee. Because the private key resides on that device, proof checks will succeed if abused locally. Likewise, this protection does not function in non-Chrome browsers or unsupported environments (Constella: What DBSC Cannot Prevent). While DBSC is a powerful countermeasure that shuts down the most common vector—stealing cookies to gain entry from elsewhere—it is essential to understand that it does not replace core fundamentals like endpoint infection countermeasures, vigilance regarding suspicious apps and links, and offboarding access revocation.
First, Verify Your Entry Points
DBSC is one of the rare "tailwinds" that takes effect without requiring administrative action. For that very reason, it is worthwhile to verify whether your environment can fully capitalize on this tailwind—such as standardizing work on Chrome, keeping devices updated, and ensuring corporate accounts are not accessed from outside personal devices. In your next IT team meeting, start by listing which devices and browsers your employees use to access corporate accounts. That will be the first step toward making this defense work for your organization.
Whether you want to audit your Google Workspace security settings against modern threats or have a third party inspect your device and access posture, feel free to reach out via GleamHub's free IT and Google Workspace consultation. We help establish security in a sensible sequence suited for teams without dedicated IT staff. Inquiries can be made via Contact Us.
Sources
- Device Bound Session Credentials now available on Windows — Chrome for Developers
- Prevent account takeovers with DBSC, now generally available in Chrome for Windows — Google Workspace Updates
- Protecting Cookies with Device Bound Session Credentials — Google
- What You Need to Know About Google Chrome DBSC — SpyCloud
- To counter cookie theft, Chrome ships device-bound session credentials — Help Net Security
- Google Just Fixed Session Cookie Theft in Chrome. Here Is What It Cannot Stop — Constella
