Six Conditional Access Defenses Against Token Theft, and What Each One Misses
TL;DR
- Token harvesting and token replay are separate problems, and most Conditional Access policies only solve one of them.
- Requiring a managed or compliant device blocks AiTM token harvesting but does nothing against replay of a token stolen by malware or a malicious browser extension.
- Phishing-resistant MFA prevents the initial harvest and keeps the password out of the attacker's hands, but stolen tokens can still be replayed.
- Trusted location and Global Secure Access policies are the only two in this set that block both harvesting and replay.
- As of June 2025, Entra's token protection session control covers only Windows desktop clients for limited apps and requires P2 licensing.
Every token theft conversation eventually arrives at the same confused question: "We require MFA and compliant devices, so how did the attacker get in?" The answer is almost always that the policy stopped one half of the attack and nobody noticed the other half was wide open.
This post covers the prevention side of the token theft problem: six Conditional Access policies, the exact settings for each, what each one actually blocks, and the gap each one leaves. We have already covered what to do after a breach in our incident response runbook; this is how you make that runbook unnecessary. These policies focus on Conditional Access specifically. Protections across the rest of the AiTM and BEC kill chain are a topic of their own.
Harvesting and replay are two different problems
Before picking policies, separate the two events you are defending against:
- Initial token harvesting can happen many ways, but the most common is an adversary-in-the-middle (AiTM) attack, where a phishing page proxies the real Microsoft login and captures the session token.
- Token replay is the second act. If a token is harvested another way, through XSS, malware on a device, a malicious browser extension, or similar, the attacker presents that token from their own device.
- The two require different defenses. For example, enforcing a compliance policy for managed devices prevents token harvesting via AiTM, but it does not prevent replay if the attacker obtained the session token through one of those other methods.
Every policy below is graded against both halves.
What the attack looks like when it works
To test these policies, we used Evilginx to generate a malicious AiTM page that harvests session tokens from a user logging in:
- The simulation models a user clicking an email link that lands on a fake Microsoft login page
- In this example the user has passwordless sign-in set up; normally the password would be harvested along with the token
- The Microsoft 365 phishlet and fake page run on a domain registered years ago for testing (apollocyber.io)
Watch the simulation: harvesting a session token with an AiTM page (opens in new tab)
The comparison, before the detail
Here is the at-a-glance view of all six policies and what each prevents. Fair warning that applies to everything below: every one of these carries significant end-user impact if its prerequisites are not in place first.
Defense 1: Block unmanaged devices
Prerequisites:
- Devices are Entra Joined, Hybrid Joined, or Entra Registered
Conditional Access policy settings:
- Users > Include All Users
- Users > Exclude Break Glass account + Guest or external users > Service provider users
- Target Resources > All
- Conditions > Device Platforms > Windows
If hybrid:
- Grant > Grant Access > Require Microsoft Entra hybrid joined device
If cloud only:
- Conditions > Filter for Devices > Exclude > Trust Type > Entra Joined
- Grant > Block
What the attacker sees: Watch the token theft attempt against a managed-device policy (opens in new tab)
Where it wins:
- Achievable for many organizations, since the prerequisite is a managed device
- Prevents initial token harvesting via AiTM
Where it fails:
- Does not prevent token replay
- The user's password is still harvested if they are not set up for passwordless
Defense 2: Require Intune compliance
Prerequisites:
- Devices are managed and enrolled in Intune
- Compliance policies are configured for every supported device platform
Conditional Access policy settings:
- Users > Include All Users
- Users > Exclude Break Glass account + Guest or external users > Service provider users
- Target Resources > All
- Grant > Grant Access > Require device to be marked as compliant
What the attacker sees: same experience as the managed device policy.
Where it wins:
- More flexibility for device types, including BYOD, as long as devices are enrolled and compliant
- Prevents initial token harvesting via AiTM, with an asterisk
Where it fails:
- That asterisk: a working bypass exists, documented in Bypassing Intune Conditional Access with TokenSmith (opens in new tab)
- The user's password is still harvested if they are not passwordless
- More overhead to set up and support, including devices falling out of compliance
- Does not prevent token replay
Defense 3: Demand phishing-resistant MFA
Prerequisites:
- Authentication strengths configured to support phishing-resistant methods (FIDO2, passkeys, and similar)
- Users have registered a phishing-resistant method
Conditional Access policy settings:
- Users > Include All Users
- Users > Exclude Break Glass account + Guest or external users > Service provider users
- Target Resources > All
- Grant > Grant Access > Require authentication strength > Require Phishing-Resistant MFA
What the attacker sees: Watch the token theft attempt against phishing-resistant MFA (opens in new tab)
Where it wins:
- One of the strongest forms of MFA available
- Passwordless, so no password is harvested
- Prevents initial token harvesting via AiTM
Where it fails:
- End-user adoption is hard to win
- More overhead to set up and support, including helpdesk volume and the cost of FIDO2 keys
- Does not prevent token replay
Defense 4: Lock sign-ins to trusted locations
Prerequisites:
- Named locations set up for trusted IPs
Conditional Access policy settings:
- Users > Include All Users
- Users > Exclude Break Glass account + Guest or external users > Service provider users
- Target Resources > All
- Network > Include > Any Network Location
- Network > Exclude > Selected Network and locations > Include Named Location (or All Trusted Locations)
- Grant > Block Access
What the attacker sees: Watch the harvesting attempt blocked by the location policy (opens in new tab)
And on replay: Watch the replay attempt fail outside the trusted location (opens in new tab)
Where it wins:
- Prevents initial token harvesting via AiTM
- Prevents token replay
Where it fails:
- Hard to implement, with limited flexibility for end users
- More support overhead for mobile devices, travel, and everything else that leaves the office
Defense 5: Bind tokens to the device
Prerequisites:
- Devices are Entra Joined, Hybrid Joined, or Entra Registered
Conditional Access policy settings:
- Users > Include All Users
- Users > Exclude Break Glass account + Guest or external users > Service provider users
- Target Resources > Include > Office 365 Exchange and Office 365 SharePoint Online
- Conditions > Device platforms > Include > Windows
- Conditions > Client Apps > Mobile Apps and Desktop Clients
- Grant > (No Selection)
- Session > Require token protection for sign-in sessions (Preview)
Where it wins:
- Prevents token replay, with an asterisk
- Low end-user friction
Where it fails:
- Does not prevent token harvesting via AiTM
- Requires P2 licensing
- Only supports desktop clients, not the browser
- Only supports limited apps
That browser limitation is the asterisk, and it is a big one. We took this policy apart in detail in our breakdown of token protection in Conditional Access.
Defense 6: Route everything through Global Secure Access
Prerequisites:
- GSA settings configured in Entra (needs at least P1 licensing)
- GSA client deployed on workstations
Conditional Access policy settings:
- Users > Include All Users
- Users > Exclude Break Glass account + Guest or external users > Service provider users
- Network > Include > Any Network Location
- Network > Exclude > All Compliant Network Locations
- Grant > Block access
User experience with the GSA client on and off: Watch the GSA client sign-in comparison (opens in new tab)
What the attacker sees: Watch the token theft attempt against the GSA policy (opens in new tab)
Where it wins:
- Prevents both token replay and token harvesting via AiTM
- More flexibility than the alternatives: SASE and ZTNA instead of a traditional firewall, trusted IP list, or VPN
Where it fails:
- Deployment and management overhead, since the client must be installed on workstations
- Early in its lifecycle, with preview limitations such as not working on Arm and Copilot+ PCs as of June 2025
- Full capability beyond Microsoft traffic requires an add-on license
Microsoft's overview is here: What is Global Secure Access? (opens in new tab)
How to roll these out without burning your week
Three rules we hold to on every deployment:
- Evaluate the best policy against each client's specific dynamics rather than standardizing on one answer for every tenant
- Always start policies in report-only mode and test properly before enforcement
- Use a phased rollout in customer environments, expanding scope as each phase proves quiet
The pattern across all six policies is the lesson: nothing here is complete on its own. Pick the combination that covers both harvesting and replay for the way each client actually works, and verify it stays in place after you leave.
Frequently asked questions
Which Conditional Access policy should an MSP deploy first against token theft?
For most organizations, requiring a managed or compliant device is the most achievable starting point because the prerequisite is device enrollment you likely already have. It blocks AiTM harvesting, though it does not stop replay of tokens stolen by other means.
Does requiring a compliant device fully prevent token theft?
No. It prevents the initial harvesting via AiTM phishing pages, but a documented TokenSmith bypass exists, the user's password can still be harvested if they are not passwordless, and tokens stolen through malware or browser extensions can still be replayed.
Why test these policies in report-only mode first?
Every policy in this set carries real end-user impact when prerequisites are missing. Report-only mode shows you exactly which sign-ins would have been blocked, so you can fix enrollment gaps and exclusions before users feel anything.
Are these policies actually in place across your tenants?
Designing the policy is the easy half. CloudCapsule scans every tenant you manage against 250+ controls in 60 seconds, including the Conditional Access protections in this post, and shows you exactly where token theft defenses are missing.
Run a free scan
Written by
Nick Ross
CEO · Microsoft MVP · Founder, T-Minus 365
Nick is not just a CEO, he's a respected thought leader and influencer in the MSP space. Tens of thousands of MSPs learn through his YouTube channel, T-Minus365. Nick has been honored as a three-time Microsoft MVP for his educational content; his expertise and influence are the backbone of our mission, ensuring that you are in the best hands when it comes to security.
Nick joined Pax8 in 2017, where he would ultimately oversee product management for PSA and Microsoft integrations. Following his tenure at Pax8, Nick has continued to demonstrate his leadership prowess as an executive at various MSPs, culminating in his most recent role at Sourcepass.
Nick holds a Bachelor's Degree in Business Management from Florida State University, as well as a Minor Degree in Entrepreneurship. In his free time, Nick is an avid hiker, reader, and fitness-junkie.
