Session cookie theft has been one of the most persistent and damaging attack vectors on the web. Infostealer malware, man-in-the-browser attacks, and compromised browser extensions have all made session hijacking disturbingly straightforward — even against users with strong passwords and multi-factor authentication enabled. Once an attacker has your session cookie, they are you.
That is about to change. Google has shipped Device Bound Session Credentials (DBSC) as generally available in Chrome 146, and it fundamentally alters the economics of session theft. If your web application handles anything sensitive — authentication, payments, personal data — this is something your development team needs to understand right now.
TL;DR
- Device Bound Session Credentials (DBSC) cryptographically bind browser sessions to physical hardware using TPM chips or Secure Enclave, making stolen cookies useless on any other device.
- DBSC went GA on Chrome for Windows in May 2026 (Chrome 146), with macOS Secure Enclave support rolling out next.
- Sessions use short-lived cookies that Chrome automatically refreshes by proving possession of a hardware-bound private key — no developer-facing API changes required for basic protection.
- Cookie theft becomes economically unviable: attackers would need physical access to the device rather than simply exfiltrating a token.
- Web applications that integrate DBSC gain a significant security uplift against infostealers, session hijacking, and replay attacks — without degrading the user experience.
How DBSC Actually Works
The core concept is elegant. During authentication, Chrome generates a cryptographic key pair and stores the private key in the device’s hardware security module — the Trusted Platform Module (TPM) on Windows, or the Secure Enclave on macOS. The public key is registered with the server.
Sessions then use deliberately short-lived cookies. When a cookie expires, Chrome doesn’t simply send a refresh request — it proves possession of the private key through a cryptographic challenge before the server issues a new cookie. The private key never leaves the hardware. It cannot be exported, copied, or exfiltrated by malware.
The result? A stolen cookie is worthless. It expires within minutes, and the attacker cannot refresh it because they don’t have access to the TPM-bound private key on the victim’s device. Session hijacking goes from a software problem to a physical access problem — and physical access doesn’t scale.
Why This Matters More Than Passkeys
Passkeys solve the authentication problem — how you prove who you are at login. DBSC solves the session problem — how you stay authenticated after login. These are complementary, not competing, technologies.
Consider the attack chain: a user logs in with a passkey (excellent — phishing-resistant, no password to steal). But their session cookie is a bearer token. If an infostealer grabs that cookie from the browser’s cookie jar, the attacker can replay it from any device and bypass the passkey entirely. The authentication was secure; the session was not.
DBSC closes this gap. With hardware-bound sessions, even if malware manages to read the cookie value, it cannot refresh the session from another machine. The entire post-authentication attack surface shrinks dramatically.
What Development Teams Need to Do
The good news is that DBSC is designed to be largely transparent for basic use cases. Chrome handles the key generation, storage, and proof-of-possession automatically. But there are concrete steps your team should take to maximise the security benefit.
1. Adopt Short-Lived Session Cookies
DBSC’s security model depends on cookies expiring frequently. If your application sets session cookies with a 30-day expiry and no server-side validation, you’re not getting the full benefit. Move to short-lived cookies (minutes, not days) with server-side session management that validates the DBSC binding on each refresh.
2. Implement the DBSC Registration Flow
For full integration, your authentication endpoint needs to accept and store the public key that Chrome presents during session creation. The W3C DBSC specification defines the registration and refresh protocol. It’s straightforward HTTP — a Sec-Session-Registration header during login and a proof-of-possession challenge during cookie refresh.
3. Plan for Graceful Degradation
Not every browser supports DBSC yet, and not every device has a TPM. Your application needs to handle both DBSC-protected and traditional sessions. The practical approach is defence in depth: DBSC where available, combined with existing protections (IP binding, fingerprinting, anomaly detection) for browsers that don’t support it.
4. Review Your Session Architecture
If you’re still using long-lived JWTs stored in localStorage, DBSC won’t help you — it operates on cookies. This is another reason to reconsider your session architecture. Server-side sessions with short-lived, httpOnly, secure cookies are the pattern that benefits most from DBSC.
The Infostealer Economics Shift
The real impact of DBSC is economic. The infostealer ecosystem — Raccoon, RedLine, Vidar, and their successors — is built on the assumption that session cookies are portable. Steal the cookie, replay it elsewhere, access the account. Underground markets sell stolen session cookies in bulk precisely because they work from any device.
DBSC breaks this business model. A cookie bound to a specific TPM is worthless on the open market. Attackers would need to maintain persistent access to the victim’s device to use the session, which is orders of magnitude more expensive and detectable than simply exfiltrating a token.
This doesn’t eliminate all session attacks — on-device attackers who can invoke the TPM directly still pose a threat. But it raises the bar from “grab a file” to “maintain real-time device access,” which filters out the vast majority of commodity attacks.
The Cross-Origin Roadmap
Google has already published the next phase: cross-origin DBSC bindings for federated identity. Today, if you log into a relying party via Google or another identity provider, the IdP session and the RP session are independently bound. The roadmap aims to chain these bindings so that the relying party’s session inherits the device binding from the identity provider’s session.
For applications using social login or enterprise SSO, this means the entire authentication chain — from identity provider to your application — could be hardware-bound. Session theft at any point in the federation chain becomes impractical.
What About Firefox and Safari?
DBSC is currently a W3C draft specification, and Google is leading adoption. Firefox has expressed interest but hasn’t shipped an implementation yet. Safari’s position is less clear, though Apple’s investment in Secure Enclave and its privacy-first messaging suggest eventual support is likely.
For development teams, this means DBSC is a progressive enhancement, not a hard requirement. Implement it for Chrome users today, benefit from broader support as it lands in other browsers, and maintain your existing session security measures as a baseline.
Getting Started
If your team is building or maintaining a web application with authenticated sessions, DBSC should be on your security roadmap for Q3 2026. The integration effort is modest — primarily server-side changes to handle key registration and proof-of-possession during cookie refresh — and the security uplift against the most common session attacks is substantial.
At REPTILEHAUS, we’re already integrating DBSC support into client projects where session security is critical. If you’re unsure how DBSC fits into your existing authentication and session architecture, or you need help implementing it alongside passkeys and your current security stack, get in touch — our team specialises in building secure, production-ready web applications.
