MFA Did Not Save You: Session Defence in 2026

Q: If I have MFA enabled, how can an attacker still take over the account?

Because MFA protects the authentication step, and modern session theft happens after authentication. When you log in and pass MFA, the server issues a session cookie or an OAuth access token that proves you already authenticated. That token is a bearer credential: by design, whoever presents it is treated as the authenticated user, with no password and no second factor required on subsequent requests — that is the entire point of a session, so you are not challenged on every click. Infostealer malware exploits exactly this. It does not attack your login; it reads the session cookie or token out of the browser or off disk, exfiltrates it, and the attacker replays it from their own machine. Your MFA never fires again because the token already represents a completed, MFA-passed login. This is why an organisation can truthfully say both "we enforce MFA" and "we had an account takeover" about the same incident. The lesson is that MFA and session security are different problems. Hardening the front door does nothing about a key that has already been cut and then copied, which is what a stolen bearer token is.

Q: What is a sender-constrained token and how is it different from a bearer token?

A bearer token is usable by anyone who holds it — like cash, possession is the whole entitlement, so a copy works exactly as well as the original. A sender-constrained token, by contrast, is cryptographically bound to a specific client, and using it requires proving possession of a secret the legitimate client holds. The recipient will only accept the token if the presenter can demonstrate knowledge of that secret on the request, so a copy of the token alone is worthless. Concretely, the client holds a private key, and every time it uses the token it must produce a fresh signature that proves it still has the key. An attacker who steals the token but not the private key cannot generate that proof, so the token is rejected at the first call. The OAuth 2.0 Security Best Current Practice, published as RFC 9700 in January 2025, explicitly recommends sender-constraining access tokens for exactly this reason. The two standard mechanisms are DPoP, which works at the application layer, and mutual TLS as defined in RFC 8705, which binds the token to a TLS client certificate. The shift from bearer to sender-constrained is the single most important session-security decision available in 2026, because it changes a stolen token from game-over into a non-event.

Q: What is DPoP and how does it stop token theft?

DPoP — Demonstrating Proof of Possession, standardised as RFC 9449 — is an application-layer mechanism for sender-constraining OAuth access and refresh tokens. It works like this: the client generates a public/private key pair, and on every token request and every resource request it includes a DPoP header containing a signed JSON Web Token proving it holds the private key. The authorization server binds the issued access token to the public part of that key pair. From then on, the resource server accepts the token only when it arrives alongside a valid, fresh proof signed by the matching private key. The security consequence is direct: if an infostealer exfiltrates the access token but not the private key — and the private key never travels in the token, so it usually does not leave the client — the attacker cannot produce the proof, and the stolen token fails at the very first request. DPoP is attractive because it is application-layer, meaning you can adopt it without the infrastructure lift that mutual TLS requires, which makes it the pragmatic default for public OAuth clients and APIs. It is also now one of the two sender-constraint mechanisms required for FAPI 2.0 compliance in financial-grade API deployments, so for regulated flows it is increasingly not optional.

Q: What is DBSC and do I need it if I already use DPoP?

Device Bound Session Credentials is Google Chrome mechanism for binding browser session cookies to the device, and it addresses a different surface than DPoP, so the two are complementary rather than alternatives. DPoP protects OAuth tokens at your application and API layer; DBSC protects the browser cookie that carries a web session. When a DBSC session is created, the browser generates a public/private key pair and stores the private key in hardware-backed storage — the Trusted Platform Module on Windows or the Secure Enclave on macOS — from which it cannot be exported. During the session the browser periodically proves possession of that key to refresh the cookie. A cookie stolen by an infostealer cannot be refreshed from another machine because the thief does not have the non-exportable device key, so the stolen cookie quickly becomes useless. DBSC reached general availability in Chrome 146 on Windows in April 2026, with macOS Secure Enclave support following. If your users authenticate through a browser, DBSC closes the cookie-theft path that DPoP on your APIs does not touch, so a defence-in-depth posture wants both: DBSC for the browser session and DPoP or mTLS for the tokens your services exchange.

Q: Are bearer tokens always insecure and should I stop using them entirely?

Bearer tokens are not always insecure, but they are always replayable, and that single property is what the infostealer economy monetises, so you should treat unconstrained bearer tokens as acceptable only for low-risk, short-lived contexts. The reason bearer tokens became ubiquitous is that they are simple: no key management, no per-request signing, easy to pass between services. That simplicity is fine when the token grants little, expires fast, and never leaves a trusted boundary. It stops being fine the moment the token grants meaningful access, lives long enough to be worth stealing, or sits somewhere malware can read it — which describes most real session and API tokens. The pragmatic policy is not to ban bearer tokens outright but to sender-constrain anything that matters, keep everything short-lived, and rotate refresh tokens. Where you cannot yet adopt DPoP or mTLS, aggressively shorten lifetimes and add post-authentication anomaly detection so a replayed token has a small window and a good chance of tripping an alarm. The direction of travel, set by RFC 9700, is clearly toward sender-constraining by default, and new systems should design for it from the start rather than retrofitting after an incident.

Q: Does DPoP or DBSC fully prevent session hijacking?

No, and it is important to be honest about the limits, because overclaiming leads teams to skip the monitoring that catches what binding misses. Both mechanisms defeat the dominant attack — bulk theft and remote replay of cookies and tokens — by making a stolen credential useless without a private key the attacker did not get. But both have documented gaps. DBSC has fallback paths where the browser skips binding, for example when a hardware TPM is unavailable or a network error occurs, so it sharply reduces but does not eliminate cookie theft risk. More fundamentally, if malware is already resident on the device at the exact moment a session is registered, it may be able to capture the private key during creation, which reproduces the hijack. That attack is significantly more complex, more targeted, and more detectable than commodity cookie theft, but it is real. The correct mental model is that sender-constraining raises the attacker cost from "copy a file and replay it anywhere" to "compromise a specific device at a specific moment." That defeats the entire mass-harvest business model, which is the bulk of real-world incidents, without pretending to defeat a determined adversary who already owns the endpoint. That residual risk is exactly why live-session anomaly scoring remains necessary alongside binding.

Q: Do AI agents and service accounts need session protection too?

Yes, and they are frequently the most dangerous case, because non-human identities tend to hold the longest-lived and highest-scope credentials in the system while receiving the least attention. A human session might last hours; a service account or CI token can be effectively permanent, and an AI agent may hold a token with broad authority to call tools, read data, and mutate systems. If any of those is a static bearer secret sitting in an environment variable or config file that many processes can read, it is a far richer target than a single user session — one theft yields durable, powerful access. The same rules apply and matter more: issue short-lived, sender-constrained credentials via a workload-identity mechanism rather than static secrets, scope them to least privilege, and rotate them. For AI agents specifically, this ties directly into fine-grained authorization, because the blast radius of a stolen agent token is a function of what the agent was allowed to do. A theft policy that hardens browser sessions but leaves agent and service-account tokens as long-lived, broadly-scoped bearer secrets has protected the smaller credential and left the larger one exposed, which is the common and backwards outcome.

Q: If I only have time for one change, what should I do first?

Shorten access-token lifetimes and turn on refresh-token rotation with reuse-detection, because it is the highest ratio of risk reduction to implementation effort and it requires no client-side changes or new cryptography. Most session-theft damage comes from tokens that are valid for hours or days, giving an attacker a comfortable window to exfiltrate and replay. Cutting access-token lifetime to minutes shrinks that window dramatically, so even an unbound, stolen token often expires before it is useful. Adding refresh-token rotation means each refresh issues a new token and invalidates the old one; if a stolen refresh token is later replayed, the server sees a reused, already-invalidated token and can treat that as a theft signal — turning a silent compromise into a fired alarm and an opportunity to kill the session. This buys you time and detection while you plan the larger work, which is sender-constraining with DPoP or mTLS and device-binding browser sessions with DBSC. Do the lifetime-and-rotation change first because it is fast and universally applicable, then sequence the binding work by risk, starting with your highest-value tokens and your non-human identities.