Prevent cookie theft with session binding (beta)

As an administrator, you can enhance the security of your users' online sessions by implementing 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. By using DBSC, you can lower the risk of unauthorized access to user accounts, keeping sensitive user data safe.

Requirements for using DBSC

  • Chrome for Windows: Currently, DBSC is available only on Chrome browser for Windows devices.
  • Hardware security (TPM): The user's device must have a Trusted Platform Module (TPM), which is a standard hardware component that’s already available for most devices running Windows 11. This hardware securely stores the cryptographic keys used to bind the session to the device. Users can typically find information about TPM availability in their device's system settings or by consulting the device manufacturer's documentation.
  • Chrome version: The user must have Chrome version 136 or later. For details, go to Update Google Chrome.
  • Primary account: DBSC protection and log event data are available only for the primary account in a Chrome browser profile.

Note: Session binding protects most Google cookies, though some cookies or sessions may remain unbound.

Turn on DBSC

Before you begin: If needed, learn how to apply the setting to a department or group.

  1. In the Google Admin console, go to Menu and then Security and then Access and data control and then Google Session control.

    Requires having the Security Settings administrator privilege.

  2. (Optional) To apply the setting only to some users, at the side, select an organizational unit (often used for departments) or configuration group (advanced).

    Group settings override organizational units. Learn more

  3. For Device Bound Session Credentials, select Enable DBSC.
  4. Click Save. Or, you might click Override for an organizational unit.

    To later restore the inherited value, click Inherit (or Unset for a group).

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. Turn on DBSC for the users that you want to protect. For the steps, go to Turn on DBSC.
  2. Follow the instructions to create a custom access level in Allow access to apps only from DBSC-bound sessions.
  3. 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.
  4. 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.

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. Only one event is recorded per user every hour, even if multiple access attempts are blocked during that time.

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.
  • Exempt users from DBSC—If a user is consistently signed out, you can create a configuration group exempt from DBSC and add the user to that group to evaluate if DBSC is causing the sign-outs.


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.