Google’s Solution to Cookie Theft: New Device-Bound Cookies

Device Bound Session Credentials (DBSC) are Google’s answer to one of the most persistent problems in browser security: session cookie theft. For years, defenders have watched attackers bypass passwords and MFA entirely by stealing the authenticated session itself. They didn’t need credentials. They only needed the right browser cookie — and that made session hijacking one of the most efficient post-compromise techniques in the hands of infostealer operators and the criminal ecosystems built around them.

With Chrome 146’s general availability rollout of DBSC to Windows users in April 2026, Google has delivered one of the most important technical responses to that problem in years.

With Chrome 146’s general availability rollout of Device Bound Session Credentials (DBSC) to Windows users in April 2026, Google has delivered one of the most important technical responses to that problem in years. But the rollout also makes clear that DBSC is a meaningful risk-reduction measure, not a silver bullet.

How Cookie Theft Works

Session cookies are small pieces of data stored by a web browser that hold authentication details that we interact with constantly. We use them when we add items to a shopping cart, log into social media or browse between pages while they work quietly in the background. Their role in this smooth browsing experience is also what makes them valuable to threat actors.

Locally stored Chrome cookies viewed in a SQLite browser

By taking session cookies from a user’s web browser, an attacker can impersonate the user and access their accounts without authorization. This is known as session hijacking, and it can happen through several techniques:

• Phishing attacks that trick the user into visiting a fake site
• Man-in-the-Middle (MitM) interception
• Cross-Site Scripting (XSS),
• And most commonly infostealer malware that harvests cookies directly from the browser’s local storage.

Once obtained, the cookie can be loaded into the attacker’s own browser or sold on Dark Web forums, where it functions as ready-made access to the victim’s accounts.

The Problem with the Current System

Traditional web sessions are largely bearer-token based: possession of the cookie is enough to grant access to the service that issued it. Anyone who has the cookie can authenticate, regardless of who they are. There is no verification of the holder’s identity beyond possession itself.

For the browser to maintain sessions, it needs access to these cookies, which makes them reachable by any malware running with sufficient privilege on the same machine. Operating systems are imperfect at isolating applications from each other, so one compromised process can often read resources belonging to another.

DBSC addresses this by replacing “possession equals authentication” with cryptographic proof. Each session is tied to a private key that never leaves the device so even if the cookie is copied, it cannot be reused elsewhere without that key.

How DBSC changes the current situation

What Is a TPM?

A Trusted Platform Module (TPM) is a hardware component that safely generates and stores cryptographic keys and verifies that a device’s firmware and operating system have not been tampered with. Historically, TPMs required a dedicated chip on the motherboard. With the TPM 2.0 standard, chipset makers can now incorporate TPM functionality directly into their silicon, which is why modern Windows devices broadly support it. DBSC on Windows uses the TPM as its secure key store; on macOS, the equivalent will be the Secure Enclave.

How DBSC Works

DBSC introduces a cryptographic public/private key pair associated with the user’s device. When a user authenticates on a DBSC-enabled site, Chrome generates this key pair and stores the private key in hardware-backed protection, the TPM on Windows. The server receives and stores only the public key.

Sessions then use short-lived cookies. When one of these cookies is about to expire, Chrome must prove possession of the private key to the server before a new cookie is issued. If a cookie was copied to another machine but the private key was not, the refresh will fail, and the cookie becomes useless within a short window.

An overview of the DBSC protocol showing the interaction between the browser and server (Source)

From an integration standpoint, DBSC was designed to fit into existing authentication stacks with limited backend changes. Chrome’s developer guidance specifies three pieces:

• A Secure-Session-Registration HTTP response header returned at login
• A registration endpoint that stores the public key and establishes the bound session
• A refresh endpoint that challenges the browser to prove possession of the private key before issuing a fresh cookie

Most existing endpoints do not need changes. This is important for adoption because security controls tend to fail at scale when they require a complete rewrite.

Why This Is Strategically Important

DBSC is the beginning of a broader architectural shift away from replayable session artifacts.

For years, security teams have relied on detection logic after theft had already occurred: impossible travel, device anomalies, IP reputation, user behavior analytics, and incident response after suspicious login continuation. Google’s own framing is that DBSC moves the model from reactive detection toward proactive prevention by making exfiltrated cookies far less useful off-device. That raises the cost for the attacker without demanding that every user become more security-aware.

It is also worth noting that DBSC was co-developed with Microsoft and is being standardized through the W3C Web Application Security Working Group, with web platforms including Okta participating in origin trials. This is not a Chrome-only proprietary feature; it is being positioned as an open web standard.

Where DBSC Falls Short

Security leaders should resist the temptation to oversell this. DBSC does not mean cookie theft is dead.

First, protection only exists for sessions on services that actually implement DBSC. A browser capability alone does not secure the web unless websites and identity providers integrate the registration and refresh endpoints.

Second, Chrome’s documentation is explicit that unsupported devices may fall back to normal behavior, and there are operational caveats around refresh failures.

Third, and most importantly, the W3C specification is clear that DBSC is not intended to stop an attacker who is already active on the victim’s device and able to operate in the user’s context. Malware present at session registration time may be able to bind the session to a key the attacker controls. Malware operating live on the device can abuse the session in-place without needing to export the private key at all.

What This Means for Attackers and Defenders

DBSC is strongest against the criminal workflow where malware steals a session token, ships it to another system, and hands it to an operator or downstream service for replay. That is the dominant infostealer economy today, and DBSC meaningfully disrupts it.

It is less decisive against resident adversaries, browser injection, malware operating at registration time, or deep endpoint compromise. In those cases, the attacker still has options, they just have fewer portable ones.

If DBSC adoption grows, attacker tradecraft will shift accordingly. We should expect more focus on on-device session abuse, browser instrumentation, token theft at registration time, and credential capture paths that still produce portable access. Forcing attackers to stay local generally increases noise, raises detection opportunities, and reduces the resale value of stolen session material. Even the W3C security considerations reflect this logic: DBSC aims to make malware act locally, where it becomes easier to detect and mitigate.

The attacker shift described above is one thread in a much larger identity-security story. Our 2026 Identity Threat Landscape Report covers the full picture: credential attacks, MFA bypass patterns, and the controls that are actually holding the line.

Identity Threat Landscape Report 2026

Practical Guidance for Enterprises

DBSC should be viewed as a risk-reduction multiplier and not a silver bullet. A few concrete steps:

• Identify critical surfaces. Which SaaS providers, internal web apps, customer portals, and identity layers handle email, admin access, financial transactions, customer data, and cloud control planes? Those are where session replay risk is highest and where DBSC support should be a procurement question.
• Ask vendors for timelines. A browser capability is only useful when servers integrate it. Product security teams should begin asking SaaS vendors when they plan to support DBSC registration and refresh endpoints.
• Treat session protection as a control family. Identity architects should stop treating session binding as an implementation detail buried inside web engineering and start treating it as a first-class control, alongside phishing-resistant authentication and privileged access management.
• Maintain existing defenses. DBSC does not replace endpoint detection, session analytics, or incident response. It complements them.

Conclusion

Cookies have long been a staple of web authentication because they are simple and easy to use. They have also long been a liability because possession alone confers authority. By using device-specific cryptographic keys and periodic possession checks, DBSC raises the standard for session management considerably.

Google’s initial goal, announced in April 2024, was to open DBSC origin trials by the end of that year. Even with the long path, the direction is the right one. Defenders should pay close attention and keep their other controls in place while the ecosystem catches up.