Continuous Access Evaluation (CAE): what happens between token issuance and expiry

Why token expiry leaves a response gap

An access token can remain unexpired after the conditions that justified its issuance change. Microsoft’s CAE overview describes a default one-hour lifetime; its developer guidance describes default Entra tokens expiring after 60–90 minutes. These are Entra defaults, not a universal OAuth requirement. A resource API can validate a JWT locally without consulting Entra on every request, so disabling an account does not inherently make every cached token unusable immediately. Refresh provides another policy evaluation opportunity, leaving an incident-response gap between evaluations.

CAE changes the enforcement path: a participating resource can reject an unexpired token and return a 401 response with a claims challenge. A capable client bypasses its token cache and returns to Entra for reevaluation. Both the client and resource API must support CAE for this interaction. CAE-aware sessions can receive tokens lasting up to 28 hours, and configurable token lifetime policies are not honored for those sessions. Longer validity therefore makes understanding event-driven enforcement essential; expiry alone no longer describes the control.

Evidence: Continuous access evaluation, Secure applications with Continuous Access Evaluation

Critical events require a measured response

Microsoft documents five critical events: account deletion or disablement, password change or reset, enabling multifactor authentication, administrator revocation of all refresh tokens, and high user risk detected by Entra ID Protection. Critical-event evaluation does not depend on Conditional Access policies and is available in any tenant. Enforcement aims to be near real time, but event propagation can produce latency of up to 15 minutes. That qualification matters operationally: CAE reduces the waiting period without promising that every protected request stops immediately after an administrator acts.

Recommended validation should distinguish the administrative action from its observed effect. In an authorized test, establish access, trigger a supported event, and record when the resource first rejects subsequent requests. Then check whether the client handles the claims challenge and whether Entra requires reauthentication or denies access. A password reset and account disablement should not be treated as interchangeable outcomes: the documented revocation flow can prompt reauthentication. Record the client, resource and platform tested rather than declaring the entire tenant successfully protected.

Evidence: Continuous access evaluation, Secure applications with Continuous Access Evaluation

Location enforcement has explicit exceptions

IP-based Conditional Access enforcement is documented as instant for supported combinations, but network topology matters. If a resource sees an untrusted address while Entra sees an allowed authentication egress address, Entra can issue a one-hour token that suspends resource-side IP checks until expiry; Entra continues its own checks. The documentation describes this exception for non-Microsoft 365 resources reached through Global Secure Access, where source IP restoration is unsupported. Recommended review: compare authentication and resource egress paths before treating a location shift as reliably blocked.

Client capability does not establish complete resource coverage. Microsoft lists Office web applications as unsupported for CAE against SharePoint Online and Exchange Online; their token lifetimes are reduced to one hour when a Conditional Access policy is set. OneDrive on Windows and Mac is unsupported against SharePoint Online, despite supporting claims challenges. Teams combinations are only partially supported, and its calls and chat services do not adhere to IP-based Conditional Access policies. Recommended inventories should therefore identify client-resource combinations, not merely application names.

Evidence: Continuous access evaluation

Review Application Proxy and the wider enforcement path

Application Proxy extends CAE to published on-premises applications without requiring those applications to be CAE-aware. Its documentation states that CAE is enabled by default, with options to disable individual applications or tenant-wide behavior. On receiving documented identity signals, Application Proxy prompts reauthentication; successful reauthentication restores access. However, enforcement is opportunistic unless Strict Enforcement is enabled and applied through Conditional Access. With a non-strict policy, reauthentication can fall back to a regular access token. Default enablement should not be mistaken for guaranteed continuous enforcement.

Use a review sequence: first inventory resources, clients and Application Proxy publications; next confirm claims-challenge handling and relevant policy settings. Then examine authentication and resource network paths, test critical-event and location enforcement, and document exceptions with an owner. For Application Proxy, explicitly review Strict Enforcement and fallback behavior rather than assuming parity with Microsoft 365 workloads. Keep the conclusion resource-specific. NIST’s zero trust guidance rejects implicit trust based solely on location or ownership; CAE is an enforcement mechanism, not proof that the whole architecture meets that principle.

Evidence: Continuous access evaluation, Zero Trust Architecture, Secure applications with Continuous Access Evaluation, Learn about Continuous Access Evaluation (CAE) for Application Proxy