Prevent cookie theft with session binding

Google Workspace automatically enhances the security of your users' online sessions by using Device Bound Session Credentials (DBSC). DBSC is designed to prevent session hijacking, also commonly known as cookie theft.

This type of cyberattack occurs when an unauthorized party gains control of a user's active web session by stealing the session cookie—often through malware on the user's device. A session cookie is a small data file containing the unique session identifier issued by the website during sign-in. By presenting this stolen cookie, the attacker can impersonate the legitimate user and continue their authenticated session.

DBSC works by binding a user's session to their specific device, making it difficult for attackers to use stolen cookies on other devices. This creates a hardware-based security boundary that reduces the risk of unauthorized access to user accounts and keeps sensitive data safe. DBSC is on by default for all Workspace accounts. No administrator action is needed to activate this protection.

Requirements for using DBSC

  • Chrome browser: Version 146 or later for Windows and version 148 or later for macOS. For details, go to Update Google Chrome.
  • Hardware security: Requires hardware-based security features to securely store the cryptographic keys used to bind the session to the device. For Windows, this is a Trusted Platform Module (TPM), which is standard on most devices running Windows 11. For macOS, this is a Secure Enclave (available on most recent Mac laptops). Consult your device manufacturer's documentation to confirm hardware capabilities.

How DBSC protection is applied

DBSC protection is applied automatically when a user's device and browser meet the necessary technical requirements. In some cases, sessions may remain unbound. Common reasons include:

  • Unsupported environment—Issues with the user's operating system, browser version, or hardware security (such as a TPM on Windows).
  • Existing sessions—DBSC protection applies only to new sessions. Users who were already signed in when DBSC was turned on must sign out and sign in again to bind their session.
  • Browser modifications—Certain browser extensions or manual changes to cookies can prevent DBSC from working correctly.

Enforce DBSC with Context-Aware Access

Limited to desktop web apps and not applicable for mobile apps or APIs

You can further enhance security by requiring users to have DBSC to access specific Google Workspace apps. When you enforce DBSC, users are prompted to sign in again if the system detects a difference with a previously established bound session. This reauthentication allows the system to attempt a new, secure binding. Users on unsupported platforms are blocked from accessing the protected app. This security measure is configured through Context-Aware Access.

To set up DBSC enforcement:

  1. Follow the instructions to create a custom access level in Allow access to apps only from DBSC-bound sessions.
  2. Assign the access level to the apps you want to be accessed only by DBSC-bounded sessions in monitor mode to simulate enforcement without blocking user access.
  3. After assessing the impact, assign access levels in active mode to enforce access only by DBSC-bound sessions. For details, go to Deploy Context-Aware Access.

DBSC enforcement is not immediate, which means that after a user signs in, there is a grace period before enforcement is applied. This design accommodates potential temporary binding issues. Once bound, the system periodically checks if users accessing the specified apps have DBSC-bound sessions. Any reauthentication will reset this grace period, and DBSC will not be enforced during that reauthentication.

Investigate DBSC protection & session issues

You can use the security investigation tool to monitor DBSC protection and troubleshoot session interruptions. There are 2 log sources for DBSC activity:

  • User log events—Monitor the binding of access tokens to user devices.
  • Access Evaluation log events—Review the status of specific cookies.

Note: DBSC log events are only visible for the primary account when multiple user accounts are signed in to the same Chrome browser profile.

Step 1: Search for DBSC activity in User log events

Use this data source to see if DBSC is successfully binding keys to user devices and validating sessions.

To check if DBSC is binding keys:

  1. In the Google Admin console, go to Menu and then Security and then Security center and then Investigation tool.

    Requires having the Security center administrator privilege.

  2. For Data source, select User log events.
  3. Click Add Condition.
  4. For Attribute, select Eventand thenIs as the operatorand thenDBSC key binding as the event.
  5. Click Search.
  6. In the results table, review the Event status column:
    • Succeeded—DBSC protection is turned on for the user, and the session is protected.
    • Failed—DBSC binding failed, and protection is not turned on for the user.
    • No results—DBSC protection was not attempted for this user session.

To check if DBSC is validating sessions:

  1. In the Google Admin console, go to Menu and then Security and then Security center and then Investigation tool.

    Requires having the Security center administrator privilege.

  2. Click Add Condition.
  3. For Attribute, select Eventand thenIs as the operatorand thenDBSC key validation as the event.
  4. Click Search.
  5. In the results table, review the Event status column:
    • Succeeded—The cookie was successfully validated.
    • Failed—DBSC validation failed. Click the status to get additional information, such as an error code.

One failure does not necessarily mean the user is experiencing session interruptions. Users might get interruptions if multiple validation failures occur in succession.

Step 2: Check for access denials in Access Evaluation log events

Use this data source to see if a user's cookie was denied access.

  1. In the Google Admin console, go to Menu and then Security and then Security center and then Investigation tool.

    Requires having the Security center administrator privilege.

  2. For Data source, select Access Evaluation log events.
  3. Click Add Condition.
  4. For Attribute, select Eventand thenIs as the operatorand thenDeny Cookie Validation Request as the event.
  5. Click Search.
  6. In the results table, click Denied in the Event status column or the link in the Description column to open a side panel where you can review the following failure reasons:
    • DBSC_BOUND_COOKIE_MISSING
    • DBSC_BOUND_COOKIE_CORRUPTED
    • DBSC_BOUND_COOKIE_EXPIRED

Log events are grouped by session. To manage log volume, only one event is recorded per hour for each unique session and failure type. Any other attempts with the same details are not recorded during that hour.

Step 3: Investigate if session interruptions are caused by DBSC

Users can be signed out for various reasons, such as session length limits, administrator-defined policies, or network issues. While a sign-out does not always indicate a DBSC issue, specific log sequences can help identify potential DBSC-related activity or instances where the system blocked a compromised session.

Use these points to help identify DBSC-related activity:

  • Review log sequences—If you find DBSC key validation failures followed by a Deny Cookie Validation Request, DBSC could be the cause of the user's sign-out.
  • Understand the impact on the user—To keep the account safe, a user needs to sign in again if the binding process encounters an error.


Google, Google Workspace, and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.