Require Token Binding Protection: Token Theft and Replay Protection

Microsoft Entra issues access tokens and refresh tokens after successful authentication. These tokens are what actually authorises access to Microsoft 365 services — once a token is issued, it can be presented to Exchange Online, SharePoint, Teams, and other services without re-authentication. Token theft attacks steal these tokens and replay them from a different device or location, giving the attacker authenticated access without ever knowing the user's password.

Token binding protection — implemented in Entra ID through Conditional Access and the Continuous Access Evaluation (CAE) framework — ties tokens to specific devices and conditions, making stolen tokens significantly harder to replay from a different context. Combined with CAE, which allows near-real-time token revocation when risk conditions change, this substantially reduces the window of opportunity for token replay attacks.

This is particularly relevant in the context of AiTM phishing attacks and session hijacking, which are increasingly common attack vectors against Microsoft 365 environments.

• Stolen access tokens can be replayed from any device and location for as long as they remain valid — typically one hour for access tokens, potentially days or weeks for refresh tokens
• AiTM phishing attacks that capture tokens during the authentication flow can use them immediately without triggering any additional challenge
• Token theft via malware gives attackers persistent access that survives password resets
• Continuous Access Evaluation may not revoke tokens promptly if the configuration relies on expired token intervals rather than real-time events
• Session anomalies (IP changes, location changes) are detected but the token remains valid until the next evaluation interval

Token binding and CAE are broadly compatible with standard Microsoft 365 usage. Considerations:

• Older Microsoft 365 client applications that don't support Continuous Access Evaluation may have reduced functionality or require more frequent re-authentication
• Strict location-based token binding may cause disruption for users who move between networks during a work session (office to VPN, for example)
• Licensing note: some advanced token protection controls require Entra ID P2

• Review whether Continuous Access Evaluation is already enabled for your tenant (it is enabled by default for most tenants but may have been disabled)
• Check which Microsoft 365 client apps in use support CAE — modern Outlook, Teams, and browser-based access are typically supported
• In Conditional Access, check whether any policies have a Session control for "Token protection" or equivalent binding controls
• Consider whether strict location enforcement (which prevents token use from any IP that wasn't present at authentication time) is appropriate for your user population
• Deploy in Report-only mode and review impact before enforcing strict token binding

1. Confirm Continuous Access Evaluation is enabled in Entra ID > Security > Continuous Access Evaluation
2. Create or update a Conditional Access policy with a Session control enabling token protection (where available for your licence level)
3. Consider enabling strict sign-in frequency controls (e.g. every 1 hour) as a complementary measure to limit how long tokens remain valid without re-authentication
4. Deploy in Report-only mode and review sign-in frequency impact on productivity before enforcing
5. Enforce the policy and monitor for sign-in frequency complaints, adjusting the interval as needed
6. Enable named location policies to ensure tokens used from dramatically different locations trigger a re-authentication challenge

Microsoft: Continuous Access Evaluation

Microsoft: Token protection in Conditional Access

Microsoft: Configure authentication session management

After enforcing this control, review these related areas:

• Session Hijack via Unusual IP Change — token binding directly addresses the risk surfaced by this GSO alert; the two controls work together
• Disable Persistent Browser Sessions — combine session lifetime controls with token binding for a comprehensive session management posture
• OAuth Phishing via First-Party Microsoft Apps — token theft via OAuth phishing is one of the primary scenarios this control mitigates
• CA MFA Bypass Paths — ensure token protection policies don't have exclusions that undermine the session management posture
• Phishing URL Clicked — AiTM phishing campaigns are specifically designed to capture tokens; this control reduces the value of stolen tokens