AccessPilot Knowledge Base

Contents › Microsoft guidance

Token protection: scope and limits

Supported apps and devices, the unsupported deployment types, and the device filters that exclude them.
Published by Urbannerd Consulting · Reviewed 2026-07-29

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:

Devices:

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:

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:

CategoryFilter rule
Entra-joined Cloud PCssystemLabels -eq "CloudPC" and trustType -eq "AzureAD"
Entra-joined Azure Virtual DesktopsystemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD"
Power Automate hosted machine groupssystemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD"
Autopilot self-deploying modeenrollmentProfileName -eq "<your Autopilot self-deployment profile name>"
Entra-joined Azure VMsprofileType -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:

Otherwise an attacker can present as a platform the policy doesn't cover.

Deployment approach

privileged-access roles as the initial target.

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:

ValueMeaning
BoundThe request used bound protocols
UnboundThe 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:

CodeMeaning
1002Unbound due to lack of Microsoft Entra ID device state
1003Device state doesn't satisfy CA requirements — unsupported registration type, or the device wasn't registered using fresh sign-in credentials
1005Unbound for other unspecified reasons
1006Unsupported OS version
1008Client 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

error after authenticating.