Microsoft Entra Token Protection: reduce stolen token replay

Stolen tokens can outlive an MFA-protected sign-in

Successful MFA does not make every subsequent token impossible to replay. Microsoft Entra Token Protection adds a Conditional Access session control: supported flows must use device-bound sign-in session tokens when requesting protected resources. Its purpose is to reduce replay from another device.

Treat deployment as a compatibility project. Start with native applications, record exceptions, and evaluate the web preview separately. The groups and identifiers in this guide are fictional.

• Microsoft: Token Protection scope and operation ↗

Separate PRTs, access tokens, and cookies

A Primary Refresh Token enables SSO and token acquisition through an identity broker, including WAM on Windows. Cryptographic binding uses device keys. Having a PRT does not prove that every application request satisfies the policy.

Do not describe this feature as universal binding for every access token or browser cookie. A compromised authorized endpoint remains a threat because an attacker can operate in its context. Token Protection complements incident response, phishing-resistant MFA, and device compliance. PRT support on a platform does not automatically imply support for this Conditional Access control.

• Microsoft: Primary Refresh Token architecture ↗
• Token theft and AiTM attacks →

Build a compatibility matrix first

Microsoft’s availability table lists native Windows, iOS/iPadOS, and macOS support as generally available. Browser support remains a preview for selected Azure Resource Manager portals. A device subsection on the overview page still carries an Apple Preview label: also use the Apple deployment guide and confirm the controls available in your tenant before expanding.

• Microsoft: availability and device requirements ↗

Windows: validate the client, broker, and registration method

The Windows guide includes Outlook, OneDrive, Teams, Microsoft 365 Office, and Graph PowerShell with EnableLoginByWAM. Edge profile sign-in support does not mean all websites in Edge are protected. Keep clients current and test their actual versions.

Perpetual Office clients, some SharePoint PowerShell modules, and some VS Code extensions are unsupported. Windows Teams Rooms and Surface Hub also need special handling. Documented registration exceptions include certain Entra-joined Cloud PCs and AVD hosts, bulk enrollment, and self-deploying Autopilot. Protecting the Windows 365 resource does not make every Cloud PC a compatible client device.

Collect device state without changing configuration. Compare AzureAdJoined, DomainJoined, WorkplaceJoined, and AzureAdPrt for the affected account and session. These fields are useful evidence, not a complete Token Protection verdict. Redact tenant, device, and user identifiers before sharing output.

# Read-only. Run in the affected user's Windows session.
dsregcmd /status
Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber
Get-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Policies\Microsoft\BrowserCore'     -Name EnablePlatformAuth -ErrorAction SilentlyContinue

• Microsoft: Windows clients and unsupported registrations ↗

Apple: configure MDM, the broker, and secure registration

Authenticator acts as the broker on iPhone/iPad; Company Portal provides it on Mac. Deploy the required Enterprise SSO profile through MDM, or Platform SSO on Mac where appropriate, and follow the guide’s secure registration configuration. Installing Outlook alone is insufficient.

Apple’s native Mail and Calendar applications cannot satisfy this control and may be blocked. Unmanaged Apple devices are outside this scenario. Existing registrations can require reauthentication and a registration upgrade: unbound observation does not always mean permanent incompatibility. Communicate and test the user journey.

• Microsoft: Apple deployment and registration upgrades ↗

Confirm licensing, ownership, and available evidence

Token Protection requires Microsoft Entra ID P1 for covered users. Confirm the entitlement in your subscriptions. Intune compliance, MDM, and Entra risk features have separate licensing requirements; P1 does not automatically license the entire architecture.

Assign a pilot owner, an authorized Conditional Access administrator, and a log reviewer. For Log Analytics, export interactive and non-interactive sign-ins, grant appropriate workspace read access, and set retention. Azure ingestion and retention can incur charges. Queries cannot reconstruct events that were never exported.

• Microsoft: control licensing and administration ↗
• Microsoft: integrate logs with Azure Monitor ↗

Create a native report-only policy and an enforcement ring

For example, CA-TokenProtection-Pilot contains a few IT staff and representative users. Record the baseline, emergency exclusions, and rollback route. Separate Windows and Apple policies for easier troubleshooting. Creating the policy is a configuration change even though report-only does not enforce blocking.

• In Entra ID > Conditional Access > Policies, create CA-TP-Windows-Native-Pilot. Include the pilot group and exclude monitored emergency access accounts.
• Select Exchange Online and SharePoint Online explicitly for the first scenario. Add Teams or Windows App resources only with documented test cases; Windows App scenarios also require the Windows Cloud Login selection described by Microsoft.
• Configure Windows under Device platforms. Configure Client apps and select only Mobile apps and desktop clients; leave Browser unchecked for this native policy.
• Under Session, select Require token protection for sign-in sessions. Save as Report-only and observe complete working cycles, including silent sign-ins and less frequent applications.
• Do not select all resources or the broad Office 365 application group: this feature is an exception to the usual Office 365 grouping recommendation.
• Resolve incompatibilities, then switch a small validated ring to On. Keep observation for subsequent rings and assess the combined effect of other policies.

• Microsoft: native policy configuration ↗
• Move from report-only to enforcement →

Read logs without mistaking observation for an actual block

Open a sign-in in Entra, inspect Conditional Access or Report-only, the exact policy, and Token Protection – Sign-in Session. Correlate requests using CorrelationId: one bound event does not prove every request in the sign-in meets the control. A negative report-only outcome describes potential impact, not an actual refusal.

The first KQL query inventories clients, resources, and binding states. The second isolates your policy by ID. Replace the fictional ID. Missing tables or columns require checking the export and schema; empty values do not mean bound. These collection templates require validation in your workspace.

// Read-only: both log categories must be exported to this workspace.
// Empty properties mean unknown, not a passing result.
union withsource=LogCategory SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| extend TP = parse_json(tostring(TokenProtectionStatusDetails))
| extend Binding = tostring(TP.signInSessionStatus),
         BindingCode = tostring(TP.signInSessionStatusCode)
| summarize Requests=count(), Users=dcount(UserPrincipalName),
    FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
    by LogCategory, AppDisplayName, ResourceDisplayName, Binding, BindingCode
| order by Requests desc

// Replace with the exact ID of your pilot policy; keep the quotes.
let PilotPolicyId = "00000000-0000-0000-0000-000000000000";
union withsource=LogCategory SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| mv-expand Policy = ConditionalAccessPolicies
| where tostring(Policy.id) == PilotPolicyId
| extend PolicyResult=tostring(Policy.result),
    TP=parse_json(tostring(TokenProtectionStatusDetails))
| project TimeGenerated, LogCategory, UserPrincipalName, AppDisplayName,
    ResourceDisplayName, PolicyResult, ResultType, CorrelationId,
    Binding=tostring(TP.signInSessionStatus),
    BindingCode=tostring(TP.signInSessionStatusCode),
    SessionControls=Policy.enforcedSessionControls
| order by TimeGenerated desc

• Microsoft: Windows status codes ↗
• Microsoft: Apple readiness interpretation ↗

Treat the ARM browser preview as a separate deployment

The web guide limits support to Azure portal, Intune admin center, Entra admin center, Microsoft Engage Center, and Engage Hub. The Conditional Access resource is Windows Azure Service Management API. Other ARM applications, including Power BI or Power Platform admin center in Microsoft’s list, may be blocked. This does not protect Outlook Web and every administration portal indiscriminately.

Windows requires the documented Windows 11 builds, EnablePlatformAuth=1 under HKLM\SOFTWARE\Policies\Microsoft\BrowserCore, and the Microsoft Single Sign-On extension in Edge or Chrome. Mac requires its broker, secure registration, and the browser extension. Deploy through managed configuration, record previous settings, and allow at least 24 hours before assessing readiness.

Create a separate policy with pilot users, compatible Windows/macOS platforms, ARM, and Browser only under Client apps. Start the Token Protection session control in Report-only. Test every allowed portal and other ARM applications used by the group. Do not enforce with unresolved essential workflows. Roll back to observation first, then restore the prior registry configuration and extension assignment through the approved process.

• Microsoft: ARM web preview requirements and limitations ↗

Validate and roll back without opening the entire tenant

For a fictional 12-person pilot, track every device/client/resource combination. Test Outlook, OneDrive synchronization, Teams files, reauthentication after client closure, silent renewal, Apple Mail where used, and an incompatible laboratory device. Record expected and observed results. No test requires stealing or exporting a token.

Give every exception an owner, rationale, minimal scope, compensating control, and expiry. Prefer client or registration remediation over permanent broad exclusions. Cloud PC and AVD filters must match the registration methods actually deployed.

For a block, capture UTC time, user, client/version, resource, policy ID, and correlation before changing scope. Return only the new policy to Report-only or disable it according to the rollback plan. Other policies continue to apply; allow propagation and test a new authentication request. Do not delete devices or revoke everyone’s sessions to fix a compatibility issue.

• Exit criteria: essential workflows tested, failures explained, exceptions approved, and emergency access validated.
• A high overall success rate can hide a critical infrequent user workflow; review people and business functions as well as request counts.
• For genuine compromise, preserve evidence and initiate incident response and appropriate access revocation; the pilot is not containment.

• Microsoft: registration-specific Windows exclusions ↗

Close uncovered paths and maintain the control

A Windows-only policy is insufficient if another platform leaves an unprotected route. Evaluate Microsoft’s complementary compliance and unknown-platform policies with their own pilots. A platform condition is not cryptographic proof of trust; combine device identity, compliance, phishing-resistant MFA, and endpoint detection.

Repeat tests after client, registration, or MDM changes. Watch new unbound codes and expired exceptions. Maintain an operational record of protected scope, uncovered workflows, owners, and incident procedures. A Microsoft 365 and Entra ID assessment can validate these dependencies across the environment and prioritize further work.

• Microsoft 365 and Entra ID security assessment →
• Microsoft: complementary controls and scope ↗