I've stopped counting the tenants where continuous access evaluation (CAE) in Microsoft Entra ID is either misunderstood or simply left at its defaults, which wastes much of what it can do. CAE delivers something admins have wanted for years. When a user is disabled, a password is reset, risk is detected or a sign-in moves to a different IP location, apps like Exchange Online, SharePoint Online, Teams and CAE-capable Microsoft Graph clients block access almost immediately. You no longer have to wait for a token to expire an hour later. Token theft hasn't gone away (AiTM phishing is the obvious example, which I wrote about in my post on AiTM phishing and Entra ID Protection), so this matters more than ever. In real tenants, though, getting CAE to work properly takes more than flipping a switch.

CAE protects a defined set of events and apps today

Continuous access evaluation reacts to specific events in specific applications. If a user is disabled, changes their password, reaches 'high' user risk, has a token revoked through the portal, or shows up from a different public IP, CAE-enabled apps check back with Entra ID. If necessary, they invalidate the token on the spot and force the user to authenticate again. Under the old model a token could stay valid for 60 minutes after a major change, so this is a big step forward for security. It relies on a direct connection between Entra ID and services such as Exchange Online, SharePoint Online and Teams. Microsoft documents the details and the current scope here.

For me, the main benefit is the near real-time reaction to critical changes, location changes and risky sign-ins in particular. Keep in mind, though, that CAE doesn't cover every app. Legacy protocols like IMAP or SMTP and most third-party apps are still out of scope. You handle those by blocking basic auth and legacy clients, not by counting on CAE.

Strict location enforcement is a session control worth using

Strict location enforcement as a Conditional Access session control gets far less attention than it deserves. Rather than checking location only at sign-in, CAE blocks an active session as soon as it sees traffic from an IP range that isn't allowed. With the right configuration, that stops attackers who steal tokens or use VPNs or proxies to get around access policies. The documentation explains the details and requirements for strict enforcement clearly.

This is where I see a lot of organizations trip up. Strict location enforcement only works if you've documented every possible egress IP (IPv6 included) for every access path. VPN split tunneling, proxy farms or cloud access brokers can easily hide the user's real public IP from CAE. If you use something like Microsoft Global Secure Access (ZTNA, still in preview), you have to turn on source IP restoration. Otherwise all user traffic appears to come from a single Microsoft IP, and CAE loses most of its value.

Pro tip: If you run ZTNA or cloud proxies, enable source IP restoration every time. Without it, CAE can't enforce location-based session controls reliably, and real threats may go unnoticed.

Most misconfigurations come from a few missing prerequisites

In my experience, most misconfigurations boil down to three issues. People don't document all outbound IPs, they skip IPv6 (even though it keeps spreading), and they forget about proxies and VPNs that hide where users really are. If you want CAE and strict location enforcement to pay off, check that:

  • All outbound (egress) IPs, including IPv6, are documented and configured in Conditional Access
  • VPN split tunneling is accounted for
  • Proxies or cloud access brokers are not obscuring user IP (source IP restoration is enabled)
  • Only CAE-capable apps are in the scope; legacy clients remain a risk

This work is tedious, but CAE can't do its job without it. Many admins never go back to check whether their egress IPs have changed, which happens a lot when networks get merged or a new VPN or proxy solution goes live. Seeing CAE actually doing its thing is a separate challenge, so monitoring and testing come next.

The sign-in logs and the CAE workbook show whether CAE is working

To find out whether CAE is active and doing its job, I start with the Entra ID sign-in logs in the Azure portal. Every session has 'Token details' that tell you whether a CAE token was used and whether location or session revocation events took place. For a more structured view, the CAE Workbook in the Azure portal visualizes token status and event timelines.

Here's a simple hands-on test. Open a session in a CAE-capable app such as Exchange Online, create a Conditional Access policy with strict location, and then change your client IP, for example by switching Wi-Fi networks or VPN endpoints. The sign-in logs should show the token being invalidated right away. The CAE workbook helps you follow the sequence, and the Mermaid diagram below gives a high-level picture of a location-based CAE revocation:

sequenceDiagram
    Client ["User client"] ->> Entra ["Entra ID"]: ["Token request"]
    Entra ->> Client: ["CAE token"]
    Client ->> Service ["Exchange Online"]: ["Access with token"]
    Service ->> Entra: ["Check token"]
    Entra -->> Service: ["Token valid"]
    Client ->> Service: ["Access from new IP"]
    Service ->> Entra: ["Check token"]
    Entra -->> Service: ["Token invalid"]
    Service -->> Client: ["Access denied"]

Figure: CAE notices a location change and invalidates the token.

After two years I consider CAE a must-have when the groundwork is done

By now I see continuous access evaluation as a must-have for every Microsoft 365 tenant that handles sensitive data, provided the groundwork is solid. The biggest gap I still run into is network hygiene. If your egress IPs aren't kept current, or proxies and VPNs aren't handled correctly, strict location enforcement won't work. Admins also need to remember that CAE only applies to modern, CAE-capable apps, and legacy protocols are just as risky as they always were. Once everything is set up properly, though, CAE gives you much better control over user sessions and much more visibility into them. Checking the sign-in logs and the CAE workbook regularly has become part of my standard routine. If you want to read more about defending against token theft and session abuse, have a look at my post on AiTM phishing in Microsoft 365.