What Are Chrome Device Bound Session Credentials (DBSC) and How Do They Stop Cookie Theft

Google has made Chrome Device Bound Session Credentials (DBSC) generally available starting with Chrome 146 on Windows. The feature is now rolling out to all personal Google accounts and Google Workspace customers. DBSC cryptographically ties your active browser sessions to your device hardware, so even if malware steals your session cookies, those cookies expire quickly and cannot be renewed without physical access to your machine.

This article explains what DBSC is, how the protection works, what it means for regular users, and what web developers need to implement it.

What Is Session Cookie Theft?

When you log into a website, the site stores a session cookie in your browser. That cookie tells the site you are already authenticated so you do not need to re-enter your password on every page load. Attackers exploit this by deploying infostealer malware such as LummaC2 and Rhadamanthys, which silently copy session cookies from browser storage and transmit them to attacker-controlled servers.

Because session cookies often stay valid for days or weeks, an attacker can use them to access your accounts long after the theft. They bypass multi-factor authentication (MFA) entirely because the site already treats the session as valid. In the past, threat actors also abused the undocumented Google OAuth MultiLogin API endpoint to generate new authentication cookies even after stolen ones expired.

Malicious browser extensions have also served as a major delivery channel for this type of credential harvesting at scale.

The core problem is that browsers store cookies in local files and memory. Once malware gains access to a device, no software-only solution can reliably prevent exfiltration. Historically, the only defense was reactive: sites detected abuse after the fact using behavioral heuristics that determined attackers could often work around.

DBSC replaces that reactive approach with proactive prevention.

What Are Chrome Device Bound Session Credentials (DBSC)?

Chrome Device Bound Session Credentials (DBSC) is a security protocol that cryptographically binds your browser session to your specific device using hardware-backed keys. Instead of relying on long-lived cookies that remain valid indefinitely wherever they are used, DBSC ties session renewal to a private key that cannot leave your device.

Google first announced DBSC in 2024, entered beta in April 2025, and is now rolling out general availability in Chrome 146. Google developed the protocol as an open web standard through the W3C Web Application Security Working Group, with active design input from Microsoft and participation from companies such as Okta during Origin Trials.

How Chrome DBSC Works

DBSC uses the secure hardware built into modern devices. On Windows it uses the Trusted Platform Module (TPM). On macOS it uses the Secure Enclave. Here is the complete session flow:

1. You log into a site that supports DBSC.
2. Chrome generates a public/private key pair. The private key is stored inside the secure hardware chip and cannot be exported or read by software.
3. Chrome sends the public key to the site’s session registration endpoint.
4. The site replaces the standard long-lived cookie with a short-lived cookie, typically expiring in 10 minutes.
5. When the short-lived cookie expires, Chrome must cryptographically prove possession of the private key to receive a new one.
6. If Chrome cannot prove possession, the session ends.

Because the private key never leaves the hardware, an attacker who steals the session cookie from your device cannot renew it anywhere else. The stolen cookie expires within minutes and becomes worthless.

If your device lacks a TPM or Secure Enclave, Chrome falls back to standard cookie behavior without disrupting your login flow. Future updates plan to add software-based keys to extend DBSC protection to devices without dedicated secure hardware.

How DBSC Protects Regular Users Without Any Setup

You do not need to configure anything. DBSC runs entirely in the background. Chrome handles key generation, cookie rotation, and proof-of-possession automatically.

Google has already enabled DBSC by default for all Google Workspace customers, Workspace Individual subscribers, and personal Google account users. Workspace administrators cannot disable it at the organizational level. Google reports a significant reduction in session theft for DBSC-protected sessions since early rollout began.

DBSC is a complement to existing Chrome security layers, not a replacement. Browser errors such as NET::ERR_CERT_AUTHORITY_INVALID and connection issues like ERR_SSL_PROTOCOL_ERROR are separate problems that DBSC does not address. Keeping Chrome updated and using Enhanced Safe Browsing remains important alongside DBSC.

How Developers Can Add DBSC Support to Their Web Apps

DBSC requires targeted backend changes. The front end requires no changes. Chrome handles all cryptographic operations transparently.

You need to implement three additions:

1. Modify your login response

After a successful login, include a Secure-Session-Registration header alongside your long-lived cookie:

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

If the device supports secure key storage, Chrome contacts your /StartSession endpoint with a public key in a JWT.

2. Add a session registration endpoint

At /StartSession, your server associates the received public key with the user’s session, responds with a session configuration JSON, and replaces the long-lived cookie with a short-lived one:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

The session configuration JSON specifies the session identifier, the refresh URL, and the cookie scope.

3. Add a refresh endpoint

When the short-lived cookie expires, Chrome pauses the outgoing request and hits your refresh endpoint:

• Chrome sends a POST to /RefreshEndpoint with a Sec-Secure-Session-Id header.
• Your server responds with 403 Forbidden and a Secure-Session-Challenge header.
• Chrome signs the challenge using the stored private key and retries with a Secure-Session-Response JWT proof.
• Your server validates the signed proof and issues a new short-lived cookie.
• Chrome resumes the original deferred request.

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

Implementation notes

• DBSC only applies to HTTPS pages.
• DBSC does not support Partitioned cookies.
• For resilience, pair the short-lived DBSC cookie with a long-lived cookie used only for issuing new short-lived tokens. This handles edge cases such as TPM busy errors or unreachable refresh endpoints without locking users out.
• Most existing endpoints require no changes. DBSC is additive and non-disruptive.

For full implementation details, refer to the Chrome DBSC developer guide.

Privacy and DBSC

DBSC preserves user privacy by design. Each session uses a distinct hardware key. Websites cannot use these keys to correlate a user’s activity across different sessions or sites on the same device. The protocol transmits no device identifiers or attestation data to the server beyond the per-session public key needed to verify proof of possession. This minimal exchange secures sessions without enabling cross-site tracking or device fingerprinting.

Current Availability

DBSC is now generally available for:

• All personal Google account users
• Google Workspace customers (enabled by default, cannot be disabled by admins)
• Google Workspace Individual subscribers
• Windows users on Chrome 146 (macOS support coming in an upcoming Chrome release)

For the full announcement, see the official Google Security blog post.

DBSC is not a complete solution if malware is already active on your device during the initial session registration. If malware intercepts the key generation step, it may be able to extract the private key at that moment. This requires significantly more sophistication than standard cookie theft and involves modifying TPM drivers, making it far more detectable.

Chrome also skips DBSC and falls back to the long-lived cookie in these specific scenarios:

• The refresh endpoint is unreachable due to network or server errors
• The TPM is busy or hits its rate limit from excessive refresh requests
• The DBSC-managed cookie is a third-party cookie and the user has blocked third-party cookies

If no long-lived fallback cookie is present, Chrome sends the request without a session cookie in these fallback cases.

DBSC also does not protect against all browser-level exploits. Google continues to address critical vulnerabilities through emergency patches, as seen with Google Patches Chrome Zero-Day Vulnerability CVE-2026-2441 Exploited in Active Attacks. DBSC adds a proactive hardware-level layer on top of those reactive patches.

Frequently Asked Questions

Related Browser Security & Error Fixes

• GhostPoster Browser Extensions Hit 840,000 Installs Across Chrome, Firefox, and Edge
• Google Patches Chrome Zero-Day Vulnerability CVE-2026-2441 Exploited in Active Attacks
• How to Fix NET::ERR_CERT_AUTHORITY_INVALID Error in Chrome, Edge, and Firefox