Update: Token Protection in Conditional Access Now Supports the Windows App

Token Protection (also known as token binding) ensures that sign-in tokens are only valid on the device where they were issued. It creates a cryptographic tie between the token and device, making the token unusable if stolen and replayed from another system.

This feature:

• Helps prevent lateral movement using stolen tokens
• Reinforces device-based access enforcement
• Complements MFA and device compliance policies

What’s New in This Update?

Key improvements now available in public preview:

• Support for Windows App (version 2.0.379.0+) - Expanded scope to AVD and Windows 365
• Enforcement for session tokens on Entra-joined or hybrid-joined Windows 10+ and Server 2019+ devices
• Works with desktop apps like Teams, OneDrive, Power BI Desktop, Visual Studio, and more

Deployment Recommendations

To implement Token Protection:

• Create a Conditional Access policy in Report-only mode.
• Apply the policy only to supported applications: Exchange Online, SharePoint Online, AVD, and Windows 365.
• Exclude unsupported platforms (e.g. Surface Hub, bulk-enrolled Cloud PCs).
• Review sign-in logs to assess impact before moving to enforcement. Log Analytics Integration You can monitor policy impact by querying Sign-in Logs via Log Analytics. This helps identify which apps or users are being blocked due to token protection issues. Important: Since June 2023, the values for enforcedSessionControls and sessionControlsNotSatisfied changed from "Binding" to "SignInTokenProtection" — queries should reflect this update. Query by Application:

AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, Status, UserPrincipalName, AppDisplayName, ResourceDisplayName
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName in ("Office 365 Exchange Online", "Office 365 SharePoint Online", "Azure Virtual Desktop", "Windows 365", "Windows Cloud Login")
| mv-expand todynamic(ConditionalAccessPolicies)
| where ConditionalAccessPolicies["enforcedSessionControls"] contains '["Binding"]'
   or ConditionalAccessPolicies["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied"
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"]

Query by User:

AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName in ("Office 365 Exchange Online", "Office 365 SharePoint Online", "Azure Virtual Desktop", "Windows 365", "Windows Cloud Login")
| mv-expand todynamic(ConditionalAccessPolicies)
| where ConditionalAccessPolicies["enforcedSessionControls"] contains '["Binding"]'
   or ConditionalAccessPolicies["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied"
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"]

Identify Unsupported Devices:

AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where TokenProtectionStatusDetails != ""
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails)
| extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"])
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"]

What's Not Supported — Key Limitations to Be Aware Of Before rolling out Token Protection broadly, it’s important to understand where it won’t work (yet):

• Office Perpetual clients are not supported.
• Apps that don’t support protected token flows will be blocked when accessing Exchange or SharePoint:

• PowerShell modules for SharePoint
• PowerQuery for Excel
• VS Code extensions accessing Exchange or SharePoint

• Unsupported device types:

• Surface Hub
• Microsoft Teams Rooms (MTR) on Windows

• External users: If their device registration doesn’t meet the requirements in their home tenant, access will be blocked — and the error message won’t explain why.
• Unsupported Entra device registration methods:

• Azure Virtual Desktop session hosts that are Entra joined
• Cloud PCs (Windows 365) that are Entra joined
• Devices enrolled using bulk enrollment
• Power Automate hosted machine groups
• Autopilot devices in self-deploying mode
• Azure VMs using Entra ID VM extension for auth

📌 If a sign-in fails due to an unsupported scenario, look for signInSessionStatusCode = 1003 in the Sign-in Logs (under TokenProtectionStatusDetails). How to Avoid Onboarding Issues? To prevent disruptions during rollout, you can filter out unsupported devices directly in your Conditional Access policy using device filters.

Examples:

• Exclude Cloud PCs:

• Exclude AVD (Entra joined):

• Exclude Power Automate hosted machines:

• Exclude Azure VMs:

Final Thoughts

Token Protection is a crucial piece in implementing session-level control across cloud apps and Windows endpoints. Now that support includes the Windows App, this protection finally extends to environments where it’s needed most: VDI and Cloud PCs.

Review your existing Conditional Access policies and begin piloting this feature today.

Learn more:

https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection

Want to know where your tenant stands? Griffin31 checks your Microsoft 365 security settings continuously and shows you what to fix first.