Device Bound Session Credentials (DBSC) explained

+70-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

Browser Support Status

Legend: 🧪 Origin Trial (experimental) | ⏸️ Trial ended | 🔄 Evaluating/monitoring | ❌ Not yet available

Note: DBSC currently requires TPM hardware on Windows. Support for other platforms will expand.

Key Advantages: DBSC vs current Model

The architecture of the World Wide Web was founded on a principle of statelessness. When HTTP was first designed, it did not retain information about users between requests. To solve this, the "cookie" was invented - a small piece of data sent from a website and stored on the user's computer, to be sent back to the website with every subsequent request. For decades, this mechanism has served as the bedrock of session management. When a user logs in, the server validates their credentials and issues a cookie. This cookie acts as a "bearer token." In the physical world, a bearer instrument is a document that entitles the holder to the rights or assets it represents; if you hold the bond, you own the bond. Similarly, in the digital world of HTTP, if you hold the cookie, you are the user.

This bearer capability is simultaneously the web's greatest utility and its most profound vulnerability. The security of the entire session - and by extension, the user's identity, data, and financial assets - rests entirely on the secrecy of that cookie string. If a malicious actor can copy that string, they can impersonate the user from any device, anywhere in the world, bypassing the initial authentication checks entirely. This specific vulnerability has given rise to an industrial-scale underground economy of "cookie theft" and "session hijacking".

As the industry successfully hardens the "front door" of authentication through the adoption of FIDO (Fast Identity Online) standards and Passkeys, attackers are shifting their focus to the "back door": the active session. Phishing a password is becoming harder, but stealing a session cookie remains dangerously effective. The industry's response to this escalating threat is Device Bound Session Credentials (DBSC).

DBSC represents a paradigm shift in how web sessions are maintained. It proposes moving away from simple bearer tokens toward a model where the session is cryptographically bound to the device. Chrome's implementation uses TPMs on Windows when available; the spec is agnostic about key storage, requiring only that it be "robust against the described threat." This makes stolen cookies far less valuable. They cannot be refreshed from another device without the bound key.

This article provides an exhaustive analysis of DBSC, designed for security architects, product managers, and developers. It explores the technical architecture, the business implications of "frictionless security," the relationship with emerging standards like Shared Signals (CAEP/RISC), and how organizations can prepare for this future using platforms like Corbado.

Key Questions this Article answers

1. Why is current session management failing to prevent account takeovers?
2. How is DBSC different from existing "Secure" cookies and HttpOnly flags?
3. How do DBSC and Passkeys work together for stronger phishing resistance?
4. What happened to Token Binding, and why is DBSC succeeding where it failed?
5. What are the business implications and ROI for Product Managers?
6. Which browsers and operating systems support DBSC today?
7. How can organizations implement DBSC without building from scratch?
8. What is the relationship between DBSC, DPoP, and OAuth 2.0?
9. How does DBSC integrate with Shared Signals (CAEP/RISC) for real-time threat response?

To navigate the complexity of this new standard, we must first understand the fundamental problems with current session management and how DBSC provides solutions. Each of these areas represents a critical vulnerability or limitation that DBSC addresses.

The fundamental failure of current session management is the "portability" of trust. When a server issues a session cookie, it is essentially issuing a passport that works for anyone who holds it. While browsers have implemented defenses like HttpOnly and Secure flags (preventing JavaScript access and ensuring transmission over HTTPS), these defenses only protect against specific extraction vectors like Cross-Site Scripting (XSS) or network sniffing. They offer no protection against malware running on the host device. "Infostealers" are malware specifically designed to locate the browser's cookie storage file on the disk, decrypt it (often using the user's own OS-level credentials), and exfiltrate the contents to a command-and-control server. Once the attacker possesses the cookie, they can perform a Pass-the-Cookie attack, injecting the stolen token into their own browser to hijack the session. The server, seeing a valid cookie, assumes the request is legitimate.

DBSC introduces a second factor of authentication into the session maintenance loop itself. Unlike a standard secure cookie, which is a static secret, a DBSC session consists of a short-lived bearer token and a cryptographic proof of possession. The browser generates a public-private key pair stored securely on the device. The server binds the session to the public key. Periodically, the browser must prove it still holds the private key by signing a challenge from the server. The spec requires key storage "robust against the described threat". Chrome uses TPM on Windows when available. If an attacker steals the cookie from a different device, they cannot refresh it because they cannot generate the required cryptographic signature. The "bearer" aspect is minimized to a very short window, while the "binding" aspect provides long-term continuity.

Passkeys and DBSC are complementary technologies that secure different phases of the user lifecycle. Passkeys (FIDO2) solve the authentication problem proving identity to start a session without passwords, thus eliminating credential phishing. DBSC addresses the post-authentication problem making session hijacking via cookie theft significantly harder. The FIDO Alliance frames DBSC as a complementary technology that "raises the bar" against session hijacking. Together, they reduce the attack surface across login and session lifecycle though DBSC does not protect against malware with ongoing device access or real-time browser-in-the-middle attacks on the same device.

How Passkeys and DBSC work together

DBSC is not the first attempt to solve this problem. "Token Binding" was a previous standard that attempted to bind cookies to the underlying TLS (Transport Layer Security) connection. While cryptographically sound, Token Binding failed to gain adoption due to its heavy reliance on the TLS layer. In the modern web, TLS connections are often terminated at load balancers, CDNs, or reverse proxies, while the application logic resides servers behind them. Propagating Token Binding information through these complex network layers proved too difficult. DBSC learns from this failure by operating entirely at the Application Layer (HTTP). It does not depend on the underlying network connection, making it compatible with existing load balancers, proxies and cloud infrastructure.

For product leaders, DBSC offers an opportunity to improve security while simultaneously improving user experience (UX). Traditionally, high security meant short session timeouts, forcing users to log in frequently (friction). By binding the session to the device, the risk of remote cookie theft is significantly reduced. Businesses can consider longer session durations, knowing that stolen cookies cannot be refreshed from another device. However, DBSC does not protect against device theft, persistent malware on the device, or abuse by a malicious use, so session lifetime policies should still reflect these residual risks.

To understand the urgency behind DBSC, one must appreciate the sophistication of the modern threat landscape. The theft of session cookies has graduated from a niche hacker trick to a scalable, automated industry.

graph TD
    A[User Downloads<br/>Malicious Software] -->|Execution| B[Infostealer Activates<br/>on Device]
    B --> C[Locates Browser Data]
    C --> D[Chrome/Edge/Firefox<br/>Cookie Storage]
    C --> E[Password Database]
    C --> F[Crypto Wallets]
    
    D --> G[Decrypts Using<br/>OS Credentials]
    E --> G
    F --> G
    
    G --> H[Creates Log File<br/>with Stolen Data]
    H --> I[Exfiltrates to C2 Server]
    I --> J[Dark Web Marketplace]
    
    J --> K[Attacker Purchases Log]
    K --> L[Imports Cookie to<br/>Own Browser]
    L --> M[Bypasses MFA]
    M --> N[Account Takeover<br/>Complete]
    
    style A fill:#ff6b6b,color:#fff
    style B fill:#ff6b6b,color:#fff
    style N fill:#ff6b6b,color:#fff
    style J fill:#495057,color:#fff
    style M fill:#ffd43b,color:#000

Malware-as-a-Service (MaaS) has lowered the barrier to entry for cybercriminals. "Infostealers" like RedLine, Raccoon, Vidar, and Taurus are commercially available malware strains designed with one primary goal: data exfiltration from web browsers. These stealers are distributed via phishing emails, cracked software, or malicious ads. Once installed, they target the specific file paths where browsers like Chrome, Edge, and Firefox store their data.

• The Target: The Cookies database (usually an SQLite file) and the Login Data database (saved passwords).
• The Mechanism: Browsers encrypt these databases using Data Protection APIs (DPAPI on Windows) linked to the user's OS login. Since the malware runs as the user, it can trivially request decryption of these files.
• The Output: The malware generates a "log"—a zip file containing the decrypted cookies, passwords, system information, and sometimes crypto-wallet keys.

These logs are aggregated and sold on dark web marketplaces like Genesis Market (before its takedown) and Russian Market. Buyers can search for logs containing active cookies for specific high-value targets: "Salesforce," "Gmail," "Bank of America," or "AWS Console."

The Bypass: The value of a cookie log lies in its ability to bypass Multi-Factor Authentication (MFA). Most MFA challenges (SMS, TOTP, Push) occur only during the login event. Once the session is established and the cookie issued, the server assumes the user is trusted. An attacker importing a valid session cookie slides right past the MFA gate, appearing to the server as the user returning to an active tab.

Cloud productivity suites are prime targets. A stolen session cookie for a Google Workspace or Microsoft Entra ID (formerly Azure AD) account can give an attacker access to corporate email, documents, and internal systems. Google's own threat intelligence has reported a massive surge in cookie theft as a primary vector for accessing Google Accounts, explicitly naming it as the driver for their investment in DBSC. They note that as they force-enable 2-Step Verification (2SV) and passkeys, attackers have simply shifted tactics from credential phishing (which 2SV / passkeys stops) to cookie theft (which 2SV / passkeys often doesn't stop).

Historically, risk engines have tried to detect session theft by analyzing device fingerprints, looking at the User-Agent string, screen resolution, installed fonts, and IP address. If a session cookie suddenly appears from a new IP with a slightly different canvas fingerprint, the server might invalidate it. The Problem: Privacy initiatives in browsers (like Safari's Intelligent Tracking Prevention and Chrome's Privacy Sandbox) are actively reducing the entropy of these fingerprints to stop ad-tracking. This makes "good" fingerprinting for security increasingly difficult. Furthermore, attackers now use "Anti-Detect Browsers" that allow them to spoof these fingerprints perfectly to match the victim's profile, rendering heuristic detection ineffective. DBSC replaces this probabilistic guessing game with deterministic cryptographic proof.

Device Bound Session Credentials (DBSC) introduces a standardized API and protocol for creating sessions bound to a key on the client device. The spec requires key storage "robust against the described threat" but is agnostic about implementation. Chrome uses TPM on Windows when available. This section details the mechanics as defined in the W3C Working Draft and Chrome's documentation.

The DBSC lifecycle allows a seamless transition from a standard session to a bound session, ensuring backward compatibility and progressive enhancement.

sequenceDiagram
    participant User
    participant Browser
    participant HSM as HSM (TPM/Secure Enclave)
    participant Server
    
    Note over User,Server: Phase 1: Authentication & Binding
    User->>Browser: Login with credentials/passkey
    Browser->>Server: Authentication request
    Server->>Browser: Success + DBSC registration header
    Browser->>HSM: Generate key pair
    HSM->>Browser: Public/Private key (private non-exportable)
    Browser->>Server: Register public key (JWT signed)
    Server->>Server: Bind session to public key
    Server->>Browser: Short-lived cookie (5 min)
    
    Note over User,Server: Phase 2: Normal Usage
    loop Every request within 5 minutes
        Browser->>Server: Request with cookie
        Server->>Browser: Response
    end
    
    Note over User,Server: Phase 3: Refresh (after expiry)
    Browser->>Server: Request with expired cookie
    Server->>Browser: 401 + Challenge nonce
    Browser->>HSM: Sign challenge
    HSM->>Browser: Signature
    Browser->>Server: Signature proof
    Server->>Server: Verify with stored public key
    Server->>Browser: New short-lived cookie
    Browser->>Server: Retry original request
    Server->>Browser: Success response

The binding process begins immediately after the user authenticates using standard methods (password, passkey, etc.).

1. Server Signal: Upon successful login, the server sets a session cookie (as usual) but adds a specific header indicating DBSC support.

   HTTP  
   HTTP/1.1 200 OK  
   Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict  
   Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register"
   

   • The Secure-Session-Registration header tells the browser: "I support algorithms ES256 and RS256. Please register a bound session at the endpoint /auth/dbsc/register."
2. Key Generation: The browser parses this header. It generates a new asymmetric key pair (e.g., Elliptic Curve P-256), stored securely on the device.
   • Implementation Note: Chrome uses TPM on Windows when available; the spec is agnostic about storage mechanism, requiring only that it be "robust against the described threat."
   • Privacy Scope: The key is scoped to the web origin (e.g., bank.com). The browser ensures this key is never used for retailer.com, preventing cross-site tracking.
3. Registration Request: The browser sends a request to the specified registration path. This request includes the newly generated Public Key inside a JSON Web Token (JWT), signed by the Private Key (self-signed attestation).

   HTTP  
   POST /auth/dbsc/register HTTP/1.1  
   Content-Type: application/jwt  
     
   \<JWT Header\>.\<JWT Payload containing Public Key\>.\<Signature\>
   

4. Session Binding: The server validates the signature to ensure the public key is functional. It then updates its database to associate the user's session (session_id=xyz123) with this specific Public Key. From this moment on, the session is "bound."

To balance security with performance (secure key operations can add latency), DBSC uses a dual-token system.

1. Issuance: The server issues a new, short-lived cookie (e.g., valid for 5 minutes). Let's call this access_token.
2. Usage: The browser uses this access_token for all normal requests (fetching images, API calls, navigating pages). As long as the cookie is valid, no cryptographic operations are performed. This ensures browsing remains fast.
3. Expiration: After 5 minutes, the access_token expires.

This is the heart of the security mechanism. When the short-lived cookie expires, an attacker on a different device is locked out, but the legitimate user (with access to the bound key) can continue.

1. Detection: The browser attempts a request. It notices the cookie is expired (or the server returns a 401 or a specific Secure-Session-Challenge header).
2. Interception: The browser pauses the network request. It does not show an error to the user.
3. Refresh Request: The browser automatically calls the refresh endpoint defined in the session configuration.
   • The server sends a cryptographic Challenge (a nonce).
   • The browser uses the bound key to sign this challenge.
   • The signature proves possession of the private key.
4. Submission: The browser sends the signed challenge back to the server.

   HTTP  
   POST /auth/dbsc/refresh HTTP/1.1  
   Sec-Secure-Session-Id: \<Session ID\>  
   Secure-Session-Response: \<JWT Signature of Challenge\>
   

5. Validation: The server uses the stored Public Key to verify the signature.
   • If Valid: The server knows the request is coming from the same physical device that started the session. It issues a new short-lived access_token (valid for another 5 minutes).
   • If Invalid: The request is rejected. The session is terminated.
6. Resumption: The browser takes the new cookie and transparently retries the original paused request. The user experiences no interruption.

graph LR
    subgraph "Victim's Device"
        A[User Session<br/>with DBSC] 
        B[HSM/TPM<br/>Private Key]
        C[Cookie +<br/>Session ID]
        A --> B
        A --> C
        B -.->|Non-exportable| X[Cannot Extract<br/>Private Key]
    end
    
    subgraph "Attack Scenario"
        D[RedLine Stealer<br/>Infects Device]
        D --> E[Steals Cookie<br/>& Session ID]
        E --> F[Exports to<br/>Attacker]
    end
    
    subgraph "Attacker's Device"
        G[Imports Stolen<br/>Cookie]
        H[Attempts to<br/>Use Session]
        I[Server Requests<br/>DBSC Refresh]
        J[Cannot Sign<br/>Challenge]
        K[Session Denied]
        
        G --> H
        H --> I
        I --> J
        J --> K
    end
    
    C -.->|Stolen| E
    F --> G
    
    style D fill:#ff6b6b,color:#fff
    style K fill:#51cf66,color:#fff
    style B fill:#4c6ef5,color:#fff
    style X fill:#51cf66,color:#fff
    style J fill:#ff6b6b,color:#fff

Consider an attacker who infects the user's PC with RedLine Stealer. They steal the access_token and the session_id. They import these into their own browser.

• Scenario A (Within 5 minutes): The attacker might get access for a few minutes until the short-lived token expires.
• Scenario B (After Expiration): The attacker's browser (on a different device) tries to use the token. The server rejects it and demands a refresh. The attacker's browser sees the DBSC headers but cannot perform the refresh because it does not have the bound private key. The attack fails.

Privacy is a central design goal of DBSC. The W3C specification explicitly prohibits the use of global identifiers that could track users across sites.

• Per-Origin Keys: The browser generates a unique key pair for every site. google.com sees Key A; amazon.com sees Key B. There is no correlation between them.
• User Clearing: If the user clears their cookies/site data, the browser also deletes the associated DBSC keys. This ensures that DBSC cannot be used as a "super-cookie" to resurrect deleted identities.

Implementing DBSC requires the server to maintain state about the public keys.

• Database Schema: The session table must be updated to store the public_key and the last_challenge alongside the user_id and `session_expiry.
• Performance: The refresh operation involves cryptographic verification (e.g., verifying an ECDSA signature). While fast, it is more CPU-intensive than checking a simple string. However, because refreshes only happen every few minutes (not every request), the overhead is negligible.

Beyond the technical specifications, DBSC carries significant implications for business strategy, product roadmaps, and compliance postures.

Security initiatives are often viewed as cost centers or friction generators. DBSC flips this narrative.

• Fraud Reduction: By neutralizing the primary vector for Account Takeover (ATO), businesses can save millions in fraud losses. For banks and fintechs, this means fewer unauthorized transactions and reduced chargeback liability.
• Support Costs: Account recovery is expensive. Verifying a user's identity after they have been hacked often involves manual review, document uploads, and support calls. Preventing the hack in the first place directly reduces this operational burden.
• Conversion Optimization: In e-commerce, every login prompt is a potential drop-off point. DBSC allows for aggressive "keep me logged in" policies. A user can return to a shopping cart weeks later and still be securely authenticated, allowing for instant checkout without a password prompt.

Regulatory frameworks like the GDPR (General Data Protection Regulation) in Europe require organizations to implement "appropriate technical and organizational measures" to ensure security.

• Defensible Security: As DBSC becomes a standard, it will likely be interpreted as the "state of the art" for session management. In the event of a breach, demonstrating that DBSC was implemented can be a powerful defense against negligence claims.
• Banking Standards (PSD2): The Payment Services Directive 2 requires "Strong Customer Authentication" (SCA). While SCA focuses on login, the dynamic linking of the session to the device aligns perfectly with the directive's goals of binding authentication to specific amounts and payees.

The FIDO Alliance whitepapers highlight the concept of "Assurance Levels".

• Moderate Assurance: Uses synced passkeys (like those in iCloud Keychain). Great for consumer apps, recoverable, easy to use.
• High Assurance: Requires device-bound keys. This is where DBSC shines. For enterprise resources (HR portals, code repositories) or high-value banking, the organization may enforce a policy that only allows access from sessions bound to a specific managed device. DBSC provides the technical enforcement mechanism for this policy.

To fully appreciate DBSC, we must compare it against other technologies that have attempted to solve similar problems.

graph RL
    subgraph "Traditional Cookies"
        TC1[Bearer Token Only]
        TC2[Vulnerable to Theft]
        TC3[Long Sessions = Risk]
        TC1 --> TC2
        TC2 --> TC3
    end
    
    subgraph "Token Binding"
        TB1[TLS Layer Binding]
        TB2[❌ Failed: Complex Infrastructure]
        TB3[Broke at Load Balancers]
        TB1 --> TB2
        TB2 --> TB3
    end
    
    subgraph "DPoP"
        DP1[OAuth Token Binding]
        DP2[✅ API Protection]
        DP3[Not for Browser Sessions]
        DP1 --> DP2
        DP2 --> DP3
    end
    
    subgraph "DBSC"
        D1[HTTP Layer Binding]
        D2[✅ Hardware Key Protection]
        D3[✅ Works with CDNs/LBs]
        D4[✅ Browser Sessions]
        D1 --> D2
        D2 --> D3
        D3 --> D4
    end
    
    style TC2 fill:#ff6b6b,color:#fff
    style TB2 fill:#ff6b6b,color:#fff
    style D2 fill:#51cf66,color:#fff
    style D3 fill:#51cf66,color:#fff
    style D4 fill:#51cf66,color:#fff
    style DP2 fill:#51cf66,color:#fff

As mentioned, Token Binding attempted to bind the session to the TLS layer.

• Token Binding: Required support from the client, the server, and every hop in between (Load Balancers, TLS Terminators). It broke when a connection was terminated and re-encrypted.
• DBSC: Operates at the HTTP application layer. It passes through Load Balancers transparently as standard headers/cookies. It is much easier to deploy in modern cloud architectures (AWS/GCP/Azure) where TLS is often handled by the cloud provider's edge network.

DPoP (RFC 9449) is the standard for "sender-constrained" OAuth tokens. It binds both access tokens and refresh tokens to a public key—critical since refresh tokens are long-lived bearer credentials themselves. Each API request includes a DPoP proof: a signed JWT with HTTP method, URL, timestamp, and unique identifier. High-assurance specs like FAPI 2.0 mandate sender-constrained tokens; DPoP is the recommended method when mTLS is unavailable.

The key difference: DPoP keys live in the application context. Best practice is to use OS APIs for non-extractable storage, but this isn't enforced—many implementations keep keys in JavaScript-accessible memory. If an attacker can execute arbitrary code (XSS, malware), they can access DPoP keys or generate proofs on demand. DPoP stops token replay between different clients, but cannot protect a compromised browser context.

DBSC moves proof-of-possession into the browser and hardware. The private key lives in a TPM or secure enclave that JavaScript cannot read or export. The browser handles the protocol and produces signatures without exposing keys to application code. Even if the web app is fully compromised, an attacker cannot mint fresh proofs for stolen cookies on another machine.

Synergy: As the FIDO Alliance notes, passkeys eliminate phishing at login, while DBSC/DPoP protect post-authentication tokens. A modern architecture combines both: DPoP for OAuth APIs (especially regulated open banking), DBSC for browser sessions. Together they close the "lift and shift" attack vector across the entire session lifecycle.

Simply shortening cookie lifetimes (e.g., to 15 minutes) improves security but destroys UX. Users are forced to log in constantly. DBSC allows the effective security of a 5-minute cookie with the User Experience of a 30-day cookie.

%%{init: {
  "theme": "default",
  "themeVariables": {
    "actorBkg": "#ffffff",
    "actorBorder": "#000000",
    "noteBkgColor": "#f1f3f5",
    "noteTextColor": "#000000",
    "activationBkgColor": "#e0e0e0",
    "actorColours": {
      "ST": "#ff6b6b",
      "IdP": "#4c6ef5"
    }
  }
}}%%

sequenceDiagram
    participant ST as Security Tools<br/>(CrowdStrike, Defender)
    participant IdP as Identity Provider<br/>(Okta, Google, Azure)
    participant SP1 as Service Provider 1<br/>(Slack)
    participant SP2 as Service Provider 2<br/>(Salesforce)
    participant SP3 as Service Provider 3<br/>(Banking App)
    participant Session as User Session<br/>(DBSC Protected)
    
    Note over ST,Session: Threat Detection Phase
    ST->>ST: Detects malware on<br/>user's device
    ST->>IdP: RISC Signal:<br/>"Device Compromised"
    
    Note over IdP,SP3: Signal Propagation Phase
    IdP->>SP1: CAEP Event:<br/>"Device Compromised"
    IdP->>SP2: CAEP Event:<br/>"Device Compromised"
    IdP->>SP3: CAEP Event:<br/>"Device Compromised"
    
    Note over SP1,Session: Enforcement Phase (with DBSC)
    Session->>SP1: Next refresh attempt<br/>(within minutes)
    SP1-->>Session: x Reject signature
    Session->>SP2: Next refresh attempt
    SP2-->>Session: x Reject signature
    Session->>SP3: Next refresh attempt
    SP3-->>Session: x Reject signature
    
    Note over Session: Sessions can be terminated at next refresh attempt

DBSC's potential is amplified when combined with the Shared Signals Framework (SSF), specifically the Continuous Access Evaluation Profile (CAEP) and Risk Management (RISC). Note: SSF/CAEP is an emerging ecosystem capability—the architecture pattern is defined, but widespread cross-vendor deployment is still maturing.

In the old model, if a user's device was compromised, the Identity Provider (IdP) had no way to tell the Service Provider (SP) to kill the session right now. The SP would have to wait for the cookie to expire.

The envisioned DBSC + CAEP flow:

1. Trigger: An endpoint security tool (like CrowdStrike or Microsoft Defender) detects malware on the user's laptop.
2. Signal: The security tool sends a RISC signal to the Identity Provider (e.g., Okta/Google).
3. Propagation: The IdP pushes a CAEP event to connected apps: "Device Compromised."
4. Enforcement (DBSC): The next time the browser tries to refresh the DBSC short-lived cookie, the server rejects the signature and kills the session.
   This architecture pattern enables faster revocation—actual latency depends on the site's refresh period and whether they have implemented both DBSC and SSF.

The adoption of DBSC depends on browser vendors. The landscape in late 2025 is evolving, with Chrome running an Origin Trial and other browsers evaluating the standard.

Google is the primary driver of DBSC.

• Status: Chrome's second DBSC Origin Trial runs from October 2025 to early February 2026. New features include cross-site session support and a Secure-Session-Skipped diagnostic header. Currently limited to Windows with TPM hardware.
• Implementation: The current implementation only supports devices with TPMs on Windows. Support for other platforms will expand.
• Google Accounts: Separately, Google has rolled out DBSC-style protection for Google account cookies on Chrome for Windows, controlled via enterprise policy. This protects Gmail/Workspace but is distinct from the general web DBSC feature.

Microsoft is actively participating.

• Status: Edge ran a DBSC Origin Trial on Windows that ended October 2025. No replacement trial or GA has been announced.
• Enterprise Context: Edge utilizes the "Primary Refresh Token" (PRT) architecture for Entra/Azure AD SSO, which is conceptually similar to DBSC. PRT remains a Microsoft-specific mechanism; there is no announced plan to unify it with the DBSC web standard for third-party sites.

Apple's stance is critical for mobile coverage.

• Status: WebKit has a standards-position issue evaluating DBSC with noted usability/privacy concerns. Safari release notes do not mention DBSC. No public "actively implementing" statement exists.
• Privacy First: Apple's main concern is that DBSC could be used for "super-cookies" (undeletable tracking). The W3C spec addresses this by ensuring keys are cleared with website data.
• Engagement: WebKit is engaging with the standard process, but implementation status is unclear—"under discussion" rather than "under development."

Mozilla has a standards-position issue evaluating DBSC with noted concerns about complexity and privacy. There is no public commitment to implement once the standard stabilizes.

Given the current ecosystem support for DBSC and passkeys, organizations should take a phased approach to implementing these complementary technologies. Here are specific, actionable recommendations:

1. Deploy Passkeys First: Start with passkey implementation to secure the authentication layer. This provides immediate protection against credential phishing and prepares your infrastructure for DBSC.

2. Prepare for DBSC Origin Trials: Chrome offers a DBSC Origin Trial on Windows (Oct 2025 – Feb 2026). Consider enrolling high-value applications (admin panels, financial dashboards) to test DBSC before general availability.

3. Implement Short-Lived Sessions with Refresh Tokens: Even without DBSC, adopt the architectural pattern of short-lived tokens with refresh mechanisms. This prepares your backend for DBSC while improving security today.

1. Adopt a Hybrid Approach: Use feature detection to serve DBSC to capable browsers while maintaining fallback options. This maximizes security without excluding users.

2. Monitor Safari/Firefox Progress: Track WebKit and Firefox development. Plan for broader DBSC deployment as browser support moves from Origin Trial to stable release.

3. Integrate with Identity Providers: If using Okta, Auth0, or similar IdPs, work with them to enable DBSC support in their SDKs. Many are actively developing DBSC capabilities.

• Start with High-Value Targets: Prioritize DBSC for admin panels, financial transactions, and sensitive data access.
• Use Managed Solutions: Consider platforms like Corbado that handle the complexity of DBSC implementation and browser compatibility.
• Measure and Iterate: Track metrics like session hijacking attempts, support tickets, and user friction to demonstrate ROI.
• Prepare for Compliance: Document your DBSC implementation as it will likely become a compliance requirement for handling sensitive data.

Implementing DBSC from scratch is a heavy engineering lift. It requires cryptographic expertise, deep knowledge of browser inconsistencies, and a robust server-side infrastructure to manage keys and challenges. This is where Corbado serves as an enabler.

You cannot build a high-assurance session on top of a low-assurance login. If a user logs in with a weak password, the session is only as secure as that password. Corbado's core product (Passkeys-as-a-Service) provides the necessary foundation. By integrating Corbado, organizations can easily deploy passkeys, ensuring that the start of the session is phishing-resistant.

Corbado will leverage DBSC to enhance trusted device detection. When DBSC signals are available, they provide cryptographic proof that a session originates from a specific device allowing Corbado to increase authentication trust levels accordingly.

• Solving the Synced Passkey Ambiguity: Synced passkeys are convenient but create a trust gap: when a user authenticates with a synced passkey, you cannot tell if it's their usual laptop or a brand-new device that just synced the credential. DBSC closes this gap. By checking whether the device has an established DBSC binding, Corbado can verify the device is truly known and trusted, not just a first-time sync.
• Higher Trust for Known Devices: When DBSC signals confirm a device has been seen before, Corbado can make more confident risk decisions: fewer step-up authentication prompts for legitimate returning users, stricter scrutiny for sessions from unrecognized devices.
• Complementing Passkey Intelligence: DBSC signals integrate with Corbado's existing Passkey Intelligence engine. The combination of passkey-based authentication and DBSC-based device binding creates a complete trust chain from login through the entire session lifecycle.

For questions about how Corbado plans to integrate DBSC into its platform, reach out to the team.

For the next few years, the web will be hybrid. Some users will have DBSC-capable browsers (Chrome on Windows 11); others will be on older systems. Handling this fragmentation is difficult. Corbado's Passkey Intelligence engine is designed to handle exactly this kind of fallback logic serving passkeys to capable devices and fallbacks to others. This same intelligence applies to session binding, ensuring that security is maximized for every user according to their device's capabilities.

The era of the "Bearer Token" is drawing to a close. Current session management is failing catastrophically — bearer tokens can be stolen by industrial-scale malware operations and used from any device, enabling account takeovers that bypass even the strongest authentication methods. This fundamental vulnerability has created an underground economy worth billions.

Device Bound Session Credentials (DBSC) represents the industry's emerging answer. Unlike traditional secure cookies with their HttpOnly flags and static secrets, DBSC adds cryptographic proof-of-possession through device-bound keys. This makes stolen cookies far less valuable. They cannot be refreshed from another device. Where Token Binding failed by requiring complex TLS-layer changes across all infrastructure, DBSC succeeds by operating at the HTTP application layer, compatible with existing load balancers and CDN architectures. Note: DBSC has documented fallback paths where the browser skips binding (TPM unavailable, network errors), so it greatly reduces but does not eliminate cookie theft risk.

The synergy between DBSC and Passkeys significantly raises the bar for attackers across the user journey. Passkeys eliminate credential phishing at login, while DBSC makes session hijacking via remote cookie theft much harder—together forming the "high assurance" identity framework that FIDO Alliance envisions. With Chrome's Origin Trial on Windows running through February 2026, organizations can begin testing DBSC now to prepare for broader rollout.

For Product Managers, the business case is compelling: DBSC enables "infinite" secure sessions that dramatically reduce login friction while simultaneously cutting fraud losses and support costs. The ROI manifests in higher conversion rates, fewer password reset tickets, and eliminated account takeover incidents. Organizations using OAuth can leverage the same key-binding concept through DPoP for API tokens, while integration with Shared Signals (CAEP/RISC) enables real-time threat response — instantly revoking compromised sessions at the next refresh attempt.

Implementation doesn't require building from scratch. Platforms like Corbado provide passkey infrastructure and are tracking DBSC developments to integrate device-binding as browser support matures. The W3C specification is an active Working Draft, with Chrome's Origin Trial live through February 2026 and other browsers evaluating the standard.

The trajectory is clear: organizations that begin adopting Passkeys and DBSC today will be best positioned for the passwordless, phishing-resistant future. The question is not whether to implement device-bound sessions, but how quickly you can deploy them to protect your users and business. The future of web security is not just authenticated; it is cryptographically bound to the devices we trust.