Token protection in Conditional Access: what it stops, what it does not, and how to deploy it without breaking sign-in
A stolen token is a working key. An attacker who lands one through an adversary-in-the-middle page or a malware grab can replay it from their own machine and walk into Exchange, SharePoint, or Teams as the user, no password prompt, no MFA. A Conditional Access baseline as most people build it does not stop this, because the token already satisfied MFA when it was issued. Token protection is the one CA control that goes after replay directly. It is also the control most likely to be misread as a complete answer to token theft, which it is not. This covers what it binds, the two scoping rules that will block your own users if you get them wrong, and how to stage it in report-only before it touches anyone.
The attack Conditional Access does not stop
Picture the sign-in that already went right. The user authenticated, passed MFA, and Entra ID issued a refresh token. Under a normal CA baseline that is the end of the story: the token is a bearer token, and a bearer token works from anywhere it is presented.
Now picture that token stolen. In an AiTM attack the proxy captures the session token as it passes through. In an infostealer case the token is lifted off disk. Either way the attacker replays it from their own device, and Entra ID sees a valid, already-MFA'd token. Your MFA policy does not fire again. Your risk policy might, if Identity Protection happens to flag the sign-in as unfamiliar, but that is a detection you are hoping for, not a control you are enforcing.
Token protection closes that specific gap. It binds the sign-in session token to the device it was issued on, so a token replayed from a different device is rejected before it grants access. The stolen key still exists. It just no longer fits the lock.
How the binding works
When a supported device registers with Entra ID, it receives a Primary Refresh Token, and that PRT is cryptographically tied to a secret held on the device. On Windows the secret sits in the TPM. On Apple platforms, where the feature is still in preview, the binding uses the Secure Enclave through the Microsoft Enterprise SSO plug-in.
With token protection enforced, Entra ID accepts only session tokens that carry that device binding and rejects plain bearer refresh tokens outright. Because the secret never leaves the hardware, a token copied to another machine cannot reproduce the binding, so the replay fails at the point of token presentation rather than relying on a risk signal to catch it after the fact.
Entra sign-in log showing Token Protection Sign In Session Bound for desktop Outlook against Exchange Online
What it protects, precisely
Token protection is narrow on purpose, and the boundaries are where deployments go wrong. Three of them matter.
It covers native and desktop clients only. Browser sessions are out of scope entirely. Desktop Outlook, the Teams desktop client, and OneDrive sync are protected; the same services reached through a browser tab are not. That single fact is why token protection is a layer and not a solution, because browser-based cookie theft is exactly where a large share of real replay happens today, and this control does not touch it.
It targets two resources: Exchange Online and SharePoint Online. You select those individually. Teams is not a separately selectable service resource here; it relies on Exchange Online and SharePoint Online, so it is covered through them. You do not target All resources, and you specifically do not use the Office 365 app group here, which I come back to in the scoping section because it is the rule most likely to bite.
Platform support splits by maturity. On Windows the control is generally available for devices that are Entra joined, Entra hybrid joined, or Entra registered. On Apple platforms it is in preview, requires macOS 14 or iOS/iPadOS 16 and later, needs the devices MDM-enrolled, and depends on the Microsoft Enterprise SSO plug-in. The preview label is the operative caveat: it moves, so re-check the deployment guide before you enforce anything on Mac or iOS.
The Apple preview carries a specific blocker worth calling out on its own. Apple's native Mail and Calendar apps do not support token protection, and under an enforced policy users on those apps are blocked from the protected resources. If your Mac or iPhone users live in Apple Mail rather than Outlook, enforcing this policy takes their mail away. That has to be communicated before enforcement, not discovered during it.
| Aspect | Windows | Apple (macOS, iOS/iPadOS) |
|---|---|---|
| Status | Generally available | Preview |
| OS minimum | Windows 10 or later; Windows Server 2019 or later (hybrid joined) | macOS 14.0 or later; iOS/iPadOS 16.0 or later |
| Device registration | Entra joined, Entra hybrid joined, or Entra registered | MDM-managed only |
| Prerequisite | TPM-backed PRT binding | Microsoft Enterprise SSO plug-in (or Platform SSO); Secure Enclave binding |
| Known blocker | Unsupported registration types return status 1003 (see Table 3) | Native Apple Mail and Calendar are blocked under an enforced policy |
| Licensing | Microsoft Entra ID P1 | |
| Resources | Exchange Online and SharePoint Online, selected individually (not the Office 365 app group). Teams authentication depends on these services and is covered through them. | |
| Client scope | Native and desktop clients only; browser sessions not supported | |
The two scoping rules that lock people out
This policy has two settings that look like reasonable choices and are in fact the block risk.
The first is the client apps condition. If you leave it unconfigured, or leave Browser selected, applications built on MSAL.js can be blocked, and that includes Teams on the web. The fix is explicit: under modern authentication clients, select Mobile apps and desktop clients only, and leave everything else unchecked. Token protection has no browser coverage anyway, so selecting Browser gains you nothing and costs you web app access.
The second is the resource selection. Microsoft's general guidance across most CA policies is to reach for the Office 365 app group. Token protection is the documented exception. Selecting the Office 365 group here can cause unintended failures, so you target Exchange Online and SharePoint Online as individual resources and nothing wider. This is the one policy where the muscle memory of "just pick Office 365" works against you.
Both rules point the same direction. Token protection wants a tight scope, and every instinct toward "cover everything" widens the blast radius onto clients the control was never meant to gate.
Deploying it without breaking sign-in
The sequence is report-only, log analysis, pilot, enforce. None of the steps are optional, and the log analysis step is where token protection specifically earns the caution, because the failure modes are not all "attacker replayed a token." Some are just your own supported devices in a registration state the control does not accept.
Start with the policy in report-only. Here is the CA012 shape I built in my lab, with the same break-glass exclusion group that carries across the rest of the baseline:
| Setting | Value |
|---|---|
| Policy name | CA012-Windows-Require-TokenProtection |
| Users | All users, excluding SG-BreakGlass-Exclude |
| Target resources | Exchange Online, SharePoint Online |
| Device platforms | Windows |
| Client apps | Mobile apps and desktop clients only |
| Session control | Require token protection for sign-in sessions |
| State | Report-only (before enforcement) |
With the policy evaluating but not enforcing, read the sign-in logs. The field to watch is Token Protection - Sign In Session under Basic Info on each request, and it returns one of three values. Bound means the request satisfied the control. None means the policy did not evaluate the request at all, which is what a browser session returns, because browsers sit outside the client apps scope. Unbound means the policy evaluated the request and the binding failed, and it carries a status code explaining why.
The distinction matters when you go looking for evidence that the policy is working. In my lab, a browser sign-in to Outlook Web against Exchange Online returned None rather than an unbound status code, which confirms browser traffic falls outside the policy's scope. The control does not fail on browser requests. It never looks at them.
Entra sign-in log showing Token Protection Sign In Session None for a browser session against Exchange Online
The status codes are worth knowing before you enforce, because more than one of them describes a device you own rather than an attack:
| Code | Meaning |
|---|---|
| 1002 | Unbound due to the lack of an Entra ID device state on the request. |
| 1003 | Device registration state does not satisfy the requirement, or the device was not registered using fresh sign-in credentials. Common on AVD session hosts, Windows 365 Cloud PCs, bulk-enrolled devices, Autopilot self-deploying devices, and Entra-login Azure VMs. |
| 1005 | Unbound for other unspecified reasons. |
| 1006 | Unbound because the OS version is unsupported. |
| 1008 | Unbound because the client is not integrated with the platform broker, such as Windows Account Manager (WAM). |
The one that catches people is 1003. It means the device's registration state does not satisfy the requirement, and it fires on device types you would reasonably expect to be fine, including Azure Virtual Desktop session hosts that are Entra joined, Windows 365 Cloud PCs, bulk-enrolled devices, Autopilot self-deploying devices, and Azure VMs using the Entra login extension. These are supported Windows devices that still land as unbound because of how they were registered. The remedy Microsoft documents is a device filter condition on the policy that excludes those deployment categories, which is why the report-only pass matters: it surfaces the 1003 population before enforcement turns it into a wave of blocked sign-ins.
Include the non-interactive sign-in logs in this analysis, not just the interactive ones, because most 1003 results surface there rather than in the interactive log. A KQL query against the non-interactive logs surfaces the unbound population by parsing the binding attribute directly:
AADNonInteractiveUserSignInLogs | where TimeGenerated > ago(14d) | where TokenProtectionStatusDetails != "" | extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails) | extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"]) | extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"]) | where bindingStatus == "Unbound" | summarize count() by UserPrincipalName, bindingStatusCode, AppDisplayName
What it does not solve
The honest boundary is the browser. Token protection does nothing for cookie theft from a browser session, which is the delivery path behind a large share of AiTM replay. An attacker who harvests browser cookies still replays them in a browser, and this control never looks there. Anyone selling token protection as the answer to token theft has skipped that line.
There is also a client-compatibility edge to plan for. Office perpetual clients are not supported, and a handful of applications do not support protected token flows and get blocked when reaching Exchange or SharePoint, including PowerShell modules that access SharePoint, so an automation account running one of those against a protected resource fails once the policy is on. Check the current unsupported list in the deployment guide before enforcing if you run that kind of tooling.
It also does not cover the platform-bypass angle by itself. Because the control only applies on Windows and Apple native clients, a sign-in from an unsupported platform can slip past it. This is why Microsoft's own deployment guide pairs token protection with additional Conditional Access policies to close that gap rather than treating it as standalone.
Verdict
Deploy it on Windows now. The binding is real, the licensing is P1 rather than P2 so it is not gated behind the higher tier, and staged through report-only it is low-risk to stand up. Watch the Apple preview but do not enforce it where users depend on native Mail and Calendar, because that blocks them outright. And hold the line on what it is: one layer against replay, strong on native clients, silent in the browser. Useful, bounded, worth deploying with the boundary understood.
Questions about which path fits your environment are welcome. Please feel free to reach out.
