Conditional Access token protection: stop stolen token replay

Conditional Access token protection blocks the replay of stolen sign-in session tokens by accepting only refresh tokens that are cryptographically bound to the device they were issued to, such as the Primary Refresh Token (PRT), and rejecting bearer tokens that would work from any machine. To use it, create a Conditional Access policy that targets Exchange Online, SharePoint Online and Microsoft Teams Services, limits the device platform to Windows (or iOS and macOS), limits client apps to Mobile apps and desktop clients, and selects the session control Require token protection for sign-in sessions, then run it in report-only mode until the sign-in logs show your users' sessions as bound.

Who this is for and what you will have at the end

This guide is for identity and security administrators responding to token theft: adversary-in-the-middle phishing, infostealer malware that copies session artifacts, or any incident where an attacker used a valid token from an unknown machine. Microsoft suggests starting with users in specialized, high-value roles and piloting with a small group.

At the end you will have:

• A clear picture of what token protection covers and, just as important, what it doesn't.
• An inventory of devices and apps that would break, with device filter exclusions where needed.
• A report-only policy and the sign-in log fields and KQL queries to judge readiness.
• An enforced policy with the companion policies that prevent a platform bypass.

How token protection works and where it stops

When a user registers a supported device with Microsoft Entra ID, a PRT is issued and cryptographically bound to that device. On Windows, the device secret is stored in hardware such as the Trusted Platform Module (TPM). On Apple platforms, Microsoft Entra ID uses Apple Secure Enclave, falling back to the Data Protection Keychain on Macs without Secure Enclave. With the policy enforced, Microsoft Entra ID only accepts bound sign-in session tokens from supported applications, so a token copied to another machine is useless.

The limits matter as much as the feature:

Three further boundaries:

• It needs a PRT. Unregistered devices don't have one, so they can't satisfy the control.
• It protects only the user signed in to the device. If someone unlocks Windows as one account and then authenticates to a resource as another, the second identity isn't protected.
• It protects sign-in session tokens, not every app session. For apps outside its scope, Microsoft recommends network-based controls such as a compliant network through Global Secure Access, or location policies with Continuous Access Evaluation.

Prerequisites

• License: Microsoft Entra ID P1.
• Role: at least Conditional Access Administrator.
• Windows devices: Windows 10 or newer that are Microsoft Entra joined, Microsoft Entra hybrid joined or Microsoft Entra registered; Windows Server 2019 or newer that is hybrid joined.
• Apple devices: macOS 14.0 or later, iOS/iPadOS 16.0 or later, MDM-managed, with the Microsoft Enterprise SSO plug-in (Platform SSO is an alternative on macOS).
• Log Analytics (recommended): sign-in logs, including non-interactive sign-ins, sent to a workspace so you can query readiness.
• Supported, current clients. On Windows these include Outlook, Teams, OneDrive, OneNote, Word, Excel, PowerPoint, Microsoft Loop, Microsoft To Do, Windows App, Microsoft Copilot, Power BI Desktop, Visual Studio Code, the Exchange PowerShell module, Visual Studio with the Windows authentication broker sign-in option, Microsoft Graph PowerShell signing in through Web Account Manager (WAM), and Microsoft Edge (Edge profile sign-in only).

Hybrid joined devices need a healthy PRT for any of this to work; if dsregcmd /status shows AzureAdPrt : NO, fix that first using the hybrid join troubleshooting guide.

Step 1: Find what will break

Review the documented limitations against your estate before you create anything.

Unsupported clients on Windows (users are blocked from Exchange and SharePoint):

• Office perpetual clients.
• PowerShell modules accessing SharePoint.
• The Power Query extension for Excel for users not on Current Channel.
• Visual Studio Code extensions that access Exchange or SharePoint.

Unsupported Windows devices: Surface Hub and Windows-based Microsoft Teams Rooms systems.

Unsupported registration types:

• Microsoft Entra joined Azure Virtual Desktop session hosts.
• Windows devices deployed with bulk enrollment.
• Microsoft Entra joined Cloud PCs deployed by Windows 365.
• Microsoft Entra joined Power Automate hosted machine groups.
• Windows Autopilot devices deployed in self-deploying mode.
• Windows VMs in Azure enabled for Microsoft Entra ID sign-in through the VM extension.

Apple platforms: Apple's native Mail and Calendar apps don't support token protection and are blocked once the policy is enforced.

External users who meet the device registration requirements in their home tenant are supported; those who don't see an error that doesn't explain the cause.

For the unsupported registration types, add a Filter for devices condition that excludes them. Microsoft documents these rule examples:

systemLabels -eq "CloudPC" and trustType -eq "AzureAD"
systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD"
systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD"
profileType -eq "SecureVM" and trustType -eq "AzureAD"
enrollmentProfileName -eq "Autopilot self-deployment profile"

The last rule assumes your Autopilot self-deploying profile in Intune has that name; use your own profile name.

Step 2: Create the policy in report-only mode

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access > Policies and select New policy.
3. Name the policy.
4. Under Assignments > Users or workload identities, include your pilot users or group, and exclude your emergency access accounts.
5. Under Target resources > Resources (formerly cloud apps) > Include > Select resources, select:
   • Office 365 Exchange Online
   • Office 365 SharePoint Online
   • Microsoft Teams Services
   • If you deployed Windows App: Azure Virtual Desktop, Windows 365 and Windows Cloud Login
6. Under Conditions > Device platforms, set Configure to Yes and include Windows.
7. Under Conditions > Client apps, set Configure to Yes and, under modern authentication clients, select only Mobile apps and desktop clients.
8. Under Access controls > Session, select Require token protection for sign-in sessions.
9. Set Enable policy to Report-only and select Create.

Two settings in that list are deliberate exceptions to normal Conditional Access practice. Don't select the Office 365 app group: Microsoft warns it can cause unintended failures with this control, even though the group is the usual recommendation. And don't leave Browser selected or the client apps condition unconfigured, because apps that use MSAL.js, such as Teams on the web, can be blocked.

Step 3: Read the sign-in logs

Collect both interactive and non-interactive sign-ins, over a period long enough to cover normal application use.

In Entra ID > Monitoring & health > Sign-in logs, open a request, go to the Report-Only (or Conditional Access) tab, select your policy, and check whether Session Controls were satisfied. Then on Basic Info, read Token Protection - Sign In Session. A sign-in can include several requests and all of them must be bound to satisfy the policy, so filter by correlation ID to see the whole sign-in.

In the raw logs this appears as the tokenProtectionStatusDetails property with signInSessionStatus and signInSessionStatusCode. The session control string in enforcedSessionControls and sessionControlsNotSatisfied changed from Binding to SignInTokenProtection in late June 2023, so queries should match both.

KQL: users on devices that don't meet requirements

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

KQL: blocked versus allowed requests by application

AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, Status, UserPrincipalName, AppDisplayName, ResourceDisplayName
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName == "Office 365 SharePoint Online"
| 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"]
| extend Result = case(SessionNotSatisfyResult contains 'SignInTokenProtection'
    or SessionNotSatisfyResult contains 'Binding', 'Block', 'Allow')
| summarize by Id, UserPrincipalName, AppDisplayName, Result
| summarize Requests = count(), Users = dcount(UserPrincipalName),
    Block = countif(Result == "Block"), Allow = countif(Result == "Allow"),
    BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName
| extend PctAllowed = round(100.0 * Allow / (Allow + Block), 2)
| sort by Requests desc

Swap AADNonInteractiveUserSignInLogs for SigninLogs to check interactive sign-ins. Microsoft notes these queries are samples and subject to change.

Step 4: Enforce and close the platform gap

When the applications your pilot users rely on show as allowed, move known, reliable users into the enforced policy and set Enable policy to On. Expand in stages.

Users on registered devices with supported apps see no difference. Users on unregistered devices are prompted to register the device. Users of unsupported apps see an error after authenticating, so tell the help desk which apps are affected before each wave.

Because token protection only applies to the Windows and Apple platforms you selected, an attacker could try to present a stolen session as a different platform. Microsoft recommends two companion policies:

• Block access from unknown or unsupported device platforms.
• Require device compliance for all known platforms. The setup is covered in requiring compliant devices with Conditional Access.

Apple platforms

For iOS, iPadOS and macOS, the policy is the same except that Device platforms includes iOS and macOS, and the Apple guide targets only Exchange Online and SharePoint Online. Before users register, enable hardware-backed registration: deploy Microsoft Authenticator (iOS) or Company Portal (macOS) as the broker and enable the Microsoft Enterprise SSO plug-in, or Platform SSO on macOS. Users registered earlier are prompted once to reauthenticate, which upgrades their registration; in report-only mode they appear as unbound with codes 1003 or 1004 even though they can self-remediate.

Defense in depth around token protection

Microsoft frames token protection as one layer of a broader strategy:

• Minimize risk: harden endpoints with Microsoft Defender for Endpoint and Intune, require compliant devices, and restrict device code flow wherever possible.
• Detect and mitigate: use Microsoft Entra ID Protection detections such as Anomalous Token and Attacker in the Middle, require interactive phishing-resistant reauthentication for risky sign-ins, and use authentication context with sign-in frequency set to every time for sensitive operations.
• Protect against replay: token protection for supported apps, plus compliant network or location-based policies with Continuous Access Evaluation for the rest.

Phishing-resistant authentication for administrators pairs naturally with this; see authentication strengths for admins.

Troubleshooting

Checklist

• Microsoft Entra ID P1 in place; sign-in logs (interactive and non-interactive) in Log Analytics.
• Unsupported clients, devices and registration types inventoried; device filter exclusions added.
• Policy targets Exchange Online, SharePoint Online and Teams Services (plus AVD, Windows 365 and Windows Cloud Login if used), not the Office 365 group.
• Device platforms set to Windows (or iOS and macOS); client apps set to Mobile apps and desktop clients only.
• Require token protection for sign-in sessions selected; policy in report-only mode first.
• Status codes reviewed; users with 1002 or 1006 remediated before enforcement.
• Block unknown platforms and require compliance on known platforms.
• Help desk briefed on registration prompts and unsupported apps.

References

• Token protection in Microsoft Entra Conditional Access
• Token protection deployment guide - Windows
• Token protection deployment guide - Apple platforms
• Protecting tokens in Microsoft Entra ID
• Conditions in Conditional Access policies
• Set-MgGraphOption