14.7 Continuous Access Evaluation (CAE)

Continuous Access Evaluation (CAE)

CAE is the control that closes the revocation gap. Instead of waiting up to 90 minutes for access tokens to expire, CAE-enabled applications re-evaluate the token against critical events in near-real-time.

How CAE works

Without CAE: an access token is valid until it expires. The resource server (Exchange, SharePoint) does not check back with the identity provider during the token’s lifetime. If the user is disabled or tokens are revoked, the resource server does not know until the next token renewal.

With CAE: the resource server subscribes to critical event notifications from Entra ID. When a critical event occurs, the resource server evaluates the event and may reject the current access token — even if it has not expired.

Critical events that trigger CAE re-evaluation:

• User account disabled or deleted
• Password changed or reset
• MFA required (new conditional access policy)
• Admin explicitly revokes refresh tokens
• Entra ID detects elevated user risk

CAE-aware applications: Exchange Online, SharePoint Online, Teams, and Graph API are CAE-aware. Third-party applications and older clients may not support CAE — they continue to honour the access token until natural expiry.

Standard vs strict enforcement

Standard CAE (default in E5): Resource servers evaluate critical events within 1-15 minutes. This significantly reduces the revocation gap from 90 minutes to 15 minutes or less. However, standard CAE allows some flexibility — the resource server may cache the evaluation result briefly.

Strict CAE (Conditional Access configuration): Enforces IP location evaluation on every access. If the token was issued from one IP and is used from a different IP, strict CAE triggers re-evaluation. This catches token replay where the attacker’s IP differs from the user’s original IP — which is the exact AiTM pattern.

Enabling strict CAE: Conditional Access → new policy → Session controls → “Customize continuous access evaluation” → “Strictly enforce location policies.” Apply to all users or a targeted group.

Blast radius: CAE strict mode forces re-evaluation on IP changes. Users who legitimately change IPs (mobile network handoff, VPN disconnect/reconnect) may experience brief session interruptions as the token is re-evaluated. In practice: negligible impact for desktop users on stable networks. Noticeable for mobile users on cellular networks. Tenant-wide for users in the policy scope.

Cost impact: £0. CAE is included in Entra ID P1/P2 (E5 includes P2).

Rollback: Modify or remove the conditional access policy. Effect is immediate.

Compliance mapping: NIST CSF PR.AC-7 (Authentication). ISO 27001 A.8.5 (Secure authentication). SOC 2 CC6.1 (Logical access controls).

Verify after deployment:

1
2
3
4
5
6
7
8

// Check CAE enforcement in sign-in logs
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName == "r.williams@northgateeng.com"
| where AuthenticationProcessingDetails has "CAE"
| project TimeGenerated, IPAddress, AppDisplayName,
    AuthenticationProcessingDetails
| take 10

CAE events appear in AuthenticationProcessingDetails with “Continuous Access Evaluation” entries showing the evaluation result.

Subsection artifact: CAE deployment instructions with blast radius, rollback, and verification query. This is part of the CAE/Token Protection Deployment Guide artifact.

Knowledge check

CAE deployment decision framework

Before deploying CAE strict mode, assess the impact on your environment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Assess: how many sign-ins involve IP changes? (predicts CAE strict mode impact)
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "0"
| summarize IPs = make_set(IPAddress, 20), IPCount = dcount(IPAddress)
    by UserPrincipalName
| where IPCount > 2
| summarize
    UsersWithMultipleIPs = count(),
    AvgIPsPerUser = avg(IPCount),
    MaxIPsPerUser = max(IPCount)

If >30% of users have 3+ IPs: CAE strict mode will trigger frequent re-evaluations for mobile users and VPN users. Deploy in report-only mode first (Conditional Access → report-only) for 2 weeks. Review the what-if results: how many sign-ins would have been challenged? Are they legitimate IP changes (VPN, mobile) or suspicious?

If <10% of users have 3+ IPs: CAE strict mode can be deployed with minimal disruption. Most users sign in from 1-2 stable IPs — the strict location enforcement affects a small percentage.

CAE and conditional access token protection — which to deploy first?

Deploy CAE strict mode first. It is less disruptive (no device requirement) and catches the most common token replay scenario (attacker IP differs from user IP). Token protection (subsection 14.8) adds device binding on top — deploy it second, after confirming CAE is stable.

For environments with high BYOD usage: CAE strict mode may be the only deployable option (token protection requires managed devices). CAE provides strong protection against token replay from different IPs — which covers the vast majority of AiTM-originated attacks.

Monitoring CAE enforcement:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// CAE events in sign-in logs — track enforcement and challenges
SigninLogs
| where TimeGenerated > ago(7d)
| extend CAEDetails = tostring(AuthenticationProcessingDetails)
| where CAEDetails has "Continuous Access Evaluation"
| summarize
    CAEEvents = count(),
    Challenged = countif(CAEDetails has "challenge"),
    Passed = countif(CAEDetails has "satisfied")
    by bin(TimeGenerated, 1d)
| order by TimeGenerated desc

Track daily: how many CAE evaluations occurred, how many resulted in challenges (re-authentication required), and how many passed. A steady baseline of CAE evaluations with occasional challenges is healthy. A spike in challenges may indicate: an attacker attempting token replay (the challenge blocked them), or a legitimate network change affecting many users (VPN outage, office IP change).