Require token protection only for verified device, client, and resource combinations

Bottom line: Microsoft Entra token protection is a Conditional Access session control intended to reduce replay of stolen tokens by requiring supported device-bound sign-in session tokens. It is not universal token binding. Platform, browser, client, device-registration, and cloud-resource support must all match before enforcement.

Source fact: what Microsoft documents

Microsoft’s token-protection documentation explains that a Primary Refresh Token issued to a supported registered device is cryptographically bound to that device. When token protection is enforced, Microsoft Entra validates that supported applications use bound sign-in session tokens for the protected resource.

Microsoft’s current platform table lists native-application support as Generally Available on Windows, iOS/iPadOS, and macOS. It lists browser support as Preview on Windows and macOS for supported web apps that access Azure Resource Manager, and as unsupported on iOS/iPadOS. The same page still labels its supported-device section “Apple (Preview),” so Apple status is internally inconsistent in the source and must be rechecked against the platform table and Apple deployment guide before relying on compatibility guidance. The listed native Microsoft 365 resources include Exchange Online, SharePoint Online, and Microsoft Teams, with additional documented Windows coverage.

What the source does not establish

Token protection does not prevent every form of token theft, session misuse, malware, browser compromise, or authenticated abuse on the intended device. It does not apply to every token or resource. Preview support is not a promise of production suitability. A policy that blocks an unsupported client can reduce availability without proving that another access path is protected.

Applicability questions

• Which protected resources are in Microsoft’s current supported list?
• Which users access them through Windows native apps, web browsers, iOS, iPadOS, macOS, virtual desktops, or automation?
• Are devices correctly registered and able to obtain the required device-bound token?
• Which client versions and brokers are required, and what legacy or embedded clients remain?
• Is the relevant platform-resource combination generally available or preview in the tenant’s cloud?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Create a user-device-client-resource inventory and compare every combination with the current Microsoft support tables.
2. Begin with a narrow group of known, reliable users and supported managed devices. Keep emergency access and unsupported operational clients outside enforcement under documented review.
3. Test normal access, token refresh, device replacement, app upgrade, browser access, remote desktop, and device-registration failure.
4. Monitor Conditional Access results and helpdesk issues before expanding scope. Investigate unexpected success as carefully as unexpected blocking.
5. Retain other defenses against token theft and post-authentication compromise; do not present binding as a guarantee.

Verification and evidence

• Preserve the Conditional Access policy, assignment, exclusions, mode, and approval.
• Record tested OS, device state, client version, resource, and observed result.
• Capture Entra sign-in details showing policy evaluation and failure information for unsupported cases.
• Reconcile the production population against documented support after client or service changes.

Official references

• Token Protection in Microsoft Entra Conditional Access — Microsoft