Token protection in Conditional Access binds sign-in tokens to devices

Token theft after MFA is still one of the most underestimated attack paths in Microsoft 365 environments. I keep running into tenants that treat MFA as the final line of defense, yet recent incidents show how attackers quietly pull session tokens off compromised machines and replay them somewhere else. Token protection, a Conditional Access session control, targets exactly this. At sign-in it ties the session token cryptographically to the device, which makes pass-the-token attacks much harder. Over the past few months I've watched more and more organizations move token protection out of the pilot phase and into production, not least because attackers keep refining their techniques.

Token protection binds the sign-in token to one device

The idea itself is simple. When a user signs in on a supported Windows device (currently Windows 10 or 11, Entra-joined or Hybrid-joined), the sign-in token is issued so that it is cryptographically bound to that specific device. An attacker who steals the token can't use it anywhere else, and the classic pass-the-token trick stops working. To turn it on, go to Entra admin center → Entra ID → Conditional Access → New policy and select "Require token protection for sign-in sessions" under Session controls. The important catch is that the policy only applies when both the client and the resource support token protection. In practice that puts Exchange Online, SharePoint Online, Teams and the Microsoft 365 desktop apps in scope, and only on supported Windows endpoints.

Before starting, I always read through the official documentation (Token protection overview). Microsoft updates it regularly with current limitations and supported scenarios.

Token protection leaves several gaps in real environments

A short pilot is enough to see that token protection doesn't cover everything. Browser sessions, macOS and mobile clients (Android/iOS), and many legacy or non-Microsoft applications fall outside it. Even on Windows you need Entra-joined or Hybrid-joined devices plus the latest desktop apps or Authenticator implementation. Classic browser logins remain unprotected, so strong authentication and other session controls are still your best defense there. The Microsoft Learn article (Conditional Access session controls) lists the supported platforms in detail and is kept current.

The protection is also limited to specific resources. Exchange Online, SharePoint Online and Teams are supported, but third-party SaaS apps and service principals are not. For service principals and workload identities, have a look at my post on Conditional Access for workload identities.

Report-only mode lets you test without breaking sign-ins

I always start a token protection rollout with report-only Conditional Access policies. That way you can gauge the impact without blocking legitimate user sign-ins. My usual setup is a policy targeting all users, with a device filter for Windows (Entra-joined/hybrid) and Exchange Online or Teams as the resource, set to report-only. You'll find the results in Conditional Access insights or directly in the sign-in logs (Entra admin center → Entra ID → Monitoring → Sign-in logs).

Practical tip: Include users with older devices or more complex setups (RDS, Citrix or VDI) in your pilot. I've seen sign-in problems appear when device join status or app versions didn't line up.

The sign-in log shows every token protection event

Once token protection is live, the sign-in log is the first place I go for troubleshooting. Every relevant event has a "Conditional Access" section that tells you whether token binding was enforced or a policy violation occurred. When a token is reused on a different device, the sign-in is blocked and clearly flagged. Filter the sign-in logs for the control "Token Protection" to find these events. The portal filter is fine for tenant-wide reporting. For deeper analysis, export the logs to a Log Analytics workspace (prerequisites: P1 or P2 licence, diagnostic settings enabled) and work with KQL.

The following simple query (role: Global Reader or Security Reader) returns sign-ins that failed because of token protection. Run it in Log Analytics workspace → Logs:

SigninLogs
| where ConditionalAccessStatus == "failure"
| where ConditionalAccessPolicies contains "TokenProtection"
| project UserPrincipalName, DeviceDetail, ConditionalAccessPolicies, ResultDescription, TimeGenerated

Token protection matters more as attackers work around MFA

Token theft is not a theoretical risk. As attackers put more effort into getting around MFA, token protection is becoming a standard part of Microsoft 365 security baselines. If you want to understand how token theft works and what else you can do about it, my detailed post on detecting and preventing token theft in Microsoft 365 goes into more depth.

The flowchart below shows how token protection stops a stolen token from working on another device:

flowchart TD
    SignIn["Sign-in on Windows device"]
    TokenIssued["Token issued"]
    Bound["Token bound to device"]
    UseSameDevice["Token used on same device"]
    UseOtherDevice["Token used on another device"]
    AccessAllowed["Access allowed"]
    AccessDenied["Access denied"]

    SignIn --> TokenIssued --> Bound --> UseSameDevice --> AccessAllowed
    Bound --> UseOtherDevice --> AccessDenied

Figure: Token protection binds the token to the device, so reuse elsewhere is blocked.

Token protection is essential but does not solve everything

For organizations whose device fleet is mainly Windows, token protection is now part of my Microsoft 365 security baseline for 2026. Starting in report-only keeps the rollout low-risk, and the limitations are well defined: browsers and non-Windows endpoints still need separate controls. Attackers are getting bolder with session hijacking, and token protection is a necessary step against it. It does not replace strong authentication, device compliance and layered Conditional Access, though. If you haven't piloted token protection yet, now is a good time to do it.