Token protection: scope and limits
On this page
- Token protection — supported scope and known limitations
- Supported applications
- Supported resources (Windows)
- Known limitations
- Identifying affected devices before you enforce
- Device filter exclusions to prevent onboarding disruption
- Policy construction warnings
- Deployment approach
- Diagnosing outcomes in the sign-in log
- End-user experience
Token protection — supported scope and known limitations
Source: Token protection deployment guide — Windows
· doc date 2026-03-24 · retrieved 2026-07-28
benchmark guidance recommends token protection and points at "known limitations" without listing
them. This file lists them. It converts a vague caveat into a concrete pre-flight checklist.
Requires Entra ID P1.
Supported applications
Exchange PowerShell module · Microsoft 365 Copilot · Microsoft Edge (sign-in to Edge
profile only) · Microsoft Graph PowerShell with the EnableLoginByWAM option ·
Microsoft Loop · Microsoft Teams · Microsoft To Do · OneNote · OneDrive · Outlook ·
Power BI Desktop · PowerQuery extension for Excel (Current Channel only) ·
Visual Studio Code · Visual Studio (when using the Windows authentication broker sign-in
option) · Windows App · Word, Excel, PowerPoint
**Token protection currently supports native applications only. Browser-based
applications are not supported.**
Supported resources (Windows)
Exchange Online · SharePoint Online · Microsoft Teams · Azure Virtual Desktop · Windows 365
Known limitations
Applications:
- Office perpetual clients aren't supported.
- These block users when accessing Exchange and SharePoint:
- PowerShell modules accessing SharePoint
- PowerQuery extension for Excel for users not on Current Channel
- Visual Studio Code extensions that access Exchange or SharePoint
Devices:
- Surface Hub — not supported
- Windows-based Microsoft Teams Rooms (MTR) systems — not supported
External users: B2B users who meet the token protection device registration requirements
in their home tenant are supported. Users who don't **see an unclear error message with
no indication of the root cause** — worth knowing when troubleshooting a guest complaint.
Unsupported device registration types — devices registered by these methods are not
supported:
- Microsoft Entra joined Azure Virtual Desktop session hosts
- Windows devices deployed using bulk enrollment
- Cloud PCs deployed by Windows 365 that are Microsoft Entra joined
- Power Automate hosted machine groups that are Microsoft Entra joined
- Windows Autopilot devices deployed using self-deploying mode
- Windows virtual machines in Azure using the VM extension enabled for Microsoft Entra ID
authentication
This list is why token protection surprises people: several very common modern deployment
patterns are excluded.
Identifying affected devices before you enforce
Inspect tokenProtectionStatusDetails in the sign-in logs. Requests blocked because of an
unsupported device registration type carry signInSessionStatusCode = 1003.
KQL to find them:
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where TokenProtectionStatusDetails != ""
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails)
| extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"])
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"])
| where bindingStatusCode == 1003
| summarize count() by UserPrincipalName
Device filter exclusions to prevent onboarding disruption
Microsoft's own suggested device filter rules for excluding the unsupported categories:
| Category | Filter rule |
|---|---|
| Entra-joined Cloud PCs | systemLabels -eq "CloudPC" and trustType -eq "AzureAD" |
| Entra-joined Azure Virtual Desktop | systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD" |
| Power Automate hosted machine groups | systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD" |
| Autopilot self-deploying mode | enrollmentProfileName -eq "<your Autopilot self-deployment profile name>" |
| Entra-joined Azure VMs | profileType -eq "SecureVM" and trustType -eq "AzureAD" |
These are directly usable and are exactly the kind of specific, hard-to-recall detail the
agent should surface.
Policy construction warnings
Do not select the Office 365 application group.
Your Conditional Access policy should only be configured for these applications. Selecting
the Office 365 application group might result in unintended failures. This change is an
exception to the general rule that the Office 365 application group should be selected.
Target explicitly: Office 365 Exchange Online, Office 365 SharePoint Online, Microsoft Teams
Services — plus Azure Virtual Desktop, Windows 365 and Windows Cloud Login if Windows App is
deployed.
Do not leave the Client apps condition unconfigured.
Not configuring the Client Apps condition, or leaving Browser selected might cause
applications that use MSAL.js, such as Teams Web, to be blocked.
Set Configure = Yes and select only Mobile apps and desktop clients.
Guard against platform bypass. Because token protection is only available for Windows and
Apple devices, Microsoft recommends additionally configuring:
- Block access from unknown/unsupported platforms
- Require device compliance for all known platforms
Otherwise an attacker can present as a platform the policy doesn't cover.
Deployment approach
- Start with a pilot group and expand over time. Microsoft suggests users in specialised
privileged-access roles as the initial target.
- Create the policy in report-only before enforcing.
- Capture both interactive and non-interactive sign-in logs.
- Analyse long enough to cover normal application use.
- Add known, reliable users to an enforcement policy.
The non-interactive log point matters — token protection failures show up heavily in
non-interactive sign-ins, which most people never look at.
Diagnosing outcomes in the sign-in log
Sign-in log → Basic Info → field Token Protection - Sign In Session:
| Value | Meaning |
|---|---|
| Bound | The request used bound protocols |
| Unbound | The request did not |
A sign-in can include multiple requests, and all must be bound to satisfy the policy.
An individual request appearing bound does not mean the sign-in complies. Filter by user or
correlation ID to see all requests for a sign-in.
Unbound status codes:
| Code | Meaning |
|---|---|
| 1002 | Unbound due to lack of Microsoft Entra ID device state |
| 1003 | Device state doesn't satisfy CA requirements — unsupported registration type, or the device wasn't registered using fresh sign-in credentials |
| 1005 | Unbound for other unspecified reasons |
| 1006 | Unsupported OS version |
| 1008 | Client isn't integrated with the platform broker (e.g. Windows Account Manager / WAM) |
Log query naming change: the string used in enforcedSessionControls and
sessionControlsNotSatisfied changed from Binding to SignInTokenProtection in **late
June 2023**. Queries must handle both to include historical data. Microsoft's own sample
queries check for both.
End-user experience
- Registered/enrolled device on a supported app: no visible difference.
- Unregistered/unenrolled device with the policy on: a "register or enroll your device"
error after authenticating.
- Unsupported application: a token-protection-required error after authenticating.