The protection is narrower than the headlines suggest. It doesn't make malware harmless, and it isn't switched on for every account yet.
What Vercel announced
Vercel CTO Malte Ubl announced the rollout on X on November 3. BleepingComputer reported it the following day. The scope is Vercel's own platform login, where developers manage projects and deployments. It is not a feature that Vercel has turned on for sites its customers deploy.
Ubl described the mechanism this way: the private key sits in your device's TPM, the same kind of hardware a fingerprint sensor relies on, and is used to sign your cookie. He added that the key can never be retrieved, "Not by us, not by you, not by the malware."
Key details from the announcement:
- Gradual rollout. DBSC currently works in Chrome on macOS and Windows, but the rollout is gradual to ensure edge cases involving OAuth apps are handled appropriately. Ubl also said the technology is new enough that Vercel wants more experience deploying it. No percentages, completion dates or user-facing toggle were given.
- Browser support. Ubl said DBSC is currently supported only by Chrome on Mac and Windows. He said Vercel is working on a "polyfill" for other browsers, but that it is less secure than DBSC.
- Layered defense. The rollout complements Chrome's App-Bound Encryption, which makes it harder for infostealers to extract browser cookies. DBSC adds protection by stopping stolen cookies from being reused on other devices.
- CLI follow-up. Vercel is also rolling out a similar technology, DPoP, for the Vercel CLI. Ubl described it as the same idea for apps that run on your device. He said it is easier to roll out than DBSC because it doesn't depend on browser vendors. No CLI version or availability date was provided.
Why session cookies are the target
Google's explanation of DBSC describes the attack. Session theft typically begins when a user inadvertently installs malware. The malware then lifts existing session cookies from the browser, or waits for the user to log in to new accounts, and sends them to an attacker's server.
Google notes that because cookies often live a long time, attackers can use them to get into accounts without ever needing the password. That is why a stolen cookie can sidestep a strong password and even some multi-factor setups.
For a developer platform the stakes are high. A hijacked Vercel session could expose projects, deployments and environment variables. Vercel's own April breach, as BleepingComputer recounts, involved attackers viewing environment variables that hadn't been marked as sensitive. That breach started with a compromised employee account at a third party, not a stolen cookie, so DBSC wouldn't have addressed that particular incident.
How DBSC works
The mechanics come from Google's April 2026 write-up and the W3C draft specification.
- At login, the browser creates a public/private key pair. The private key sits in hardware-backed storage. Google names the TPM on Windows and the Secure Enclave on macOS.
- The browser registers the public key with the server.
- The server issues short-lived session cookies. Each refresh requires the browser to prove it still holds the private key.
- A stolen cookie therefore expires quickly and can't be renewed from another machine.
Google says each session has a separate key, and it should not be possible to detect that two session keys come from one device. That is meant to keep DBSC from becoming a tracking or fingerprinting tool. Google also says the browser handles the cryptography and cookie rotation, so web apps keep using standard cookies.
Ubl mentions only the TPM, but on a Mac the key lives in the Secure Enclave. Windows readers get the TPM version.
The limits
Ubl was candid that malware can still do bad things while residing on the device. His argument is that the abuse seen in practice separates the stealing from the later abuse, and DBSC breaks that split. The W3C draft says the same thing more formally:
- DBSC will not prevent temporary access to the browser session while the attacker is resident on the user's device. The key can't be exported, but the signing ability is likely still available to programs running as the user.
- It also won't stop an attack if the attacker replaces or injects into the browser at session registration. In that case the attacker could bind the session to a key that isn't TPM-bound, or to a TPM they control.
- DBSC isn't designed to tell a host which specific device a session is on, or what state that device is in.
Two practical consequences follow:
- Timing matters. Short-lived cookies can be replayed until they expire, as the Corbado analysis notes, but they can't be renewed without the key.
- Local malware is still a problem. A compromised machine can act as you for as long as the malware stays there. Endpoint protection, patching and careful installs still matter.
The W3C document is an editor's draft, not a finished standard.
What Windows users and admins should take from this
- Use Chrome for Vercel logins on Windows. That is the only Windows browser Vercel has named. Corbado's analysis says DBSC is listed in Edge 147, but Vercel hasn't said it supports Edge. Don't assume Edge or other browsers are covered.
- Check that your PC has a working TPM. Most Windows 11 hardware does. A machine without usable secure hardware is the case Google says it is still exploring, through software-based keys.
- Don't assume your account is protected yet. Vercel hasn't said when any given account will be included, and there is no setting to enable it.
- Keep the other layers. Vercel pairs DBSC with Chrome's App-Bound Encryption. You should still use strong sign-in methods, minimize secrets stored in dashboards, and watch for supply-chain malware. Ubl himself cited it as the sort of route through which infostealers arrive.
- Developers adopting DBSC elsewhere can learn from independent write-ups. Scott Helme's Report URI experience reports that DBSC degrades cleanly: browsers without support ignore the registration header, and the session carries on as a normal cookie session. He also described pitfalls, including a race that overwrote the binding data and a redirect on a DBSC endpoint that silently downgraded a session.
Wider context
DBSC isn't new. Chrome ran origin trials, and Google says it designed the standard with Microsoft's involvement. Google's April announcement said Windows availability was starting with Chrome 146. Secondary reports disagree on the exact Windows version, with one citing Chrome 145, so treat version numbers cautiously. Scott Helme's account says Chrome on macOS arrived with Chrome 147, with a gradual Chrome-side rollout.
Vercel's move is notable because a major developer platform is putting it in front of real users, along with the awkward OAuth cases that come with that. Ubl's view is that every website should use DBSC. Google's own results are encouraging: it reports a significant reduction in session theft for sessions protected by DBSC. That figure comes from Google, so it should be read as the vendor's claim.
Security Review, briefly
Separately, Vercel launched Security Review in public beta for Pro and Enterprise teams. Scans are free until November 10, 2026, while agent-generated fixes are billed separately. It's a different feature from DBSC.
Bottom line
Vercel's DBSC rollout makes a stolen session cookie much less useful off the victim's machine. That is a real improvement for developers using Chrome on Windows or macOS. It does nothing against malware that is still running on your PC, and the rollout is staged and limited to Chrome. Vercel is open about the rollout being gradual and about DBSC's limits, which is more than many security announcements manage.