Vercel binds logins to the device so a stolen session cookie fails elsewhere

When a cookie is bound to hardware, the question changes

When you sign in to a service, you prove who you are once. The service then gives your browser a small token, called a session cookie. The browser shows it on every later request, so you are not asked to log in again.

That makes the cookie a stand-in for the password. Whoever presents it is treated as the user. The risk this addresses is that a stolen cookie can be replayed from another machine.

Here is the idea this story argues. When a cookie is bound to hardware, the security question changes. It stops being "is the token secret?" and becomes "which devices and browsers are allowed to hold sessions?" That is a policy question, and someone in your organisation has to own it.

What Vercel announced

Vercel is gradually rolling out Device Bound Session Credentials, or DBSC, for logins to vercel.com. BleepingComputer reported it on November 4. Vercel is a platform where developers deploy sites, web applications and AI agents. It also develops the Next.js framework. Its CTO, Malte Ubl, announced the change on X.

The target is information stealer malware. That is software that copies stored data, including session cookies, from an infected computer. According to BleepingComputer, the feature binds a session to the user's device, so a stolen cookie cannot be reused on another device.

Ubl also said Vercel's security team shipped the feature internally a couple of months ago. He said it had already proven its worth. The report does not say whether anyone outside Vercel has tested it.

How it works

DBSC relies on a TPM, a security chip built into the computer. Ubl described it as the same kind of hardware that laptops and phones use for fingerprint sensors. Per Ubl, the chip holds a private key, and that key is used to sign the cookie.

The source gives no more detail than that. In general, schemes like this work in a few steps. Vercel has not published these steps in the source, so treat them as background, not as a description of its system. The browser creates a pair of keys and keeps the private one in the chip. The server links the session to the matching public key. The server can then ask for fresh proof that only the chip can produce. A copied cookie would arrive without that proof.

Ubl stated that the private key cannot be taken out of the chip again, by Vercel, by the user or by malware. That is the company's own claim about its feature.

BleepingComputer notes that DBSC sits alongside a Chrome protection called App-Bound Encryption. That protection makes it harder for infostealers to pull cookies out of the browser. One layer makes theft harder. The other aims to make a stolen cookie useless elsewhere.

One caution, offered as analysis. The protection described is about replay on a different device. The source does not say it defends against malware running on the user's own device.

The limits are the policy

The limits decide how far this goes. BleepingComputer says DBSC works today in Chrome, on macOS and on Windows. The rollout is gradual so that edge cases involving OAuth apps are handled. The report names no other browsers or systems.

It also covers one door. DBSC applies to logins on vercel.com. Vercel is rolling out a similar technology, DPoP, for its command-line tool, the Vercel CLI.

Read together, these limits show where the risk moves. A developer on an unsupported browser or system is outside the protection. So the real control is no longer only the cookie. It is the list of devices and browsers your staff may use to reach critical accounts.

The report also recalls an April breach at Vercel. It does not link that breach to session cookies or to vercel.com logins. It is mentioned here only for context, and nothing in this story suggests DBSC would have changed its outcome.

What to ask your team

This is one vendor's rollout, not proof of an industry shift. One way to read it is as a bet that cookies will sometimes be copied, so a copy should be hard to use. Vercel does not say this in the source. It is our interpretation.

Start with the accounts that can change production. Ask which of them still rely on cookies that any device can replay. Ask whether your cloud, code hosting and identity providers offer device-bound sessions, and on which browsers.

Ask what happens for staff on unsupported browsers or systems. If protection covers only Chrome on two operating systems, the gap is a policy decision. Name an owner for it.

Ask who decides which devices may hold sessions for sensitive systems, and how that list is kept current.

A stolen password was once the prize. With device binding, the prize shifts to the device itself, and the policy around it.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: BleepingComputer.