Token Theft in 2026: What CAE and DBSC Actually Cover, and What Your SIEM Still Has to Catch

Phishing-resistant MFA was supposed to retire the credential-stealing era. It mostly did, for credentials. What replaced it is worse for defenders in one specific way: the attacker no longer needs the password, the TOTP, or the FIDO2 assertion. They need the cookie that gets minted after all of that succeeds. By 2026 the dominant identity attack against Entra ID tenants is not password spraying and it has not been for a while — it is session token theft, delivered through either an AitM reverse-proxy phish or an infostealer pulling cookies straight out of the browser profile on an unmanaged device. The auth events look clean. MFA satisfied. Conditional Access satisfied. The token is just being replayed somewhere it shouldn’t be.

Microsoft has shipped two pieces of machinery that are supposed to close this: Continuous Access Evaluation (CAE), which is GA and has been for a while, and Device Bound Session Credentials (DBSC), which Chrome started rolling out in earnest through 2025 and which Edge picked up shortly after. Both of them help. Neither of them is a full answer, and the gap between what marketing claims they cover and what the SIEM actually sees is where most teams get burned the first time.

What gets stolen, and what the replay actually looks like

Three token shapes matter here. The Primary Refresh Token (PRT), which lives on a joined or registered Windows device and is bound to the device key — that one is hard to lift cleanly and when it does get lifted (via a tool in the Mimikatz / ROADtools family running on the box itself) you have bigger problems than token theft. The access token, short-lived, usually an hour, scoped to a specific resource. And the session cookie set by login.microsoftonline.com plus the per-app cookies (ESTSAUTH, ESTSAUTHPERSISTENT, the SharePoint FedAuth/rtFa pair, the Outlook OWA cookies). The session cookies are the prize. They survive across access-token refreshes, and until DBSC binds them to a device key they are pure bearer credentials.

AitM frameworks — Evilginx and the half-dozen commercial phish kits that followed it — sit between the user and the real IdP, proxy the entire auth flow including MFA, and walk away with the cookie jar. Infostealers like the RedLine / Lumma / StealC lineage do the same thing without needing the user to click a link, by reading the browser’s local cookie store on whatever personal laptop the user keeps logged in. Both produce the same artifact: a valid session cookie, replayable from anywhere, against a tenant that already considers the session authenticated.

When the attacker replays, the SigninLog entry for the replay does not say AuthenticationRequirement: multiFactorAuthentication. It says singleFactorAuthentication because no fresh auth happened — the token was already good. This is the first thing analysts miss. They filter for failed MFA or risky sign-ins and the replay never shows up there because as far as the IdP is concerned, the replay isn’t a sign-in, it’s a session continuation.

What CAE actually does

CAE is event-driven token revocation. When a critical signal fires — user disabled, password reset, risky user detected, location policy change — the IdP pushes a revocation event to CAE-aware resource providers (Exchange Online, SharePoint, Teams, Graph) which then reject the existing access token on the next call and force a re-auth. The token lifetime extension up to roughly 28 hours is the part Microsoft puts in the deck. The revocation channel is the part that matters.

What CAE does not do: it does not detect the token theft itself. It is a propagation mechanism for a decision somebody — or some other system — already made. If your only “somebody” is Identity Protection’s built-in risk detections, you are relying on Microsoft’s heuristics to notice the replay, and those heuristics lean heavily on impossible-travel and anonymous-IP signals that any competent attacker routes around with a residential proxy in the user’s metro area. The cheap residential-proxy services are five dollars a month. Assume the attacker has one.

CAE is the right plumbing. It is not the detection.

What DBSC covers, and what it doesn’t

DBSC binds a session cookie to a non-exportable key in the browser’s TPM-backed key store. The server periodically challenges the browser to prove possession of the key; a stolen cookie replayed from another machine fails the challenge and the session ends. Chrome enabled it broadly during 2025, Edge followed, and Entra ID started honoring it for web-based sign-ins. For the AitM and infostealer cookie-grab cases against a DBSC-capable browser on a TPM-equipped host, this is real mitigation. Not theoretical. Real.

The holes are predictable. Firefox’s implementation is behind. Safari on macOS lags. Any non-browser OAuth client — and there are a lot of them, every Electron app, every mobile app using the system webview, every legacy desktop client doing ROPC against a service principal it shouldn’t — is not in scope. Mobile is the messy one: iOS and Android have their own attestation stories that don’t cleanly line up with DBSC, and the per-app cookie binding varies by client. And on unmanaged personal devices where the user has no TPM or the browser profile is sitting in a shared Chrome install, you get nothing.

So: DBSC closes the browser-on-corporate-laptop case, which is large but not the whole pie. The BYOD-checking-Outlook-on-the-couch case is still wide open and that case is probably half your token theft exposure depending on how permissive your Conditional Access is around unmanaged devices.

What the detection actually looks like in the SIEM

The replay-from-elsewhere pattern, in Entra’s SigninLogs (or AADSignInEventsBeta if you’re on Defender XDR’s advanced hunting schema), shows up as a successful interactive or non-interactive sign-in with these characteristics: AuthenticationRequirement == "singleFactorAuthentication" despite the user’s CA policy requiring MFA, a DeviceDetail.deviceId that is empty or does not match the user’s known device set, an IPAddress from an ASN the user has never been seen on, and frequently a UserAgent that doesn’t match the user’s normal client mix (the classic tell is an Outlook desktop UA from a user who has only ever used OWA, or a raw Python-requests UA from anybody).

A workable first-pass hunt is correlation across a 24-hour window: for each UserPrincipalName, find sign-ins where the ASN of IPAddress does not appear in that user’s prior 30-day ASN history AND DeviceDetail.deviceId is null or absent from the user’s device history, then filter to where at least one such session produced a subsequent Graph or Exchange activity. The reason for the activity correlation is volume — raw “sign-in from new ASN” in a tenant of any size will fire constantly. Mobile carrier NAT shuffles users across ASNs daily. VPN exit nodes rotate. Corporate egress through a CASB looks like a different ASN than home. You will get thousands of hits a day. Tying the suspect sign-in to a follow-on action — mailbox rule creation, mass file access in SharePoint, an unusual Add service principal credentials call — cuts the noise by roughly two orders of magnitude in most tenants.

Rough volume expectations in a 5,000-user tenant: untuned, the ASN-mismatch query alone returns somewhere in the tens of thousands of rows per day. Once you carve out the user’s prior 90-day ASN set (not 30 — 30 is too tight, people travel), the known mobile-carrier ranges for your geography, the corporate VPN concentrators, and any sanctioned third-party SaaS that proxies traffic on the user’s behalf, you should land in the low hundreds. From there, the device-ID + post-auth-activity correlation typically gets you to under twenty events a day worth a human look. Your mileage depends heavily on how much of your workforce is mobile-first and how permissive your CA policy is for unmanaged devices.

The field most teams miss on the first build: SessionLifetimePolicies. When a CA policy applies a sign-in frequency control and the session still extends past it, that delta is in there and it’s diagnostic. Also AuthenticationProcessingDetails — the entry with key "Legacy TLS (TLS 1.0, 1.1, 3DES)" or any of the family of legacy-protocol flags is rarer than it used to be but still surfaces the occasional EWS or IMAP client doing things no human is doing.

Where the first round of tuning has to go

The first week of any deployment of this detection is dominated by four false-positive sources, in roughly this order. Travel — users who actually went somewhere and your 30-day ASN window didn’t cover it. Mobile carriers — T-Mobile and Verizon in the US shuffle a single device across half a dozen ASNs in a week, and overseas carriers are worse. Sanctioned third-party integrations — anything with delegated Graph permissions making calls on behalf of users will look like a sign-in from the vendor’s ASN. And the long tail of personal-device OWA sessions where the user has technically been allowed by policy and the SOC just doesn’t know.

The carve-outs that buy you the most signal-to-noise: maintain a tenant-specific allowlist of ASNs (not IPs — ASNs) for known mobile carriers in your operating geographies, your VPN egress, your CASB egress, and the major SaaS vendors with delegated access. Don’t try to enumerate IPs; the ranges shift and you will spend a sprint chasing it. Allowlist by ASN, alert on everything else, and accept that you’ll re-tune the allowlist about once a quarter.

The thing nobody wants to hear: there is no clean detection for a replay from a residential proxy in the same metro as the user, on the same browser family, against a tenant that allows unmanaged devices. The IdP signals just aren’t there. The detection in that case has to come from the resource side — anomalous mailbox rule creation, anomalous file download volume, anomalous service principal modification — not from the auth event. If your IR runbook assumes the SIEM will catch the token replay at sign-in, rewrite it.

Remediation, and the gap CAE doesn’t close

When you confirm a replay: revoke the user’s refresh tokens (Revoke-MgUserSignInSession or the portal equivalent), disable the user, force a password reset, kill any service principal credentials the attacker may have added, and audit the last 24 hours of that user’s Graph and Exchange activity for persistence. CAE will push the revocation to the major resource providers in seconds to a couple of minutes — not instant, but close. Non-CAE-aware resources will honor the existing access token until it expires, up to its normal lifetime. For Graph and the big workloads this is fine. For some line-of-business apps still using v1 tokens against custom resource registrations, the access token will outlive the revocation by up to an hour. Plan for it.

The persistence step matters more than people give it credit for. Once an attacker has had a valid session for even ten minutes, the standard playbook is to add a credential or certificate to a service principal they have rights to, or to consent to a malicious OAuth app on the user’s behalf, or to create an inbox forwarding rule. Revoking the session does nothing about any of those. Hunt for Add service principal credentials, Consent to application, and inbox rule changes in AuditLogs for any user you’ve had to remediate, going back at least to the first suspect sign-in.

Control mapping

Nothing surprising in there. The point is that the detection work sits squarely in SI-4 and AU-6, and the policy work that determines whether the detection has a chance sits in AC-3 and IA-2 — and if you have not closed the unmanaged-device path in CA, no amount of SIEM tuning will save you.

The honest summary

CAE is good infrastructure. DBSC is real mitigation for the cases it covers. Neither replaces the hunt query. Token theft in 2026 looks like a clean sign-in from a residential IP in the right metro, no MFA prompt, and a quiet ten minutes of Graph activity before the user even closes their laptop. The detection has to come from the resource side and the auth side combined, the allowlist has to be maintained, and the IR playbook has to assume the access token will outlive the revocation for at least the worst-behaved app in your estate. If your current build doesn’t account for those three things, that’s the first round of tuning.