Security & Identity 30 Sep 2026 27 min read

Making a stolen session useless

How production systems try to make a copied session or access credential worthless to the thief, and why bearer tokens keep defeating every control short of binding.

A field guide to session and token theft, reconstructed from seven public incidents (Okta, Cloudflare x2, BeyondTrust, 1Password, GitHub, Meta, Storm-0558) and the standards now answering them (KEP-1205, DBSC, CAEP, RFC 9700, DPoP). It shows why the reflex controls after a theft, MFA, short lifetimes, rotation, leave the root fact untouched, gives a decision tree for which binding fits which holder, a five-class failure catalogue with transferable rules, and the residual-window number to measure per resource.

The finding that surprised me

The controls teams reach for after a session theft, MFA, shorter lifetimes, rotation, do not change the one fact that made it work: the server cannot tell the thief's copy from the owner's, because possession is the whole proof. Only binding the credential to something uncopyable changes that answer, and even binding has a documented ceiling.

What you get out of it

  • A bearer credential's blast radius is the population, not the known-stolen set: Facebook reset ~90M tokens and GitHub invalidated all sessions because neither could tell which copies existed.
  • Network or console binding alone is bypassable: BeyondTrust's console policy held, so the attacker drove the same stolen cookie through the admin API, which policy could not gate.
  • Revocation is a distributed-systems problem in disguise: a locally validated token has no recall channel, which is why Entra leaves a residual window of up to 90 minutes and only for CAE-capable apps.
  • The residual window is the number to measure, per credential and per resource; a resource with no revocation channel has the full token lifetime as its window.

Scope

Why this, now. DBSC shipped to Chrome 146 in April 2026 and CAEP reached 1.0 in August 2025, so the binding-and-revocation answer to a problem the 2023 Okta breaches made unavoidable is now concrete enough to design against rather than await.

What it does not cover. The login itself (MFA factor choice, phishing-resistant enrolment), authorization logic once identity is established, and secret management for issuing credentials, each covered by a sibling guide. Several cited hosts were unreachable from this session's egress proxy and their quotes were retrieved via web-search rather than direct fetch.

Open the field guide → Self-contained: it loads nothing at read time, follows your system theme, and prints cleanly.