Chrome 146 Ships Device-Bound Sessions to Kill Cookie Theft

Google activated Device Bound Session Credentials (DBSC) protection in Chrome 146 for Windows this week, deploying a hardware-backed defense against one of infostealers' most valuable targets: authentication cookies.

The feature cryptographically binds session tokens to the physical device that created them. Stolen cookies become worthless on any other machine—attackers can exfiltrate them, but they can't use them.

Why This Matters

Infostealers have made cookie theft industrialized. Malware families like Lumma, Vidar, and Atomic Stealer harvest browser cookies at scale, selling access on dark web marketplaces. Researchers tracking the infostealer-to-ransomware pipeline found that stolen credentials typically appear on underground markets within 48 hours of infection—and ransomware execution often follows within another 48 hours.

Session cookies bypass password-based defenses entirely. If an attacker has your session token, they don't need your password or MFA code. They inherit your authenticated session and can access anything you can access.

DBSC breaks this model. Even if malware extracts cookies from Chrome's data stores, those tokens won't authenticate on attacker infrastructure.

How DBSC Works

The system uses hardware security modules—TPM 2.0 on Windows, Secure Enclave on macOS—to generate device-specific cryptographic keys:

1. Key generation: When you authenticate to a DBSC-enabled website, Chrome generates a public/private key pair within the TPM. The private key never leaves the hardware module.

2. Session binding: The website issues a session cookie tied to the public key. To use the session, the browser must prove possession of the corresponding private key.

3. Continuous verification: Short-lived session cookies require periodic refresh. Each refresh requires cryptographic proof that the original device is still present.

4. Theft mitigation: Stolen cookies lack the private key. When attackers attempt to use them, the cryptographic handshake fails and the session is rejected.

Google reported "a significant reduction in session theft" since DBSC's deployment began.

Hardware Requirements

DBSC requires hardware-backed key storage. On Windows, this means:

• TPM 2.0 chip, or
• Windows Hello-compatible security hardware

Google's telemetry indicates approximately 85% of active Windows Chrome installations meet these requirements. Systems without compatible hardware fall back to standard session behavior—no breakage, just no additional protection.

The feature launched for Windows in Chrome 146. macOS support using Secure Enclave will follow in an upcoming release.

What DBSC Protects

The protection applies to websites that implement the DBSC protocol. Google accounts are protected by default. Third-party websites must adopt the standard for their users to benefit.

Current coverage includes:

• Google Workspace accounts
• Google Cloud Platform
• Gmail, Drive, and other Google services

Enterprise identity providers and major SaaS platforms are expected to adopt DBSC throughout 2026. Microsoft has indicated Entra ID (Azure AD) support is in development.

Privacy Considerations

DBSC generates unique keys per website and per session. This architecture prevents cross-site correlation—websites can't use DBSC to track users across different services.

Each new authentication creates a fresh key pair. There's no persistent device identifier that websites can leverage for fingerprinting.

Limitations

DBSC doesn't protect against all credential theft scenarios:

• Real-time proxy attacks: Adversary-in-the-middle phishing (like the Storm-2755 Payroll Pirate campaign) intercepts sessions in real-time before they're bound to hardware
• Same-device attacks: Malware running on the victim's machine can potentially interact with the TPM directly
• Non-Chrome browsers: The protection only applies to Chrome. Safari, Firefox, and Edge have not announced similar features

The technology complements rather than replaces other defenses. Phishing-resistant MFA, endpoint detection, and security awareness training remain essential.

Checking Your Status

To verify DBSC is active:

1. Navigate to chrome://settings/security
2. Look for Device Bound Session Credentials in the security settings
3. Ensure Chrome 146 or later is installed

Enterprise administrators can manage DBSC through Chrome Enterprise policies if they need to disable the feature for compatibility testing.

The Broader Context

DBSC represents Google's response to the infostealer economy that has flourished over the past three years. We've covered numerous campaigns exploiting stolen cookies—from the CPUID supply chain attack distributing credential stealers to Chrome extension malware harvesting session tokens from Meta Business accounts.

Hardware-bound sessions make the entire cookie theft business model less viable. Attackers can still compromise individual machines, but they can't monetize stolen sessions across their infrastructure the way they do today.

For organizations concerned about credential theft, DBSC is one piece of a layered defense. Our online safety guide covers additional steps for protecting accounts against common attack patterns.