Device Bound Session Credentials: The Answer to Session Theft

A session cookie is a bearer token. Whoever holds it is you. That single property is why stealing a cookie has become more attractive than stealing a password: the cookie sits on the far side of your MFA, and it replays from anywhere.

SpyCloud's 2026 exposure report counted 8.6 billion stolen cookies and session artifacts recaptured from a single year of infostealer activity, alongside 13.2 million malware infections. Passwords are not the growth market. Sessions are.

Device Bound Session Credentials is the structural answer. Chrome shipped it to stable in version 146, Google turned it on by default across Workspace and consumer accounts, and the specification is now a W3C Working Draft in the Web Application Security Working Group. It is the first mainstream mechanism that makes a stolen cookie inert on the thief's machine.

What DBSC actually does

DBSC binds a browser session to a private key held in device hardware, then makes the cookie short-lived so the binding gets exercised constantly. The flow has four steps.

1. Registration. The login response carries a Secure-Session-Registration header naming the acceptable algorithms (ES256 or RS256) and a registration endpoint. Chrome generates a key pair and posts the public key to that endpoint as a signed JWT.
2. Key storage. The private key goes into a Trusted Platform Module where one is available, and into the Secure Enclave on the macOS builds that follow. It is not exportable. Malware running as the user cannot copy it out.
3. A deliberately short cookie. The server stops issuing a long-lived session cookie and issues a short one instead. Google's own documentation uses Max-Age=600, ten minutes.
4. Proof-of-possession refresh. When the cookie expires, Chrome pauses the request, calls the refresh endpoint with Sec-Secure-Session-Id, receives a Secure-Session-Challenge, signs it with the hardware key, and returns the signature in Secure-Session-Response. A new short cookie is issued and the request continues.

The security property falls out of step four. An attacker who exfiltrates the cookie gets at most ten minutes of access, and cannot renew it, because renewal requires a key that never left the victim's machine. The theft is not prevented. The value of the theft collapses.

An honest read on the threat

Vendor marketing will tell you session theft is the dominant attack. Microsoft's data says something more useful. The 2025 Digital Defense Report found that more than 97 percent of identity attacks are password spray and brute force, while token theft by malware accounts for 2.4 percent of attempts and adversary-in-the-middle for 0.003 percent.

Read those numbers correctly. They measure attempts, not outcomes. Password spray is loud, cheap, and mostly absorbed by MFA. Session theft is the technique that survives MFA, which is why it appears in the incidents that actually cost money. DBSC is not a volume control. It is a control for the tail that gets through everything else.

That framing also tells you where it sits in a roadmap. If you have not deployed phishing-resistant authentication, do that first. If you have, and your remaining exposure is the token issued after a perfectly good passkey ceremony, DBSC is the next thing. It is the same gap I described in Pass-the-Passkey: the cryptography holds, and the session handed out afterward does not.

How it compares to what you already have

Four mechanisms address the same weakness from different layers. They are complements, not alternatives.

Mechanism	Binds	Layer	Status
DBSC	Browser session cookie to device hardware	Browser and web server	Chrome stable, W3C Working Draft
DPoP (RFC 9449)	OAuth access and refresh tokens to an application key	OAuth client and authorization server	Standard since 2023, uneven vendor support
mTLS-bound tokens (RFC 8705)	OAuth tokens to a client certificate	Transport	Mature, common in finance and machine-to-machine
Short lifetimes plus CAEP	Nothing. It shortens the window and revokes faster	Session policy	Widely available

The distinction worth holding onto: DPoP and mTLS constrain API tokens to a client, DBSC constrains the browser cookie to a machine. Most products need both, because the browser session and the API session are different objects with different theft paths. Our glossary entries on sender-constrained tokens and token binding cover the vocabulary; the mTLS guide covers the transport case.

Continuous evaluation remains the backstop. Binding reduces how often a stolen credential is useful. CAEP and shared signals reduce how long a compromised session survives once you know about it. Neither replaces the other, and sane token lifetimes sit underneath both.

The limits, stated plainly

DBSC is narrower than the headlines suggest, and the gaps are the part a buyer needs.

• It is Chromium-only today. Mozilla and WebKit have both filed standards positions with concerns, and neither has committed to implement. Apple's stated worry is that a hardware-bound, undeletable session could become a supercookie. Until that resolves, DBSC protects the share of your users on Chrome and Edge and nobody else.
• Platform coverage is still filling in. General availability landed on Windows first. macOS support using the Secure Enclave follows, and devices with no secure hardware fall back to an unbound session.
• It does not stop malware on the device. An attacker with code execution on the victim's machine can drive the live browser rather than exfiltrating the cookie. DBSC converts remote replay into local session riding, which is a real improvement and not a cure.
• It does not cover native apps or server-to-server calls. Those need DPoP or mTLS.
• It excludes third-party and partitioned cookies, and requires HTTPS throughout.
• It is work on your server. Two new endpoints, a key registry keyed to sessions, and a session model that tolerates a ten-minute cookie. A monolith with a database-backed session handles this easily. A system that treats a long-lived JWT as the session does not, which is one more argument for the opaque-token side of that debate.

What to ask your CIAM vendor now

Almost nobody should be hand-rolling DBSC. The question is whether the platform you already pay for will ship it, and on what timeline. Six questions to put in writing:

1. Do you have a published DBSC roadmap with a date, or an aspiration?
2. Can your hosted session endpoint issue a ten-minute cookie today without breaking your SDKs?
3. Do you support DPoP for access tokens, and on which grant types?
4. Do you support mTLS-bound tokens for confidential clients?
5. When a bound session fails to refresh, what event do we receive? Silence here is the answer that should worry you.
6. How does your session revocation interact with a bound session, and what is the measured time to effect?

Question five is the one that gets skipped. A binding failure is a security event and an availability event at once, and if it produces no signal you will meet it as a support ticket. That is the instrumentation argument from CIAM observability applied to a specific control.

Expect the answers to split by vendor age. The newer CIAM providers reshaping identity in 2026 tend to move on browser-platform features faster than the incumbents, because they have fewer legacy session contracts to honor. Ask anyway, and ask for a date.

What to do this quarter

A sequence that does not require DBSC to be finished:

1. Measure your session lifetimes as they actually are in production. Configured and observed values diverge once refresh logic is involved.
2. Shorten what you can, and make sure your refresh path works before you shorten anything further.
3. Turn on sender-constrained tokens where your stack already supports them. DPoP for public clients, mTLS for confidential ones.
4. Wire up revocation and measure its latency. A revocation you cannot time is a revocation you cannot trust.
5. Instrument session anomalies now. A session whose network path, device fingerprint, or geography changes mid-life is the signal DBSC would have made moot. Behavioral detection stays useful for every browser that does not speak the protocol, which is the case for adaptive authentication rather than against it.
6. Put DBSC support in your next renewal conversation. Roadmap commitments are cheaper to get before the signature.

Frequently asked questions

What are Device Bound Session Credentials?

A browser protocol that ties a web session to a private key stored in the device's secure hardware. The server issues short-lived cookies and refreshes them only when the browser proves possession of that key, so a cookie copied to another machine stops working within minutes.

Does DBSC prevent session hijacking?

It prevents remote replay of a stolen cookie, which is how most session hijacking monetizes. It does not stop an attacker who has code execution on the victim's device and can drive the browser in place. The realistic outcome is that cookie theft stops scaling.

Which browsers support DBSC?

Chrome shipped it to stable in version 146, starting on Windows, with macOS following via the Secure Enclave. Chromium-based browsers including Edge inherit the implementation. Firefox and Safari have filed standards positions raising complexity and privacy concerns, and neither has committed to ship.

How is DBSC different from DPoP?

DBSC binds the browser's session cookie to device hardware and is driven by the browser itself. DPoP binds OAuth access and refresh tokens to a key held by the application and is driven by the client code. They protect different credentials on different layers, and a product with both a web app and an API generally wants both.

What does a server need to implement for DBSC?

Two endpoints and a data change. You need a registration endpoint that accepts the browser's public key and binds it to a session. You need a refresh endpoint that issues a challenge and verifies the signature. And you need a session store that can live with cookies measured in minutes rather than weeks.

Is DBSC a privacy risk?

That is the objection on the record from other browser vendors. A hardware-bound session identifier that survives cookie clearing looks like persistent tracking, so the specification scopes credentials tightly to a site and excludes third-party cookies. Whether the mitigations satisfy Mozilla and Apple is still an open question, and it is the main thing gating cross-browser support.