How Chrome 146's DBSC uses TPM to neutralize session cookie theft

Infostealers siphoning session cookies and selling them on dark markets has been a persistent weak spot in web security for years. Change your password, enable MFA — none of it matters if the attacker has a valid session cookie. Device Bound Session Credentials (DBSC), Google’s hardware-level answer to this problem, has finally shipped to all Windows users in Chrome 146.

Why session cookie theft is so hard to stop

A browser session cookie is essentially the authentication token itself. Issued by the server after login, it’s automatically attached to subsequent requests to maintain the “logged in” state. The problem: these cookies sit in files and memory in practically plaintext form.

Infostealers like LummaC2 read cookies from local files and memory on compromised devices, then exfiltrate them to attacker-controlled servers. The attacker just sets the stolen cookie in their own browser and they’re logged into the victim’s account — no password needed. If the cookie has a long expiry, access persists for weeks or even months.

Google themselves have stated that “there is no pure software solution that can fully prevent cookie theft from malware with OS-level access.” If software alone can’t protect cookies, hardware has to step in.

How DBSC works

The core idea behind DBSC is straightforward: bind the session to the device’s hardware. A private key stored in the TPM (Trusted Platform Module) must continuously prove session ownership, or the cookie won’t be refreshed.

sequenceDiagram
    participant Browser as Chrome
    participant TPM as TPM<br/>(Private key storage)
    participant Server as Web Server

    Browser->>Server: Login authentication
    Server->>Browser: Secure-Session-Registration header<br/>+ long-lived cookie
    Browser->>TPM: Request key pair generation
    TPM->>Browser: Return public key<br/>(private key stays in TPM)
    Browser->>Server: Send public key via JWT<br/>(registration endpoint)
    Server->>Browser: Session configuration<br/>+ short-lived cookie (10 min)

    Note over Browser,Server: 10 minutes later, cookie expires

    Browser->>Server: Refresh request<br/>Sec-Secure-Session-Id
    Server->>Browser: Send challenge<br/>Secure-Session-Challenge
    Browser->>TPM: Request challenge signature
    TPM->>Browser: Return signed JWT
    Browser->>Server: Send signed JWT<br/>Secure-Session-Response
    Server->>Browser: Issue new short-lived cookie

Breaking down the flow:

1. Registration phase

When the user logs in, the server includes a Secure-Session-Registration header in the response. Chrome has the TPM generate a public/private key pair, with the private key locked inside the TPM. The public key is sent to the server’s registration endpoint in a JWT (JSON Web Token). The server replaces the long-lived cookie with a short-lived cookie (typically around 10 minutes) and returns the DBSC session configuration.

2. Refresh phase

When the short-lived cookie expires, Chrome sends a request to the server’s refresh endpoint. The server returns a challenge value. Chrome signs the challenge with the TPM’s private key and sends it back. The server verifies the signature and, if valid, issues a new short-lived cookie.

3. From the attacker’s perspective

Even if an infostealer exfiltrates the cookie, it expires in at most 10 minutes. Refreshing requires the private key inside the TPM, but TPM private keys are not exportable by hardware design. An attacker attempting a refresh from a different device fails ownership proof and gets rejected.

What is TPM?

TPM (Trusted Platform Module) is a dedicated security chip that handles cryptographic key generation, storage, and signing at the hardware level. Since Windows 11 requires TPM 2.0, virtually all current Windows PCs have one.

In the DBSC context, the TPM acts as an inescapable vault for the private key. A private key generated inside the TPM never leaves the chip — even OS-level malware cannot read the key itself. Signing operations complete entirely within the TPM; only the signature result is returned externally.

On macOS, Chrome will use Secure Enclave instead of TPM for the same role, though the macOS rollout timeline has not been announced yet.

On devices without a TPM, or when the TPM’s signing pipeline is busy, DBSC gracefully falls back to traditional long-lived cookies. Security is reduced, but the site doesn’t break.

HTTP header details

DBSC has been standardized through the W3C Web Application Security Working Group. Here are the HTTP headers used by the protocol:

Header	Direction	Purpose
Secure-Session-Registration	Response	Initiate DBSC registration. Communicate supported algorithms and registration endpoint
Secure-Session-Challenge	Response	Send challenge value during refresh
Secure-Session-Response	Request	Send signed JWT (DBSC proof) in response to challenge
Sec-Secure-Session-Id	Request	Specify the session ID to refresh

Supported signing algorithms are ES256 (ECDSA + SHA-256) and RS256 (RSA + SHA-256). The JWT header specifies "typ": "dbsc+jwt", and the payload includes the challenge value (jti), the refresh URL as audience (aud), and the public key (jwk).

Server-side adoption

A common question about DBSC deployment is how much server-side work is involved. According to Google, no frontend code changes are needed — just add a registration endpoint and a refresh endpoint on the backend.

The server needs to implement:

1. Include the Secure-Session-Registration header in login responses
2. Accept a JWT at the registration endpoint, store the public key, and return session configuration (scope, protected cookies, refresh URL) as JSON
3. Issue challenges at the refresh endpoint, verify signatures, and issue new short-lived cookies
4. Use a dual-cookie approach combining long-lived and short-lived cookies, so basic session continuity is maintained even if DBSC temporarily fails

Google has already run joint tests with Okta and operated an earlier version on its own services for over a year. The result: “a measurable decrease in session theft since deployment began.”

Privacy design

Security features turning into tracking tools has happened before. DBSC deliberately includes privacy constraints to prevent this.

Each session generates a different key pair, so a site cannot use keys to correlate a user across sessions. Cross-site correlation is also impossible. Only a session-specific public key is sent to the server — no device identifiers or attestation data are shared. Abusing DBSC for fingerprinting is impossible by protocol design.

Limitations and roadmap

Current DBSC limitations:

• Windows Chrome 146 only. macOS support is planned but no timeline has been announced
• HTTPS pages only
• Not compatible with Partitioned cookies (coexistence with Privacy Sandbox partitioning is still pending)
• Does not work in environments that block third-party cookies
• TPM throughput has limits; system-wide spikes in TPM signing requests can cause latency

DBSC went from origin trial in Chrome 135 to general availability in about a year. Google is now working on expanding DBSC’s scope:

• Federated identity support — When logging in via an SSO identity provider, the relying party’s session is also bound to the same device key, protecting the entire authentication chain
• Extended registration — Binding DBSC sessions to existing trusted key material such as mTLS certificates and hardware security keys
• Software-based key support — Making DBSC available on devices without TPM or Secure Enclave using software keys. Security is weaker, but coverage is prioritized

Chrome 146 has also seen a string of security updates including the Dawn (WebGPU) zero-day CVE-2026-5281 and two Skia and V8 zero-days. Unlike those vulnerability patches, DBSC goes after the infostealer business model itself — making stolen session cookies worthless.