Token protection in Conditional Access: what it really covers

How token binding works

When a Windows device is joined or registered to Entra ID, it holds its own cryptographic key, protected by the TPM where possible. Token protection relies on that key: session tokens issued for the applications in scope are bound to the device, and using them requires proof of possession of the key. An attacker who exfiltrates the token from the workstation therefore cannot replay it from their own machine.

In Conditional Access this takes the form of a session control, "Require token protection for sign-in sessions". When the policy applies, Entra ID only accepts device-bound sessions; clients that cannot provide that binding are blocked.

What the feature covers, and what it does not

This is the point we most often see misunderstood. Token protection does not protect "every session". Its scope depends on three dimensions:

• Platforms: support started with Windows (joined, hybrid joined or registered devices), with other platforms being added over time.
• Clients: mainly native desktop applications (Outlook, Teams, OneDrive, Office clients) can present bound tokens. Browser sessions are not, at the time of writing, covered in the same way.
• Resources: only certain resources are supported, typically Exchange Online, SharePoint Online and Teams.

The lists of supported platforms, clients and resources change regularly, as do the licensing terms. Check the current state in the documentation and in your tenant before designing the policy.

Designing a policy that does not block everything

Because any unsupported client is blocked, the policy must be scoped precisely. A cautious design looks like this:

1. Users: a pilot group, then high-risk populations (administrators, executives), excluding emergency access accounts.
2. Resources: only the supported applications, selected explicitly.
3. Conditions: the Windows platform only, and the "mobile apps and desktop clients" client type, so browsers are left alone.
4. Session control: require token protection.

Start in report-only mode

Report-only mode is essential here. Over several weeks it lets you see in the sign-in logs what the policy would have done, together with the token protection status of each session. This reveals:

• devices whose registration state does not allow binding;
• client versions that are too old;
• unexpected usage: third-party tools, scripts, line-of-business applications accessing the same resources;
• shared or virtualised environments, where binding may behave differently.

Only once these cases have been fixed or excluded in a documented way should the policy move to enforced mode, first for the pilot, then in waves.

One building block among others

Token protection is part of a wider set: phishing-resistant MFA to reduce initial theft, a compliant device required for sensitive resources, continuous access evaluation to speed up revocation, and Entra ID Protection detections to spot anomalous tokens. On its own it covers one specific scenario: a token exfiltrated from a Windows workstation and replayed elsewhere. That scenario is real, particularly after infostealer malware has run, but it is not the only one.

What an audit checks

• Whether a token protection policy exists and its mode (report-only or enforced).
• Its scope: users, resources, platforms and client types.
• Exclusion of emergency access accounts and justification of any other exclusions.
• Analysis of report-only sign-in logs before enforcement.
• Consistency with other controls: compliant device, authentication strength, continuous access evaluation.