Entra ID Conditional Access Token Protection: How to Defend Against Token Theft with Token Binding
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Token theft became the dominant Microsoft 365 account compromise method in 2022 to 2024 as MFA adoption increased. Attackers using AiTM phishing frameworks (Evilginx, Modlishka, Muraena) proxy the victim's authentication and capture the session token -- the MFA step completes successfully on the victim's side, but the attacker receives a valid authenticated cookie. Token Protection makes that stolen token worthless because it can only be used from the device that originally authenticated. This guide covers deployment in enforced mode and the compatibility limitations to plan for.
Prerequisites Before Deployment
Token Protection requires: Entra ID P2 licenses for all users in scope (included in Microsoft 365 E5 and Entra ID P2 standalone). Windows devices must be Entra ID joined or Entra ID hybrid joined AND enrolled in Intune (or at minimum compliant per Intune compliance policy). macOS and iOS support is available in public preview as of 2025; Android and Linux are not yet supported for enforcement. The token binding is implemented using device keys (PRT -- Primary Refresh Token) stored in the device's TPM. Devices without TPM 2.0 cannot fully support token binding enforcement. Verify your device fleet: Get-MgDeviceManagementManagedDevice -Filter "isEncrypted eq true" -- all devices intended to be in scope need Entra hybrid join or Entra join status, Intune enrollment, and TPM 2.0. Assess the coverage: if 40% of your devices are unmanaged personal devices, enforce Token Protection only on the managed population initially.
Configure in Report-Only Mode First
In the Entra admin center, navigate to Protection > Conditional Access > Policies > New Policy. Name: Token Protection - Pilot. Assignments > Users: Include a pilot group of 50 to 100 users on managed Entra ID joined devices. Assignments > Cloud Apps: Include Microsoft Office 365 Exchange Online and Microsoft SharePoint Online to start (the highest-risk apps for AiTM compromise). Session > Token protection: toggle to Require token protection for sign-in sessions. Enable policy: Report-only. After 1 to 2 weeks in Report-Only, review the Sign-in logs (filter for Conditional Access result = Report-only failure). Events with CA failure reason related to token protection indicate sessions where a user authenticated from an unmanaged device or a device where token binding was not possible. Common causes of report-only failures: personal BYOD devices (not enrolled in Intune), browser sessions on unmanaged devices, legacy desktop applications that do not support token binding, and iOS/macOS devices (limited support).
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Enforce and Handle Compatibility Issues
After the Report-Only assessment, switch the pilot group policy to Enabled. Monitor the pilot group for authentication failures over the first week. The most common enforcement issue: users who sometimes authenticate from unmanaged personal devices will be blocked when those sessions lack token binding. Resolution: create a separate Conditional Access policy for those users that requires either compliant device (for managed device sessions) or a Named Location restriction (if they can only access from office network on unmanaged devices). For application compatibility: some older MAPI-based desktop Outlook versions and some third-party clients do not support token binding. These applications will fail authentication when Token Protection is enforced. The Microsoft 365 Apps (Current Channel, version 2306 or later) support token binding. Upgrade clients that fail. Expand scope to all users after the pilot completes successfully.
Monitor Token Binding Violations for Threat Detection
Even without enforcement, running Token Protection in Report-Only mode is a valuable detection signal. A user who authenticated from their managed corporate device should not have sign-in events failing token protection -- if they do, their token may have been stolen and replayed by an attacker. KQL query for suspicious token protection failures in Sentinel: SigninLogs | where ConditionalAccessStatus == 'reportOnlyFailure' | where AuthenticationRequirement == 'multiFactorAuthentication' | where DeviceDetail.isManaged == true | project TimeGenerated, UserPrincipalName, IPAddress, DeviceDetail, AppDisplayName, ConditionalAccessPolicies | where TimeGenerated > ago(7d). A user who completed MFA on their managed device but whose token then appears with a binding violation from a different IP address is a high-confidence AiTM victim. Alert on this pattern as a P1 incident: it indicates successful AiTM phishing with the token already in attacker hands.
Token Protection vs Phishing-Resistant MFA
Token Protection and phishing-resistant MFA (FIDO2, Windows Hello for Business) are complementary controls that address different parts of the AiTM attack chain. Phishing-resistant MFA prevents the attacker from completing the MFA step in an AiTM scenario -- FIDO2 keys are origin-bound and cannot be proxied. If phishing-resistant MFA is enforced for all users, AiTM phishing is blocked before a token is issued. Token Protection assumes the attacker did capture a token (possibly via a technique other than AiTM, or via a platform not yet covered by phishing-resistant MFA) and prevents replay. The ideal architecture: phishing-resistant MFA for all users who can use it, Token Protection as an additional defense for device-bound token validation. Organizations moving toward full FIDO2 deployment can use Token Protection as an interim control while completing the FIDO2 rollout.
The bottom line
Token Protection is a meaningful defense against the AiTM token theft attacks that bypassed MFA requirements throughout 2022 to 2024. It requires P2 licenses and managed Entra ID joined devices. Deploy in Report-Only first to identify unmanaged device usage, then enforce on the managed device population. Run the report-only monitoring as a detection layer even before enforcement -- token binding violations from authenticated managed devices are a high-confidence indicator of active token theft.
Frequently asked questions
Does Token Protection work against all AiTM phishing kits?
Token Protection prevents the stolen token from being replayed on a different device. It does not prevent the initial phishing -- the user still authenticates through the AiTM proxy and the attacker captures the session cookie. But when the attacker attempts to use the captured cookie/token from their device, the token binding check fails (the token was issued to the victim's device with its specific device key, not the attacker's device). The protection is effective against token theft replay; the initial credential/session capture still occurs.
What is a Primary Refresh Token (PRT) and how does it relate to Token Protection?
A Primary Refresh Token is a long-lived credential issued to Entra ID joined or hybrid joined Windows devices that allows the device to obtain access tokens for cloud resources without re-authenticating. The PRT is tied to the device's TPM and includes device identity claims. Token Protection leverages the PRT's device binding: when a user authenticates on an Entra ID joined device, the resulting tokens include a cryptographic proof of device identity using the TPM-bound device key. This proof cannot be replicated by an attacker who only has the token -- they would also need the TPM key, which never leaves the device.
Can Token Protection be bypassed?
Current known bypass scenarios: the attacker compromises the device itself (endpoint compromise, not just token theft), in which case the attacker can use the device's TPM key to prove device identity. Physical access to an unlocked enrolled device bypasses token binding. Devices without TPM 2.0 may not fully enforce binding. Unmanaged device sessions (BYOD, personal devices) are not covered unless you explicitly block access from unmanaged devices. Token Protection is not a silver bullet -- it is one layer in a defense-in-depth strategy.
How is Token Protection different from Continuous Access Evaluation (CAE)?
These are different controls. Continuous Access Evaluation ensures that changes in user or session risk (account disabled, risky sign-in detected) are reflected in access token validity within seconds rather than waiting for token expiry. Token Protection ensures that valid tokens can only be used on the device they were issued to. They complement each other: CAE handles revocation scenarios (token theft detected, revoke immediately), Token Protection handles the case where theft has not been detected yet but replay is attempted from a different device.
What telemetry should I collect to detect AiTM phishing attacks if Token Protection is not yet deployed?
Without Token Protection, detect AiTM via log analysis: in SignInLogs, look for an interactive sign-in from the victim's location followed within minutes by a non-interactive sign-in (refresh token use) from a different IP address or ASN -- this pattern indicates token theft replay. Also monitor for mailbox inbox rules created immediately after sign-in (via Office 365 Unified Audit Log search for New-InboxRule events), which is the most common attacker action after AiTM success. Entra ID Identity Protection's 'Anomalous Token' risk detection is specifically designed to flag AiTM-derived token use. Enable it and configure a risk-based Conditional Access policy that requires re-authentication when Anomalous Token risk is detected.
What is the licensing requirement for Conditional Access Token Protection and which token types does it cover?
Conditional Access Token Protection (also called token binding) requires Microsoft Entra ID P2 licensing (included in Microsoft 365 E5, EMS E5, and Microsoft 365 Business Premium). P1 licensing supports most Conditional Access features but not Token Protection specifically. Token Protection currently applies to access tokens and refresh tokens issued to applications that support Continuous Access Evaluation (CAE) and that have been onboarded to the Token Protection preview -- not all Microsoft 365 services support it at rollout. Primary token uses covered: Exchange Online access tokens (Outlook clients), SharePoint Online access tokens (SharePoint clients), and Teams tokens. Third-party applications that do not implement the Proof of Possession (PoP) token binding protocol are not covered and will fail if you target them in a Token Protection Conditional Access policy -- always deploy in report-only mode first to identify incompatible applications before enforcement. Review the Entra ID Token Protection documentation for the current list of supported applications as coverage expands.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.