Standard OAuth access tokens remain valid until expiry even after account disable or password reset. CAE closes that exposure window.

Preface

Resource providers traditionally trust issued tokens for their full lifetime without re-checking identity state. Exchange Online, SharePoint Online or Microsoft Graph validate the token signature, audience and expiry, and that is all. If the user was disabled five minutes ago, the resource has no way of knowing until the client comes back to Entra ID for a new token.

Continuous Access Evaluation (CAE) changes that contract. Entra ID and CAE-capable resource providers share a channel for critical events, and the resource can reject a still-valid token and send the client back for re-authentication. This is what NIST SP 800-207 means by dynamic, per-session policy rather than a one-time decision at the front door.

Problem

After remediation starts, attackers can keep using stolen tokens for up to about an hour to exfiltrate data or pivot. In a real incident the sequence usually looks like this: a user is phished through an adversary-in-the-middle page, the attacker captures a session, the SOC detects the sign-in and disables the account or resets the password. The defenders consider the account contained. The attacker, holding an access token issued before the reset, keeps reading mail and downloading files until that token expires.

Three details make the gap worse than it looks:

  • Refresh tokens outlive access tokens. A password reset alone does not always invalidate every refresh token; an explicit session revocation is the reliable step.
  • Sign-in logs do not show token reuse. They record token issuance. Use of an existing token is only visible in the resource's own logs, so "no new sign-ins" does not mean "no activity".
  • Location rules are checked once. Without CAE, a Conditional Access location condition is evaluated when the token is issued, not when it is used from a different network later.

How CAE works in practice

CAE relies on two mechanisms. The first is critical event evaluation: Entra ID notifies participating resources when a user account is deleted or disabled, a password is changed or reset, MFA is enabled for the user, an administrator revokes all refresh tokens, or Entra ID Protection detects elevated user risk. The resource then rejects that user's tokens on the next request.

The second is Conditional Access policy evaluation at the resource. Supported services re-check the IP address a request arrives from against the network conditions in your policies, so a token issued on the corporate network stops working when it is replayed from somewhere else.

When a resource rejects a token, it returns a claims challenge. CAE-aware clients (current Outlook, Teams, OneDrive and Office apps, and applications built with recent MSAL versions that declare the capability) handle that challenge by silently or interactively returning to Entra ID. Because revocation can now be pushed, CAE-aware sessions receive longer-lived tokens, up to about 28 hours. Clients and resources that do not support CAE keep the normal short token lifetime and none of the near real-time protection.

Solution

Align with NIST SP 800-207:

  1. Enable CAE tenant-wide so services listen for critical security events. In current tenants CAE is on by default and is controlled through the Conditional Access session control "Customize continuous access evaluation". Confirm no policy disables it.
  2. Instant session revocation on disable, password reset, or location change outside trusted boundaries. Build revocation into the incident runbook rather than relying on the reset alone.
  3. Strict location enforcement throughout the session, not only at first sign-in. Use the strict enforcement mode for the populations where IP-bound access matters most, such as administrators and finance.

Design guidance

  • Inventory egress IPs first. Strict location enforcement compares the IP seen by the resource with your named locations. Split tunneling, IPv6 egress, cloud proxies and SSE/ZTNA points of presence often present a different address to Exchange than to Entra ID. Every legitimate egress address, IPv4 and IPv6, must be in a named location.
  • Scope strict mode narrowly at first. Apply it to a pilot group of administrators, then expand. Broad strict enforcement without an accurate IP inventory produces repeated sign-in loops.
  • Pair CAE with sign-in frequency where CAE does not reach. Third-party SaaS and custom APIs that do not implement CAE still rely on token lifetime. Shorter sign-in frequency for sensitive apps limits that exposure.
  • Do not treat CAE as phishing protection. CAE shortens the window after detection. Phishing-resistant MFA reduces the chance of theft.

Implementation steps

  1. Check the legacy CAE setting and every Conditional Access policy for a CAE session control set to disabled.
  2. Confirm client versions: managed Office apps current, and line-of-business apps on an MSAL version that supports claims challenges.
  3. Build named locations that cover all corporate and SSE egress ranges, including IPv6.
  4. Create a report-only policy with strict location enforcement for a pilot group, review the sign-in logs for mismatched IP results, then switch it on.
  5. Update the compromised-account runbook: disable or reset, then revoke sessions, then confirm in resource logs that activity stopped.

PowerShell: Check CAE Status

The tenant-level CAE object is exposed under the identity namespace in the beta Graph module, and session revocation is part of the v1.0 module:

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgBetaIdentityContinuousAccessEvaluationPolicy | Format-List

# Incident response: revoke refresh tokens and sessions for a user
Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId "user@contoso.com"

The tenant-level object is a legacy setting; the authoritative configuration in current tenants is the session control in Conditional Access, so review your policies as well.

Monitoring and detection

The Entra sign-in logs include a filter for CAE-related sign-ins, and the "Continuous access evaluation insights" workbook shows IP mismatches between Entra ID and resources. In Microsoft Sentinel, a useful starting hunt is successful token issuance shortly after a containment action: 

let window = 2h;
let containment = AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName in ("Disable account", "Reset password (by admin)", "Reset user password")
| extend UPN = tostring(TargetResources[0].userPrincipalName)
| project ActionTime = TimeGenerated, UPN, OperationName;
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d) and ResultType == "0"
| join kind=inner containment on $left.UserPrincipalName == $right.UPN
| where TimeGenerated between (ActionTime .. (ActionTime + window))
| summarize Events = count(), Apps = make_set(AppDisplayName), IPs = make_set(IPAddress)
    by UserPrincipalName, OperationName, ActionTime

Because sign-in logs show issuance, not use, also check resource-side telemetry: the MicrosoftGraphActivityLogs table, the unified audit log for Exchange and SharePoint, and Defender for Cloud Apps activity. Activity from an account after containment, with no matching new sign-in, points to a token that was not revoked.

Common mistakes

  • Assuming a password reset ends every session, and skipping explicit revocation.
  • Enabling strict location enforcement tenant-wide without an egress inventory, then disabling CAE entirely after the help desk calls start.
  • Expecting CAE to protect third-party apps or old clients that do not support it.
  • Closing an incident based on sign-in logs alone, without checking resource activity.

Where to start

Confirm that no policy disables CAE, add session revocation to your account-compromise runbook, and deploy the Sentinel hunt above. Then build an accurate egress IP inventory and pilot strict location enforcement with your administrators. Those steps turn a one-hour exposure window into minutes for the services that matter most.