We rolled out Device Bound Session Credentials to every Report URI login
Since 1st September 2026, every single login to Report URI has been offered a Device Bound Session Credential. That's 100% of our users, on the live site, all day, every day.
As far as we can tell, this makes Report URI one of the first production deployments of DBSC outside Google anywhere in the world.
This blog post covers what we shipped, how we rolled it out, and what the real numbers look like now that it's on for everybody in production.
The problem DBSC solves
Your typical session cookie is a bearer token, and those few words really summarise the problem quite well actually!
No matter how strong we make account authentication, with long passwords, password managers, TOTP, 2FA, and now passkeys, the result of that whole process is a simple string of characters.
Set-Cookie: __Host-report_uri_sess=b7e4d1c0a9f2438e5c6b0d17a2f93e84Anyone who holds that string of letters and numbers becomes me, so all you have to do is find a way to steal it from me. If you want to read about how InfoStealer malware has become exceptionally good at stealing cookies, you can read my introductory blog post on DBSC: Device Bound Session Credentials: Making Stolen Cookies Useless. This blog post is instead going to focus on the success of the DBSC Beta at Report URI, and what that looks like.
What success looks like
Weirdly, I bet absolutely nobody has noticed that we've done this, unless you've been paying really close attention to the dev tools in your browser, or reading our blog posts of course. That's because DBSC requires absolutely nothing from the visitors to our site, with no prompt to click or enrolment to complete, it's completely invisible.
We do surface the information in our account section, so you can go check it out on the Settings page if you like:
Your browser will also tell you in dev tools (if your browser supports DBSC), but other than that, you get this awesome level of protection with no visible cues.
How we rolled it out
The first DBSC code landed in our codebase on 7th May 2026, behind a beta flag that allowed staff admins to opt individual users into DBSC. The first people that joined the beta were the Report URI staff, and things moved quite quickly from there.
| Date | What happened |
|---|---|
| 7 May 2026 | First implementation, beta flag, staff only |
| 16 May 2026 | Server logic extracted into an open-source library |
| 19 May 2026 | First refresh collapsed to a single round trip |
| 13 Jul 2026 | Stopped redirecting from DBSC endpoints |
| 25 Jul 2026 | Open beta sampled rollout at 1% of logins |
| 10 Aug 2026 | 10% |
| 20 Aug 2026 | 25% |
| 26 Aug 2026 | 50% |
| 1 Sep 2026 | 100% |
| 4 Sep 2026 | Beta flag deleted |
It only took us just under four months to go from our first code hitting production to a rollout on 100% of logins, and I think that's pretty good going. To help other organisations use DBSC we open-sourced our DBSC code as dbsc-php, I wrote a blog post covering Everything I Learned Shipping Device Bound Session Credentials, and I launched DBSC.dev to help with debugging and better understanding DBSC.
The numbers
100% of logins to Report URI are now offered DBSC, but of course the question of whether or not the browser supports it still remains. The more interesting question then becomes how many sessions actually end up bound to a physical device.
I pulled the numbers at the time of writing and I'm seriously impressed to see that more than two thirds (67.7%) of our currently active sessions are using DBSC.
This is effectively a measurement of the DBSC-capable browser share among our logged-in users, meaning that everyone was offered DBSC, and these are the browsers that called back to register. Also, it's probably worth considering that our users are overwhelmingly security professionals and developers, so our browser mix is unlikely to be a typical browser mix, and your mileage may vary as a result, but it still looks good.
What's next
For now, our part is done and we continue to monitor for the deployment of DBSC across more and more browsers. Chrome on Windows has full support already and Chrome on macOS support has landed and is currently rolling out across the population in stages. Beyond more client support, we also need more server support, and I hope the tools and resources linked above that we've made freely available will help with that.
If you run a site with login sessions that are worth stealing, DBSC is ready to go now. It took us four months, but much of that was learning the things that are now written down or open sourced above, so hopefully, it shouldn't take you as long.
