CYBERSECURITY

Web security has historically placed a strong emphasis on authentication. Significant progress has been made in strengthening it, from passwords to multi-factor authentication and now passkeys. As a result, compromising user credentials has become both more difficult and more costly for attackers.

However, authentication is only the entry point.

Once a session is established, most systems still rely on mechanisms that are effectively bearer tokens that are easy to reuse if exposed. This has led to a clear shift in attack patterns with an increased focus on session hijacking rather than credential theft.

The structural weakness: sessions as bearer tokens

After a user authenticates, the server issues a session identifier typically stored in a cookie that is sent with each subsequent request. This allows the user to remain authenticated without repeating the login process.

In most implementations, this session identifier functions as a bearer token where its possession is sufficient to grant access. This actually creates a structural weakness.

If a session token is exposed through malware, browser compromise or other means, it can often be reused in a different environment without requiring re-authentication. From the server's perspective, the request appears legitimate because the session is valid.

This model prioritizes usability but it assumes that session tokens remain confined to the original client environment. In practice, that assumption no longer holds.

The shift toward session-focused attacks

Attackers have increasingly adapted to this model. Rather than attempting to bypass authentication controls directly, many modern attack chains focus on extracting session data from the client. An infostealer malware, for example, is specifically designed to collect browser artifacts including cookies and session tokens.

Once obtained, these tokens can be replayed in a separate environment to gain access without triggering traditional authentication safeguards.

This changes the threat model in a meaningful way: authentication can be strong and credentials uncompromised, yet access can still be obtained through session reuse. This gap between authentication and session integrity is what DBSC aims to address.

Device Bound Session Credentials (DBSC)

Device Bound Session Credentials, introduced in Chrome 146 (April 2026), are an open W3C standard and designed to make session tokens non-transferable. The principle is straightforward: a session should only be valid on the device where it was created. To achieve this, DBSC introduces a cryptographic binding between the session and the client device.

How DBSC works in practice

When a user authenticates to a website that supports DBSC, the browser generates a cryptographic key pair.

The private key is stored securely on the device, typically within hardware-backed components such as a Trusted Platform Module (TPM) or Secure Enclave (a dedicated, isolated coprocessor built into the main system-on-a-chip of modern devices). This key is non-exportable by design.

The corresponding public key is shared with the server and associated with the user's session.

From that point onward, the session is no longer validated solely through possession of a cookie. Instead, the client must also prove that it holds the private key associated with that session.

This proof is provided transparently during session use or renewal without requiring user interaction.

A closer look at the flow

The diagram below illustrates how this binding is established and maintained over time.

The process starts at login, where the browser initiates a registration step.

At this stage, a key pair is generated on the device and the public key is sent to the server. The server stores it and associates it with the session being created.

This is the moment where the session stops being just a cookie and becomes tied to a cryptographic identity anchored in the device.

Once registration is complete, the server issues a session cookie in the usual way. The browser includes this cookie in subsequent requests so the application flow remains unchanged from the user's point of view.

The difference appears when the session is validated or refreshed.

Instead of relying only on the cookie, the browser must also prove that it still holds the private key associated with the session. This proof is verified by the server using the stored public key.

If the proof is valid, the session continues and the cookie can be refreshed. If not, the session is rejected even if the cookie itself is technically correct.

This is what prevents reuse across environments. A copied cookie, without access to the corresponding private key, is no longer sufficient to gain access.

Another important aspect visible in the diagram is the refresh cycle.

Sessions can be short-lived and continuously renewed, with each renewal requiring proof of device ownership. This reduces the usefulness of any intercepted data and limits exposure over time.

Impact on session hijacking

This mechanism directly addresses the replay scenario that underpins many modern attacks. If a session cookie is extracted and reused on another device, the attacker can present the token but cannot produce the required cryptographic proof. The server rejects the request.

In effect, the session token is thus no longer a portable credential. This represents a shift from a model based purely on possession to one based on possession combined with proof of origin.

Relationship to passkeys

DBSC complements rather than replaces modern authentication methods such as passkeys. Passkeys are designed to secure authentication itself. They eliminate shared secrets and reduce phishing risk by tying login to a trusted device.

DBSC extends this principle beyond authentication. It ensures that once a session is established, it remains bound to that same device.

In practical terms, passkeys address identity at login while DBSC protects the continuity of that identity over time.

A shift toward continuous trust

Taken together, these mechanisms reflect a broader evolution in web security. Instead of granting trust once at login and maintaining it implicitly, systems are moving toward continuously validating both identity and context. In the end, trust becomes something that is reinforced over time rather than assumed after a single event.

Practical considerations and trade-offs

Despite its benefits, DBSC also introduces new constraints.

For example, binding sessions to a specific device reduces portability so users cannot transfer active sessions between devices and switching environments also requires re-authentication. And if a device is lost or replaced, sessions cannot be recovered and must be re-established.

There are also privacy considerations.

Binding sessions to hardware-backed keys raises concerns about persistent cryptographic identifiers. The model mitigates this by scoping keys per site and preventing cross-site reuse but this remains an area that will be closely scrutinized.

From an implementation standpoint, DBSC adds complexity.

Servers must manage key registration, store public keys and verify cryptographic proofs during session validation. This introduces additional overhead compared to traditional session handling.

It is also important to understand its limits.

DBSC prevents session reuse across devices but it does not protect against compromise of the device itself. If an attacker controls the endpoint, they can operate within the valid session context.

In enterprise environments, adoption may be uneven.

Virtual desktops, shared systems and older hardware complicate the model because device identity is not always stable or hardware-backed.

Finally, as session trust becomes tied to hardware and platform capabilities, questions arise about interoperability and control. Over time, this may influence which environments are considered sufficiently "trusted" to access sensitive services.

The next shift: from identity to intent

Even with these improvements, the underlying dynamic remains unchanged: Attackers will adapt to where trust resides.

Historically, they targeted credentials and as authentication improved, they shifted to session reuse. Now, with device-bound sessions, that avenue becomes more constrained. Thus the logical next "taget" step is the device itself.

Instead of extracting and replaying session data, attackers increasingly operate within the user's environment. Techniques such as remote access tools or browser injection allow them to act directly through the trusted device.

In these scenarios, both identity and session validation succeed because the activity originates from the correct context.

This changes the nature of the problem. The question is no longer limited to whether a request is authenticated or whether it comes from a trusted device. It becomes whether the action itself is legitimate even though it comes from the right user on the right device.

Toward a layered model of trust

A more complete model of modern web security is emerging. Authentication mechanisms establish identity. Device-bound sessions maintain continuity and an additional layer (still evolving) focuses on behavior and intent. Each layer of this model addresses a different class of risk and one is sufficient on its own.

Conclusion

Device Bound Session Credentials (DBSC) address a long-standing weakness in web security which is the transferability of session tokens.

By binding sessions to hardware-backed keys, they significantly reduce the effectiveness of session hijacking attacks without introducing additional user friction.

At the same time, they do not eliminate the need for strong authentication or endpoint security. Instead, they fit into a broader shift toward continuous, context-aware trust.

As identity becomes more robust and sessions become non-transferable, the focus of security will continue to move toward the device and ultimately toward understanding behavior.

One subsequent challenge is no longer only to verify who is accessing a system, or from where, but to determine whether what they are doing is legitimate with behavioral analysis, intent verification etc.

About Me

I am a SecOps analyst in the FinTech insurance sector. My focus is on safeguarding sensitive assets by applying threat-informed defense strategies and ensuring strict adherence to industry standards (e.g., ISO 27001, ISO27701, NIST).