Continuous access evaluation (CAE) lets Exchange Online, SharePoint Online, Teams and Microsoft Graph react to a disabled account or a network move within minutes instead of waiting for an access token to expire. It also explains why users get blocked mid-session or receive one-hour tokens where you expected long ones. In this post I'll explain how CAE works, what strict location enforcement adds, and how to find and fix IP mismatches.
Errors this guide fixes
insufficient_claimsHTTP 401 claim challenge (WWW-Authenticate)
How it works#
Without CAE, an access token is valid for about an hour and policy is only reevaluated when the client refreshes it. CAE, based on the OpenID Continuous Access Evaluation Profile, opens a two-way conversation between Microsoft Entra ID and the resource. It covers two scenarios.
Critical event evaluation#
Resources subscribe to these Entra events and act on them in near real time (propagation can take up to 15 minutes):
- The user account is deleted or disabled.
- The user's password is changed or reset.
- Multifactor authentication is enabled for the user.
- An administrator revokes all refresh tokens for the user.
- Microsoft Entra ID Protection detects high user risk.
Critical event evaluation doesn't depend on Conditional Access, so it works in every tenant.
Conditional Access policy evaluation#
Exchange Online, SharePoint Online, Teams and Microsoft Graph synchronize key Conditional Access policies and enforce IP-based location conditions themselves. IP location enforcement is instant.
Claim challenges and token lifetime#
When a resource rejects a token that hasn't expired, it returns HTTP 401 with a claim challenge (error="insufficient_claims" in the WWW-Authenticate header). A CAE-capable client skips its token cache and goes back to Entra ID with its refresh token and the challenge; Entra ID reevaluates and either prompts the user or denies access. Because revocation no longer waits for expiry, CAE sessions get tokens valid for up to 28 hours, and configurable token lifetime policies aren't honored for them. Sign-in frequency still applies with or without CAE.
Support depends on the client and resource. Outlook on every platform supports CAE against Exchange Online and SharePoint Online. Office desktop and mobile apps are supported, Office web apps aren't. OneDrive for Windows and Mac aren't supported against SharePoint Online, and Teams is only partially supported; its calls and chat services ignore IP-based Conditional Access. Guest accounts aren't supported. On the Semi-Annual Enterprise Channel, Office loses CAE if DisableADALatopWAMOverride or DisableAADWAM is enabled, so don't disable Web Account Manager.
Location enforcement: standard vs strict#
CAE only understands IP-based named locations. Country/region locations and the legacy MFA trusted IPs are invisible to it: when a sign-in matched one of those, Entra ID issues a one-hour token with no instant IP check. The same happens when the IP ranges across your location policies add up to more than 5,000.
The common problem is a split path: Entra ID sees one egress IP and the resource sees another, because of split-tunnel VPNs, proxies, SD-WAN, SNAT, local internet breakout or IPv6 at the resource but IPv4 at Entra ID.
| Mode | Entra ID sees an allowed IP, the resource sees one that isn't | Use it when |
|---|---|---|
| Standard (default) | Entra ID issues a one-hour token that suspends IP checks at the resource until it expires; other events are still enforced | Any topology |
| Strictly enforce location policies (preview) | Access is blocked | Egress IPs are dedicated and known for both Entra ID and all resource traffic |
Before you choose strict mode, every IPv4 and IPv6 egress address users can come from must be in your IP-based named locations, and no Conditional Access policy in scope may be one that CAE doesn't support. Don't use it if you send traffic for non-Microsoft 365 apps through Global Secure Access: source IP restoration isn't supported there, so users are blocked even from a trusted location.
Step-by-step: troubleshooting CAE#
1. Confirm the session is CAE#
Go to Entra ID › Monitoring & health › Sign-in logs, apply the Is CAE Token filter and narrow by user and application. One sign-in produces several requests, and only one of them is marked as CAE, on either the interactive or the non-interactive tab, so check both before you conclude CAE isn't in use.
2. Look for IP mismatches#
Add the IP address (seen by resource) column and filter out blank values. Blank means the resource saw the same address as Entra ID; a value means a mismatch worth investigating. For blocked events, the Conditional Access tab shows which policy acted. For a tenant-wide view, open Entra ID › Monitoring & health › Workbooks and the public template Continuous access evaluation insights (it needs sign-in logs streamed to Log Analytics). Its IP mismatch table lists the addresses seen on both sides.
3. Fix the network or the named locations#
- Add your organization's dedicated egress IPs, IPv4 and IPv6, to an IP-based named location under Entra ID › Conditional Access › Named locations, after confirming they really belong to you. My named locations guide covers the details.
- Never add shared proxy or other non-dedicated egress IPs as trusted; that weakens every location policy.
- Where split tunneling causes
insufficient_claimsor "Instant IP Enforcement check failed" blocks, Microsoft notes you may need to route that traffic through a trusted egress or VPN.
4. Apply urgent changes immediately#
Policy and group membership changes can take up to a day to reach resource providers. When a change must apply to a user right now, revoke their sessions with Revoke-MgUserSignInSession -UserId <UPN> or Revoke sessions on the user's page in the admin center.
5. Roll out strict enforcement in waves#
Start from a tested IP-based location policy for a pilot group, then set Session › Customize continuous access evaluation to strictly enforce location policies. Check IP address (seen by resource) for the pilot users, add any legitimate egress IPs the workbook finds, and widen the group step by step. The same session control can disable CAE for a scoped group; keep that for exceptions you've documented.
Verify#
- Sign-ins from Outlook and Teams show Is CAE Token on one of the requests.
- IP address (seen by resource) is blank, or every value is in your named locations, and the workbook's mismatch table stays empty.
- Disable a test account: it loses access to mail and files within minutes. Re-enabling it takes about 15 minutes to reach SharePoint Online and Teams, and 35 to 40 minutes for Exchange Online.
- With strict mode, a pilot device leaving the trusted network is blocked at the resource immediately.
Tips & gotchas#
- Coauthoring: users editing a shared document may keep access until they close it or the app, or for up to an hour with an IP policy. A SharePoint network location policy cuts coauthoring sessions to 15 minutes, adjustable with
Set-SPOTenant -IPAddressWACTokenLifetime. - Push notifications: message previews aren't covered by IP policies; opening the item is.
- Frequent prompts are rarely CAE alone: see sign-in frequency and reauthentication prompts.
