For years, the session cookie has been the soft underbelly of web security — a tiny, invisible token that, once stolen, hands an attacker the keys to a user’s entire digital life. From corporate email accounts to banking portals, session cookie theft has enabled some of the most damaging account takeovers in recent history, often with no warning until it is too late. Google’s Chrome browser is now taking direct aim at this vulnerability with a quietly profound shift: device-bound sessions that anchor authentication to the physical hardware of a user’s device, making stolen cookies worthless in the hands of an attacker. This is not a minor patch or a marginal improvement. It is a fundamental rethinking of how session integrity is maintained on the open web.
What Are Device-Bound Session Credentials and Why Do They Matter?
Device-Bound Session Credentials, or DBSCs, represent a new authentication paradigm that eliminates the longstanding reliance on shared secrets — the session cookies that have been the standard mechanism for maintaining logged-in states since the early days of the web. Under the traditional model, a server sets a cookie in the browser, and every subsequent request simply presents that cookie to prove the user is authenticated. The problem is brutally simple: if an attacker steals that cookie — through malware, a phishing attack, or a man-in-the-middle interception — they can impersonate the user from any device, anywhere in the world. The cookie itself is the only proof of identity, and it is entirely portable.
DBSCs break this model by binding the session to a cryptographic key stored in the device’s hardware security module. When a website sets a session cookie under the DBSC framework, the browser must also sign a challenge with a private key that never leaves the Trusted Platform Module (TPM) on Windows or the Secure Enclave on macOS. The server stores the corresponding public key. When a request comes in, the server sends an authentication challenge that the browser must answer by producing a signature from the private key. If the signature is valid, the session proceeds. If not — if the cookie has been copied to another machine — the request is rejected, because the attacker’s device lacks the private key to sign the challenge.
As Scott Helme, a researcher and founder of Report URI, explained in a blog post on Tuesday, the core protection is elegantly simple: “The attacker can’t steal the private key from the device because the TPM / Secure Enclave will not release it. That is the core protection here. The attacker can steal the cookie, but they can’t answer a DBSC challenge by signing it with the private key, which is still safe on your device.” This is the critical architectural insight: the cookie itself is no longer sufficient. It becomes a piece of a larger cryptographic puzzle, and without the hardware-bound key, the puzzle cannot be solved.
How DBSCs Stop the Most Common Account Takeover Attacks
Session cookie theft is not a theoretical threat. It is one of the most prevalent attack vectors in modern cybercrime, fueling everything from credential-stuffing campaigns to sophisticated targeted intrusions. Attackers steal session cookies through a variety of methods: info-stealing malware that scrapes browser data, phishing pages that trick users into revealing tokens, cross-site scripting exploits that exfiltrate cookies from vulnerable web applications, and network-level interception on unencrypted or poorly secured connections. Once a cookie is in hand, the attacker can load it into their own browser and instantly gain access to the victim’s account — no password required, no multi-factor authentication prompt triggered, no suspicious location alert raised. The session is simply handed over.
DBSCs render all of these attacks ineffective. An info-stealer that exfiltrates session cookies from a compromised machine will deliver a cookie that is useless on any other device. A phishing page that captures a session token in real time will find that the token cannot be replayed from the attacker’s own browser. A cross-site scripting payload that reads document.cookie will obtain a value that has no standalone value. The cryptographic binding to the hardware key means that the cookie is only valid when presented from the same device that holds the corresponding private key — and the private key cannot be extracted, copied, or moved.
This is a particularly important improvement for enterprise environments, where session cookie theft is a common vector for lateral movement and privilege escalation. An attacker who compromises a single employee’s machine can often use stolen session cookies to access cloud services, internal applications, and administrative portals without triggering any alarms. DBSCs close that door. Even if an attacker achieves full remote access to a machine, the session cookies they steal are bound to that specific device and cannot be used from a command-and-control server or a secondary machine.
The Technical Foundation: TPM, Secure Enclave, and the Principle of Hardware-Bound Keys
The security of DBSCs rests on the properties of dedicated hardware security modules that have become standard components in modern computing devices. Windows machines have included Trusted Platform Module chips for years, and Apple’s Mac lineup has used the Secure Enclave since the introduction of the T2 chip. These components are designed to isolate cryptographic operations from the main operating system, storing private keys in a way that prevents them from being read by any software — including the operating system itself, the kernel, and any applications running with elevated privileges.
When Chrome generates a private key for a DBSC session, it requests that the TPM or Secure Enclave create the key internally. The hardware module generates the key pair, stores the private key in its own secure storage, and returns only the public key to the browser. The browser then sends the public key to the web server, which stores it as part of the session record. From that point forward, whenever the server needs to verify the session, it sends a challenge — a random string of data — and the browser forwards that challenge to the hardware module, which signs it with the private key. The resulting signature is sent back to the server, which verifies it against the stored public key.
This process is fundamentally different from software-based key storage, where a private key is stored in a file on disk or in a memory region that can be read by an attacker who has gained code execution on the device. Even if the operating system is fully compromised, the hardware module will not reveal the private key. It will only use it to sign data that the requesting application presents, and it does so within a secure boundary that is inaccessible to the rest of the system. Apple’s documentation, which explains the Secure Enclave’s operation in detail, emphasizes that the processor enforces strict isolation between the Secure Enclave and the main application processor, ensuring that even a compromised kernel cannot extract keys stored within.
This is the same architectural principle that underlies passkeys, the passwordless authentication standard that Apple, Google, and Microsoft have been promoting. As covered in a post published earlier this week, passkeys also use hardware-bound private keys, stored in the TPM or Secure Enclave, to authenticate users without shared secrets. The difference is that passkeys are used for primary authentication — the initial login — while DBSCs maintain the session after authentication. Together, they form a complete hardware-backed authentication flow: a passkey proves who you are at login, and a DBSC proves that you are still the same device throughout the session.
Current Availability: Chrome 147 on Windows and Chrome 150 on macOS
For the moment, DBSCs are not universally available. Google has implemented the feature in Chrome version 147 for Windows and Chrome version 150 for macOS, and even in those versions, the feature is enabled only for a limited subset of users. This is a deliberate rollout strategy, consistent with Google’s typical approach to deploying security-sensitive features: test with a small population, monitor for issues, and expand gradually. Users who want to check whether DBSCs are active on their browser can open the developer tools, navigate to the Application tab, and look for a “Device Bound Sessions” entry. If it appears, and if the user is logged into a site that supports the protocol, the feature is active.
This limited rollout suggests that Google is still working through edge cases, compatibility issues, and performance considerations. The browser must manage cryptographic operations with the hardware module on every authenticated request, which introduces a new latency consideration. The TPM and Secure Enclave are designed for relatively low-throughput operations, and a browser that is making dozens of authenticated requests per second to multiple sites could potentially create a bottleneck. Google is likely evaluating whether the performance impact is acceptable and whether any sites or applications break under the new model.
It is also worth noting that DBSCs are a Chrome feature, not a web standard — at least not yet. The implementation is built on the Web Authentication API, which is a W3C standard, but the specific application to session management is Chrome’s own innovation. Other Chromium-based browsers, such as Microsoft Edge, Brave, and Opera, will likely adopt the feature over time, given that they share Chrome’s codebase and typically follow Google’s lead on security enhancements. However, the timeline for such adoption is unclear. Non-Chromium browsers, including Safari and Firefox, would need to implement the feature from scratch, and there is no indication that either Apple or Mozilla has committed to doing so. This has the potential to create a fragmented security landscape, where users of some browsers are protected against session cookie theft while users of others are not.
What This Means for the Security Landscape
The introduction of DBSCs represents a significant step forward in the ongoing effort to move beyond the password-cookie model that has defined web authentication for three decades. The concept of a shared secret — a password, a token, a cookie — has always carried an inherent vulnerability: if the secret is shared with the wrong party, the protection is lost. Hardware-bound keys eliminate this vulnerability by making the secret non-transferable by design. The private key never leaves the device, never travels over the network, and never appears in a log file. It is, in the truest sense, a secret that cannot be stolen.
This is not to say that DBSCs solve every security problem. They do not protect against real-time session hijacking where an attacker controls the user’s device directly — for example, through a remote access trojan that performs actions through the legitimate browser. They do not prevent an attacker from using the user’s own machine to perform actions while the user is logged in. They do not address the threat of malware that reads the screen or captures keystrokes. What they do is eliminate the most common and most damaging form of credential theft: the extraction of a session token that can be used from a different device, often in a different country, without the user’s knowledge.
For organizations that have been struggling with session cookie theft as a persistent threat, DBSCs offer a practical solution that does not require changes to user behavior. Users do not need to learn new workflows, install additional software, or manage hardware tokens. The protection is invisible, operating entirely within the browser and the hardware security module. Websites that implement DBSC support can offer their users a significantly higher level of security without any additional friction — a rare combination in the world of authentication.
The Broader Context: From Passwords to Passkeys to Device-Bound Sessions
The web is in the middle of a long-term transition away from shared secrets in all forms. Passwords, the original shared secret, have been under attack for decades, and the industry has responded with multi-factor authentication, password managers, and, most recently, passkeys. Session cookies, however, have remained largely unchanged in their fundamental design. They are still shared secrets, still transmitted with every request, still vulnerable to the same class of attacks that have plagued passwords for years. DBSCs address this gap by applying the same hardware-backed cryptographic principle that makes passkeys secure to the session management layer.
This transition is not happening overnight. The web has billions of active sessions running on millions of sites, and every one of those sites must choose to implement DBSC support. Google’s gradual rollout on the browser side is only half the equation. Websites must also update their servers to handle the DBSC protocol, storing public keys and sending challenges. Until enough sites adopt the feature, most users will not see any difference in their day-to-day browsing. But the direction is clear: the industry is moving toward a model where authentication is anchored to hardware, not to secrets that can be copied, stolen, or guessed.
Apple’s documentation on the Secure Enclave, which explains the isolation mechanisms and the cryptographic guarantees, provides a useful reference for understanding the security properties of hardware-backed keys. The same principles apply to the TPM on Windows, which is governed by the Trusted Computing Group’s specifications. Both implementations ensure that the private key is generated within the hardware module, stored within the hardware module, and used only within the hardware module. No software, not even the operating system kernel, can read the key directly. This is a fundamentally different security posture from software-based key storage, where the key is ultimately a sequence of bytes in memory that can be read by an attacker with sufficient privileges.
How to Check If DBSCs Are Active on Your System
For users who are running Chrome 147 on Windows or Chrome 150 on macOS and want to know whether the feature is active, the process is straightforward. Open the browser’s developer tools by pressing F12 or right-clicking anywhere on a page and selecting “Inspect.” Navigate to the “Application” tab, which is typically located across the top of the developer tools panel alongside Elements, Console, Sources, and Network. Scroll down the left-hand sidebar until you see the “Device Bound Sessions” entry. If it appears, and if you are logged into a site that supports the DBSC protocol, the feature is running on your browser.
It is important to note that DBSCs must be supported by both the browser and the website. A user can have the feature enabled in Chrome, but if the website they are visiting has not implemented DBSC support, the session will continue to use traditional cookies. The feature is backward compatible by design: sites that do not support DBSCs simply receive a standard session cookie, and the browser handles the DBSC protocol only when the server indicates that it is available. This ensures that the rollout does not break existing functionality while allowing early adopters to benefit from the enhanced protection.
What the Future Holds for Device-Bound Session Credentials
The introduction of DBSCs in Chrome is a milestone, but it is only the beginning of a longer journey. For the feature to reach its full potential, it needs widespread adoption on both the browser side and the server side. Other browser vendors must implement the protocol, and website operators must deploy the necessary server-side code. Google’s track record with security features suggests that this will happen, but it may take years rather than months. The company has a history of introducing security innovations in Chrome and then gradually expanding their reach through the Chromium ecosystem and through pressure on the wider web.
The broader significance of DBSCs is that they complete a vision of hardware-anchored authentication that has been taking shape for years. Passkeys handle the login. Device-bound sessions handle the session. Together, they create an environment where the user’s identity is tied to their device in a way that cannot be spoofed, copied, or stolen. This is not a minor improvement. It is a structural change in the security model of the web, one that addresses a class of vulnerabilities that has been exploited at scale for as long as session cookies have existed.
For users, the practical impact will be invisible but profound. The next time they log into a banking site, a corporate email system, or a healthcare portal, the session cookie that keeps them logged in will be protected by the same hardware security that guards their device’s encryption keys. An attacker who steals that cookie will find it useless. A phishing campaign that captures it will produce a token that cannot be replayed. The session will be bound to the device, and the device alone, and that is the difference between a vulnerability that can be exploited at scale and a vulnerability that is effectively closed.
