Chrome's Device-Bound Sessions Take On Cookie

Here's a thing that doesn't get nearly enough attention: you can have a perfect password, two-factor authentication enabled, and a passkey set up — and still get locked out of your own account within hours of an attacker landing on your machine. That's the session cookie problem, and it's been quietly fueling an epidemic of account takeovers that most mainstream security advice completely sidesteps.

Chrome's answer, now rolling out broadly, is called Device Bound Session Credentials — DBSC, if you want the acronym. It's not the flashiest security announcement Google has ever made, but the people who track this stuff are calling it potentially the most effective browser-level protection against account takeovers to date. Ars Technica flagged it with that exact framing, and looking at how the technology actually works, it's hard to argue with the enthusiasm.

The cookie theft problem, explained without the jargon

When you log into a website, the site issues your browser a session cookie — essentially a "you're good, come on in" pass that lets you navigate the site without re-authenticating every five seconds. The cookie is temporary, but it's also portable. If someone swipes it, they can drop it into their own browser, and the website has no idea it's not you. Your password never got compromised. Your MFA never got triggered. But your account is gone.

This attack vector — sometimes called "pass-the-cookie" — is increasingly what attackers are actually going after. Malware designed to harvest session cookies from browser storage has become a cottage industry. TechRepublic notes that account takeovers via this method are "rising fast," and the threat isn't theoretical: it's the mechanism behind a meaningful chunk of real-world credential compromises hitting individuals and enterprises alike.

Standard MFA doesn't stop it. That's the uncomfortable part. Once the session is established and the cookie is issued, the second factor has already done its job. The attacker doesn't need to know your password or intercept your one-time code — they just need the cookie that proves you already authenticated.

What DBSC actually does

The core idea behind Device Bound Session Credentials is elegant in its simplicity: make the cookie useless without the device that created it.

According to Faz Business, once a website sets a session cookie under DBSC, the browser must send a version of that cookie signed with a cryptographic key stored in the device's hardware — specifically in the TPM (Trusted Platform Module) chip or a secure enclave, depending on the device. The key never leaves the silicon. It can't be exported, copied, or exfiltrated by malware the way a cookie file can. If an attacker steals the cookie but not the actual physical device, the signed handshake fails and the session is dead.

TechRepublic describes it as tying session cookies "to the specific device that logged in, making it harder for attackers to reuse stolen cookie files." Google calls it "enhanced post-authentication protection" — which is accurate, if slightly corporate in its understatement.

The Windows rollout is already live for general availability, according to Google Workspace Updates, which also notes that DBSC can be layered with context-aware access (CAA) for even more granular controls — relevant especially for enterprise environments where IT admins want to enforce device compliance policies at the session level, not just at login.

The hardware dependency question

Here's where it gets genuinely interesting from a policy and access standpoint: DBSC's strength is also its constraint. The protection relies on TPM chips or secure enclaves being present in the device. Newer Windows machines generally have TPM 2.0 (Microsoft made it a Windows 11 requirement), and modern Macs have the Apple T-series chips. But older hardware, budget devices, and certain configurations may not have the silicon DBSC needs to do its job.

This creates a tiered security landscape that the sources don't address head-on but that's worth sitting with. The people most likely to be running older, lower-spec hardware — often lower-income users, people in parts of the world where device refresh cycles are slower — may be the ones who don't get the full benefit of this protection. It's not a reason to dismiss DBSC; it's a reason to be honest about the fact that hardware-rooted security features distribute unevenly.

For enterprise users, the calculus is different. Organizations managing fleets of modern, standardized hardware will find DBSC a genuinely powerful tool, particularly when combined with the context-aware access layer that Google Workspace has built around it.

DBSC isn't the whole picture

It's worth being clear about what DBSC doesn't do. It's specifically an antidote to session cookie theft — the "after you've already logged in" attack surface. It doesn't protect against phishing attacks that capture credentials before a session is even established. It doesn't help if someone has your password and no session exists yet to steal.

Forbes makes this point implicitly in its account takeover coverage, where the recommendations still include using a standalone password manager, adding a passkey to your Google account, and using MFA that isn't SMS-based. ChromeThemer's Chrome identity protection guide covers similar ground — password leak alerts, passkey setup, anti-phishing settings — as a layered hygiene stack that DBSC sits on top of, not replaces.

The threat model for account takeovers in 2026 is multidimensional. Attackers aren't locked into one vector; they probe for whatever's weakest. DBSC closes a specific, increasingly exploited gap. The rest of the hygiene stack closes the others.

What this means for the browser ecosystem

Google controls roughly two-thirds of the global browser market, so when Chrome ships a security feature, it has real weight. But DBSC isn't a Chrome-proprietary fortress — Google has been developing it as an open web standard, and the long-term vision is for websites to be able to require DBSC across any supporting browser.

That matters a lot. A security feature that only works for Chrome users protects Chrome users. A security feature that becomes a web standard — that sites can opt into and enforce — starts to actually move the needle on the ecosystem-wide problem. The sources don't detail which other browsers are actively implementing DBSC, and that's a gap worth watching. If Firefox and Safari don't follow, the fragmentation creates its own risks.

The incentives seem aligned, at least in principle: session cookie theft is a problem for every browser, every platform, every user. The question is how fast the rest of the ecosystem moves, and whether the open standard track gains the momentum it needs to make DBSC protection genuinely universal rather than Chrome-exclusive.

Security features that protect two-thirds of users are good. Security features that protect everyone are what the internet actually needs. 🔐

Zara Chen covers tech and politics for Buzzrag.