--- url: 'https://www.corbado.com/blog/device-bound-session-credentials-dbsc' title: 'Device Bound Session Credentials (DBSC) explained' description: 'Learn how Device Bound Session Credentials (DBSC) prevent session hijacking & cookie theft. Learn about browser support status and enterprise security.' lang: 'en' author: 'Vincent Delitz' date: '2025-12-03T09:45:08.112Z' lastModified: '2026-03-27T07:01:54.145Z' keywords: 'Device Bound Session Credentials, DBSC, Session hijacking prevention, Cookie theft protection, TPM session binding' category: 'Authentication' --- # Device Bound Session Credentials (DBSC) explained **Browser Support Status** > **Latest:** Chrome's > [second DBSC Origin Trial](https://developer.chrome.com/blog/dbsc-origin-trial-update) > began October 2025 and runs until early February 2026. Now includes cross-site session > support and improved diagnostics. | Browser | Windows | macOS | Linux | Android | iOS | Status | | ----------- | --------------- | ------------- | ------------- | ------------- | ------------- | ---------------------------------------------------------------------------------------------------- | | **Chrome** | 🧪 Origin Trial | ❌ | ❌ | ❌ | ❌ | [2nd Origin Trial](https://developer.chrome.com/blog/dbsc-origin-trial-update) (Oct 2025 – Feb 2026) | | **Edge** | ⏸️ Trial ended | ❌ | ❌ | ❌ | ❌ | Origin Trial ended Oct 2025, no GA announced | | **Safari** | N/A | 🔄 Evaluating | N/A | N/A | 🔄 Evaluating | WebKit discussing, no implementation announced | | **Firefox** | 🔄 Monitoring | 🔄 Monitoring | 🔄 Monitoring | 🔄 Monitoring | 🔄 Monitoring | Evaluating, no commitment to implement | **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** | **Feature** | **Current cookie model** | **DBSC model** | | --------------------- | ---------------------------- | ---------------------------------- | | **Token type** | Bearer (possession = access) | Bound (possession + key = access) | | **Theft consequence** | Total account takeover | Useless token (cannot refresh) | | **Session duration** | Short (for security) | Long / infinite (secure by design) | | **User friction** | High (frequent logins) | Low (invisible security) | | **MFA bypass** | Vulnerable (pass-the-cookie) | Resistant (device required) | | **Revocation** | Slow (wait for expiry) | Near real-time (fail next refresh) | ## Key Facts - **DBSC** binds web sessions to a device-held cryptographic key, making stolen cookies useless because they cannot be refreshed from another device. - The browser stores a non-exportable private key in a **TPM**, signing server challenges every 5 minutes to prove device possession without user interaction. - Unlike **Token Binding**, which failed due to TLS-layer infrastructure complexity, DBSC operates at the HTTP application layer and works transparently with existing load balancers and CDNs. - Chrome's **second DBSC Origin Trial** runs October 2025 to February 2026, currently limited to Windows with TPM. Safari and Firefox are evaluating but have not committed to implementation. ## 1. Introduction: Device Bound Session Credentials (DBSC) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/vulnerability) has given rise to an industrial-scale underground economy of "cookie theft" and "[session hijacking](https://www.corbado.com/blog/3ds-authentication-failed)". 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](https://www.corbado.com/glossary/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](https://www.w3.org/TR/dbsc/). 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/oauth2)? 9. How does DBSC integrate with Shared Signals (CAEP/RISC) for real-time threat response? ## 2. Understanding the Core Problems and Solutions 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](https://www.corbado.com/glossary/vulnerability) or limitation that DBSC addresses. ### 2.1 Failure of current Session Management 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](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies) (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](https://www.corbado.com/glossary/malware) running on the host device. "Infostealers" are [malware](https://www.corbado.com/glossary/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](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html), injecting the stolen token into their own browser to hijack the session. The server, seeing a valid cookie, assumes the request is legitimate. ### 2.2 DBSC's Cryptographic Advantage over traditional secure Cookies 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](https://www.w3.org/TR/dbsc/) "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. ### 2.3 Synergy between Passkeys and DBSC 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](https://www.corbado.com/glossary/phishing). DBSC addresses the _post-authentication_ problem making [session hijacking](https://www.corbado.com/blog/3ds-authentication-failed) via cookie theft significantly harder. The [FIDO Alliance frames DBSC](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) as a complementary technology that "raises the bar" against [session hijacking](https://www.corbado.com/blog/3ds-authentication-failed). Together, they reduce the attack surface across login and session lifecycle though DBSC does not protect against [malware](https://www.corbado.com/glossary/malware) with ongoing device access or real-time browser-in-the-middle attacks on the same device. | Technologies | Remote Phishing | Credential Stuffing | Token Theft | | -------------------------- | --------------- | ------------------- | ----------- | | **Passkeys** | ✅ | ✅ | ❌ | | **DBSC / DPoP** | ❌ | ❌ | ✅ | | **Passkeys + DBSC / DPoP** | ✅ | ✅ | ✅ | **How Passkeys and DBSC work together** | **Aspect** | **Passkeys** | **DBSC** | **Combined benefit** | | -------------------- | -------------------------------------- | -------------------------------------- | ---------------------------------------------- | | **Scope** | Authentication (login) | Session management | End-to-end protection | | **Threat mitigated** | Password phishing, credential stuffing | Remote session hijacking, cookie theft | Significantly raised bar for account takeover | | **User experience** | Passwordless login | Transparent session protection | Seamless, secure experience | | **Key storage** | Device-bound or synced credentials | Device-bound (HSM when available) | Flexible authentication, rigid session binding | | **Deployment** | Replaces passwords | Enhances existing sessions | Incremental security improvements | ### 2.4 Learning from Token Binding's Failure 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)](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). It does not depend on the underlying network connection, making it compatible with existing load balancers, proxies and cloud infrastructure. ### 2.5 Business Implications and ROI Opportunities 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. ## 3. Threat Landscape: Industrialization of Cookie Theft 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. ### 3.1 Rise of Infostealers ```mermaid graph TD A[User Downloads
Malicious Software] -->|Execution| B[Infostealer Activates
on Device] B --> C[Locates Browser Data] C --> D[Chrome/Edge/Firefox
Cookie Storage] C --> E[Password Database] C --> F[Crypto Wallets] D --> G[Decrypts Using
OS Credentials] E --> G F --> G G --> H[Creates Log File
with Stolen Data] H --> I[Exfiltrates to C2 Server] I --> J[Dark Web Marketplace] J --> K[Attacker Purchases Log] K --> L[Imports Cookie to
Own Browser] L --> M[Bypasses MFA] M --> N[Account Takeover
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](https://www.corbado.com/blog/passkey-webauthn-database-guide) 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](https://www.corbado.com/blog/digital-wallet-assurance) keys. ### 3.2 Market for "Logs" These logs are aggregated and sold on dark web [marketplaces](https://www.corbado.com/passkeys-for-e-commerce) 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](https://www.corbado.com/blog/passkeys-amazon-cognito) 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](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc), appearing to the server as the user returning to an active tab. ### 3.3 Google Workspace & Microsoft Entra Threat 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](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html) 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](https://www.corbado.com/blog/2sv-vs-2fa) / passkeys stops) to cookie theft (which [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / passkeys often doesn't stop). ### 3.4 Limits of "Device Fingerprinting" Historically, risk engines have tried to detect session theft by analyzing device fingerprints, looking at the [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) 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. ## 4. Technical Architecture: How DBSC works Device Bound Session Credentials (DBSC) introduces a [standardized API and protocol](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) 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. ### 4.1 Core Components | **Component** | **Description** | **Role in DBSC** | | -------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | **User agent (browser)** | The client application (Chrome, Edge, etc.). | Manages the key pair, handles the HSM interaction, and intercepts network requests to attach proofs. | | **Relying party (server)** | The web application (e.g., banking portal). | Issues challenges, verifies signatures, and manages the session lifecycle. | | **Key storage** | Secure storage (TPM, Secure Enclave, or other) | Stores the private key. Chrome uses TPM on Windows when available; spec is agnostic about implementation. | | **Session cookie** | A standard HTTP cookie. | Used as the bearer token, but with a very short lifespan (e.g., 5-10 minutes). | | **Proof of possession** | A cryptographic signature. | A JWT sent by the browser to prove it still has the private key. | ### 4.2 DBSC Protocol Lifecycle The DBSC lifecycle allows a seamless transition from a standard session to a bound session, ensuring backward compatibility and progressive enhancement. ```mermaid 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 ``` #### 4.2.1 Phase 1: Initiation and Binding 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](https://www.corbado.com/glossary/attestation)). ``` HTTP POST /auth/dbsc/register HTTP/1.1 Content-Type: application/jwt \.\.\ ``` 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." #### 4.2.2 Phase 2: Short-lived Cookie Loop 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. #### 4.2.3 Phase 3: Refresh (Proof of Possession) 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: \ Secure-Session-Response: \ ``` 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](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). ### 4.3 Implementation Nuances #### 4.3.1 "Lift and Shift" Defense ```mermaid graph LR subgraph "Victim's Device" A[User Session
with DBSC] B[HSM/TPM
Private Key] C[Cookie +
Session ID] A --> B A --> C B -.->|Non-exportable| X[Cannot Extract
Private Key] end subgraph "Attack Scenario" D[RedLine Stealer
Infects Device] D --> E[Steals Cookie
& Session ID] E --> F[Exports to
Attacker] end subgraph "Attacker's Device" G[Imports Stolen
Cookie] H[Attempts to
Use Session] I[Server Requests
DBSC Refresh] J[Cannot Sign
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. #### 4.3.2 Scope and Privacy Privacy is a central design goal of DBSC. The [W3C specification](https://www.w3.org/TR/dbsc/) 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. #### 4.3.3 Server-side Considerations 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. ## 5. Business and Product Implications Beyond the technical specifications, DBSC carries significant implications for business strategy, product roadmaps, and compliance postures. ### 5.1 ROI of Frictionless Security Security initiatives are often viewed as cost centers or friction generators. DBSC flips this narrative. The following diagram illustrates how device-binding creates a cascade of business benefits: - **Fraud Reduction:** By neutralizing the primary vector for Account Takeover (ATO), businesses can save millions in fraud losses. - **Support Costs:** Account recovery is expensive. [Preventing the hack in the first place](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) directly reduces this operational burden. - **Conversion Optimization:** In [e-commerce](https://www.corbado.com/passkeys-for-e-commerce), every login prompt is a potential drop-off point. DBSC allows for aggressive "keep me logged in" policies, enabling instant checkout without password prompts. ### 5.2 Compliance and "State of the Art" 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](https://www.corbado.com/passkeys-for-payment) Services Directive 2 requires "[Strong Customer Authentication](https://www.corbado.com/faq/sca-psd2-importance)" (SCA). While SCA focuses on login, the [dynamic linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) of the session to the device aligns perfectly with the directive's goals of binding authentication to specific amounts and payees. ### 5.3 High Assurance vs. Moderate Assurance The [FIDO Alliance whitepapers](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/) highlight the concept of "Assurance Levels". - **Moderate Assurance:** Uses synced passkeys (like those in [iCloud Keychain](https://www.corbado.com/glossary/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](https://www.corbado.com/passkeys-for-banking), the organization may enforce a policy that _only_ allows access from sessions bound to a specific [managed device](https://www.corbado.com/blog/passkeys-managed-ios-android-testing). DBSC provides the technical enforcement mechanism for this policy. ## 6. DBSC vs. Alternatives To fully appreciate DBSC, we must compare it against other technologies that have attempted to solve similar problems. ```mermaid 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 ``` ### 6.1 DBSC vs. Token Binding 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](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). 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. ### 6.2 DBSC vs. DPoP (Demonstrating Proof of Possession) [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) 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](https://openid.net/specs/fapi-2_0-security-profile.html) 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](https://www.corbado.com/glossary/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. | Aspect | DPoP | DBSC | | ------------------ | ------------------------------------ | ------------------------ | | **Target** | OAuth access + refresh tokens | Browser session cookies | | **Key storage** | App context (best practice: OS APIs) | Hardware-backed (TPM) | | **XSS resistance** | ⚠️ Implementation-dependent | ✅ Keys unexportable | | **Primary use** | Native apps, SPAs, FAPI 2.0 | User-facing web sessions | **Synergy:** As the [FIDO Alliance notes](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/), 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](https://www.corbado.com/passkeys-for-banking)), DBSC for browser sessions. Together they close the "lift and shift" attack vector across the entire session lifecycle. ### 6.3 DBSC vs. Short-lived Cookies (Alone) 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. ## 7. Shared Signals and Dynamic Response (CAEP/RISC) ```mermaid %%{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
(CrowdStrike, Defender) participant IdP as Identity Provider
(Okta, Google, Azure) participant SP1 as Service Provider 1
(Slack) participant SP2 as Service Provider 2
(Salesforce) participant SP3 as Service Provider 3
(Banking App) participant Session as User Session
(DBSC Protected) Note over ST,Session: Threat Detection Phase ST->>ST: Detects malware on
user's device ST->>IdP: RISC Signal:
"Device Compromised" Note over IdP,SP3: Signal Propagation Phase IdP->>SP1: CAEP Event:
"Device Compromised" IdP->>SP2: CAEP Event:
"Device Compromised" IdP->>SP3: CAEP Event:
"Device Compromised" Note over SP1,Session: Enforcement Phase (with DBSC) Session->>SP1: Next refresh attempt
(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)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/), 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](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) enables faster revocation—actual latency depends on the site's refresh period and whether they have implemented both DBSC and SSF. ## 8. Browser and Ecosystem Support 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. ### 8.1 Google Chrome Google is the primary driver of DBSC. - **Status:** Chrome's [second DBSC Origin Trial](https://developer.chrome.com/blog/dbsc-origin-trial-update) 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](https://groups.google.com/a/chromium.org/g/blink-dev/c/O7Z9DF9AT8Y). Support for other platforms will expand. - **Google Accounts:** Separately, Google has rolled out DBSC-style protection for [Google account cookies on Chrome for Windows](https://support.google.com/chrome/a/answer/2657289), controlled via enterprise policy. This protects Gmail/Workspace but is distinct from the general web DBSC feature. ### 8.2 Microsoft Edge & Windows Microsoft is actively participating. - **Status:** Edge ran a [DBSC Origin Trial](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d) on Windows that ended October 2025. No replacement trial or GA has been announced. - **Enterprise Context:** Edge utilizes the ["Primary Refresh Token" (PRT) architecture](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token) for Entra/Azure AD [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-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. ### 8.3 Apple Safari (WebKit) Apple's stance is critical for mobile coverage. - **Status:** WebKit has a [standards-position issue](https://github.com/WebKit/standards-positions/issues/281) 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." ### 8.4 Mozilla Firefox Mozilla has a [standards-position issue](https://github.com/mozilla/standards-positions/issues/912) evaluating DBSC with noted concerns about complexity and privacy. There is no public commitment to implement once the standard stabilizes. ## 9. Recommendations: Protecting Users Today Given the current ecosystem support for DBSC and passkeys, organizations should take a phased approach to implementing these complementary technologies. The roadmap below outlines immediate actions and strategic planning milestones: ### 9.1 Immediate Actions (Q1 2025) 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. ### 9.2 Strategic Planning (2025-2026) 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](https://www.corbado.com/blog/auth0-passkeys-analysis), or similar IdPs, work with them to enable DBSC support in their SDKs. Many are actively developing DBSC capabilities. ### 9.3 Implementation Best Practices - **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. ## 10. How Corbado can help: Bridge to the Future 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. ### 10.1 Foundation: Passkeys 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. ### 10.2 Future: DBSC for Trusted Device Detection 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](https://www.corbado.com/blog/device-bound-synced-passkeys), 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](https://www.corbado.com/glossary/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**](https://docs.corbado.com/corbado-connect/features/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](https://www.corbado.com/contact). ### 10.3 Graceful Fallback (the "Hybrid" Reality) For the next few years, the web will be hybrid. Some users will have DBSC-capable browsers (Chrome on [Windows 11](https://www.corbado.com/blog/passkeys-windows-11)); others will be on older systems. Handling this fragmentation is difficult. Corbado's [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/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. ## 11. Conclusion: Path Forward for DBSC 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkey-adoption-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](https://www.corbado.com/blog/logins-impact-checkout-conversion), fewer [password reset](https://www.corbado.com/blog/password-reset-increase-customer-retention) 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](https://www.corbado.com/features) provide passkey infrastructure and are tracking DBSC developments to integrate device-binding as browser support matures. The [W3C specification](https://www.w3.org/TR/dbsc/) 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. ## Frequently Asked Questions ### How does DBSC work with CAEP and RISC to revoke compromised sessions in real time? When endpoint security tools like CrowdStrike detect malware, they send a RISC signal to the Identity Provider, which pushes a CAEP 'Device Compromised' event to connected apps. At the next DBSC refresh attempt (within minutes), those apps reject the session signature and terminate access. Cross-vendor CAEP/RISC deployment is still maturing. ### What is the difference between DBSC and DPoP for protecting web application sessions? DPoP (RFC 9449) binds OAuth access and refresh tokens to a public key at the application layer, primarily protecting API calls in native apps and SPAs. DBSC binds browser session cookies to hardware-backed TPM keys that JavaScript cannot read or export, protecting user-facing sessions even when the web app itself is compromised by XSS or malware. ### Why does DBSC allow longer session durations without increasing security risk? Traditional secure design mandates short session timeouts to limit damage if a cookie is stolen and replayed remotely. DBSC binds refresh capability to the originating device's private key, so a stolen cookie used from a different device fails the cryptographic challenge. Sessions can be effectively indefinite because remote replay attacks are neutralized. ### What business ROI can enterprises expect from deploying DBSC? DBSC neutralizes cookie theft as the primary Account Takeover vector, directly reducing fraud losses and account recovery support costs. Secure long sessions eliminate repeated login prompts, improving conversion rates in e-commerce and reducing drop-off. The FIDO Alliance positions DBSC as raising the security bar while simultaneously lowering user friction.