Entra Token Protection Does Less Than You Think. Here Is the Test Evidence.

A Conditional Access session control named "Require token protection for sign-in sessions" reads like a solved problem. Turn it on, tokens get bound to devices, replay attacks die. That is how plenty of admins have read it, ourselves included at first, and that reading is wrong in one expensive way.

We put the preview through a real token theft scenario to document where the protection holds and where it does not. The headline finding: a stolen session token still replays happily in a browser, which is exactly where most adversary-in-the-middle activity lives today. Everything below is the evidence, current as of May 2025.

Microsoft's reference for the feature, including known limitations, is here: Microsoft Entra Conditional Access token protection explained (opens in new tab).

One genuinely good piece of news up front: Microsoft recently changed the licensing requirement, making token protection available with Entra ID P1. You no longer need P2 for this control.

What a device-bound token is supposed to buy you#

Device-bound token protection secures a Microsoft 365 environment by tying sign-in credentials to a specific device. Even if someone steals a token, the key to the account, they cannot use it from another device. Think of a house key that only turns in your own front door: anyone who lifts it gets a useless piece of metal. Done fully, that defeats token replay attacks regardless of how the token was stolen, AiTM or otherwise.

That is the promise. The current preview delivers a narrower slice of it.

Expectation versus what actually shipped#

To Microsoft's credit, this is still in preview, and we will update this comparison as the feature matures. Here is the gap between a reasonable reading of the feature and the rollout as of May 2025:

The row that matters is the third one. The protection only applies to client apps, not the browser. Even with the policy enforced, an attacker can replay a stolen session token in a browser through cookies, which is where we see very high attack volume today. In practical terms: no protection against the harvesting and replay pattern used in AiTM attacks.

The sign-in flow when everything is in order#

When a user signs into a client app for Outlook, Microsoft 365 apps, or Teams from a device holding a device-bound token, the sign-in succeeds and Entra records the binding. You can see it in the sign-in logs:

The device prerequisite: devices have to be Entra Joined, Hybrid Joined, or Registered.

With the prerequisites met, the Conditional Access policy reports success:

The sign-in flow when the token is unbound#

A user signing into an Outlook client on a device with an unbound token gets stopped:

The sign-in logs show the unbound token failure arriving from a new location:

So far the control behaves exactly as designed. Client app, unbound token, blocked.

Then the browser undoes it#

Here is the gap. The same attacker takes the stolen session token to a browser and replays it via cookies:

The policy never enters the picture because browser sessions are out of scope for the current rollout. If your threat model is AiTM phishing, and for most MSP client bases it should be, this control alone does not change your exposure.

What enforcing it feels like for users#

Friction is modest. Beyond the expected block when signing into a desktop client on a non-managed device without a device-bound token, we noticed one side effect: as soon as enforcement started, users were asked to sign in again across Office applications. Plan for a brief wave of re-authentication prompts on rollout day, and warn the helpdesk.

Where token protection fits in the bigger token theft picture#

We map the full landscape of Conditional Access protections against token theft in our proactive protections playbook. The summary view:

A few conclusions from sitting with that table:

• Splitting the analysis into token theft and token replay matters because tokens stolen via malware, XSS, or malicious browser extensions can still be replayed even when you enforce compliant devices or phishing-resistant MFA. The grant in the token has already been satisfied.
• For the many organizations on Business Premium, several options prevent the initial token theft. Requiring a compliant or managed device is probably the most achievable today. Phishing-resistant MFA adoption is a slow climb, and trusted locations are tough with a remote workforce.
• Global Secure Access, Microsoft's SASE solution, covers both initial theft and replay, including theft methods beyond AiTM. The con is cost: it is hard to justify for much of the SMB space.
• Token replay protection via the policy in this post has the holes documented above. Treat it as one layer for desktop client traffic, not as your replay answer.

The feature is worth enabling where the prerequisites are already met, precisely because the friction is low. Just do not file it under "token theft: solved." File it under "one more door locked, browser still open."