Supercharging Zero Trust with Continuous Access Evaluation (CAE)

By Mirko Peters · 2026-08-11

Welcome back to the podcast and our ongoing deep dive into identity security architecture. If you have ever rolled out a brand-new, iron-clad Conditional Access pol…

Welcome back to the podcast and our ongoing deep dive into identity security architecture. If you have ever rolled out a brand-new, iron-clad Conditional Access policy in Microsoft Entra ID—only to watch a compromised user or an out-of-policy device continue merrily along their way for another eight hours—you are not alone. Identity administrators face this frustrating reality every single day. The secret truth behind how Microsoft 365 handles authentication is that your security boundaries are only as strong as your tokens. Policies do not enforce themselves; tokens do.

In this comprehensive blog post, we are going to expand on our recent podcast conversation by breaking down how Continuous Access Evaluation (CAE) changes the game. By moving away from static tokens and leaning into real-time, event-driven revocation, you can dramatically shrink your organization's exposure window. To catch up on the foundational mechanics of how these tokens flow under the hood, make sure you listen to our companion episode, Modern Authentication and Token Lifecycle in Microsoft 365.

TL;DR (The Big Idea)

• Policies don't enforce themselves—tokens do. Conditional Access is evaluated at token issue or refresh. Existing tokens keep yesterday's trust until you force reevaluation.
• MSAL silently swaps access tokens using refresh tokens, while CAE can invalidate them mid-flight when risk or context changes.
• To make changes "stick now," you must target the token lifecycle (sign-in frequency, revoke refresh tokens, CAE, session controls).

Plain-English Mental Model

To understand why Continuous Access Evaluation is so transformative, we first need to look at the actors involved in modern authentication. Think of your authentication architecture like an exclusive club:

• Access token (AT): A short-lived guest badge (typically lasting about 1 hour) that grants you entry to specific rooms.
• Refresh token (RT): A longer-lived wristband (lasting days or weeks) that allows you to request new guest badges from the front desk without going through security check-in every single time.
• MSAL: The internal runner that trades your refresh token for a new access token completely silently behind the scenes.
• Conditional Access (CA): The bouncer policy engine that checks your credentials and context strictly at the moment of AT/RT issuance (and during CAE events).
• CAE (Continuous Access Evaluation): A modern protocol upgrade that lets Azure AD actively pull access away in-session if risk spikes, a device becomes non-compliant, a user's location changes improperly, or the user account is disabled.

Why Your New Policy Didn't Hit Today

One of the most common helpdesk tickets following a security policy update is: "I just blocked legacy countries, but user X is still downloading files from an unmanaged network!" Why does this happen? The answer lies in token caching.

• Users already hold valid ATs; there is no reevaluation until that token naturally expires.
• RTs minted before your change still work seamlessly until:
  • The RT is presented again during a normal silent refresh, or
  • You actively revoke sessions and refresh tokens, or
  • CAE triggers a forced recheck.
• Mobile and desktop applications (like Microsoft Teams, Outlook, and OneDrive) aggressively cache and silently refresh tokens, which inadvertently extends the life of that "old policy" window.

Control Levers (in priority order)

1. Turn on CAE for supported resource providers (Exchange Online, SharePoint Online, Microsoft Graph, and Teams).
   • Effect: Policy and risk changes can invalidate tokens mid-session immediately.
2. Set Sign-in frequency (configured via per-app CA Session controls).
   • Examples: 8 to 12 hours for standard productivity apps; 1 to 4 hours for high-sensitivity administrative portals.
3. Require reauth on context change.
   • CA conditions to enforce: Sign-in risk ≥ Medium, User risk ≥ High, Device compliance required, or Hybrid/AADJ only.
4. Use Conditional Access App Control (Microsoft Defender for Cloud Apps session proxy) for unmanaged or risky sessions.
   • Enforce strict policies like no download/print/sync to reduce your blast radius while legacy tokens phase out.
5. Revoke tokens on demand during active rollouts or security incidents.
   • Targeted approach: Invalidate refresh tokens for specific affected users or groups.
   • Broad approach: Force sign-out and revoke tokens across the entire tenant for emergency posture adjustments.
6. Modern auth session settings.
   • Always prefer CA Session controls over legacy token lifetime policies, which have been deprecated for most modern workloads.

Ready-to-Use Policies (Minimal but Effective)

1. Block when User risk = High

• Assign: All users (excluding two break-glass accounts) + All cloud apps
• Conditions: User risk = High
• Grant: Block
• Session: Enable CAE (tenant setting)

1. Step-Up on Sign-in risk

• Assign: All users; Apps: Exchange, SharePoint, and Admin portals
• Conditions: Sign-in risk ≥ Medium
• Grant: Require MFA; Require compliant device (specifically for Admin portals)

1. Short sign-in frequency for administrators

• Assign: Directory roles = Privileged
• Session: Sign-in frequency = 1–4 hours, Persistent browser session = Never

1. Contain unmanaged devices

• Assign: All users; Apps: SharePoint, OneDrive, and Teams
• Device filter: Unmanaged
• Session: Use Conditional Access App Control (block download/print)

Operational Playbooks

Playbook A — "Make the new CA rule stick now"

• Scope: Group named "Sensitive-Apps-Users"
• Steps:
  1. Set and adjust Sign-in frequency for your target applications.
  2. Invalidate refresh tokens for the targeted security group.
  3. Post user communications explaining why they might see extra prompts today.
  4. Monitor SignInLogs for new CA challenges and keep an eye on helpdesk ticket volume.

Playbook B — "Risk spike/compromise containment"

• Trigger: High-severity identity alert (such as a risky user, impossible travel, or Defender for Identity lateral movement)
• Actions (automate via Azure Logic Apps):
  1. Confirm user compromised (sets User risk = High).
  2. Revoke refresh tokens + revoke sign-in sessions.
  3. Flip the user to an App Control policy for 72 hours.
  4. Require a Password reset & device health check.
  5. Notify the SOC and the user's manager via a Teams adaptive card.

Admin Commands & Endpoints (Copy/Paste)

• Microsoft Graph (Recommended):
  • Revoke sessions (user): POST /users/{id}/revokeSignInSessions
  • Invalidate all refresh tokens (user): POST /users/{id}/invalidateAllRefreshTokens
  • Confirm risky user compromised: POST /identityProtection/riskyUsers/{id}/confirmCompromised
  • Dismiss false positive: POST /identityProtection/riskyUsers/{id}/dismiss
• PowerShell (Entra / AzureAD)
  • (Legacy): Revoke-AzureADUserAllRefreshToken -ObjectId <UserId>
  • MSGraph PowerShell: Invoke-MgGraphRequest -Method POST -Uri "/users/$id/revokeSignInSessions"

Tip: Always prefer Microsoft Graph for future-proofing your automations. Build runbooks that accept a UPN list and loop these calls with built-in backoff logic.

Hunting & Monitoring (KQL)

Who kept using old tokens after a Conditional Access change?

Silent RT churn spikes (possible scripted refresh token abuse)

Metrics That Matter

• Time-to-enforce (policy change → first CA challenge) ↓
• Token revocation latency (action → user forced reauth) ↓
• Blocked risky sessions (per week) ↑ while false positives ↓
• Helpdesk auth tickets per 1k users remaining stable after changes
• CAE invalidations correlated with risk spikes (proving real-time in-session reaction)
• Privileged sign-in frequency adherence (ensuring no stale sessions persist) ↑

30/60/90 Execution Plan

Days 0–30 – Foundations

• Enable CAE and document your supported applications.
• Implement User risk block and Sign-in risk step-up CA policies.
• Set Sign-in frequency to 8–12h for productivity apps and 1–4h for admin tools.
• Pilot App Control for unmanaged endpoints.

Days 31–60 – Token Discipline

• Build a Graph runbook to bulk invalidate refresh tokens by security group.
• Wire Playbook B directly to Microsoft Defender alerts (risky user → automatic revocation and containment).
• Trim persistent sessions and disable legacy token lifetime policies.

Days 61–90 – Zero Trust Tuning

• Expand CAE coverage and verify that mid-session prompts work smoothly as intended.
• Add PIM guardrails (blocking elevation if user or sign-in risk is ≥ Low/Medium).
• Stand up an Identity Session Health workbook using the metrics outlined above.
• Run a purple-team drill to validate your revocation speed and CA enforcement mechanisms.

Common Pitfalls (and Safer Defaults)

• Relying on policy only → Always manage your tokens (CAE + revocation + sign-in frequency).
• One global sign-in frequency → Split your policies between admin workloads and standard worker apps.
• Tenant-wide revokes at noon → Stage your rollouts by group and time zone to avoid massive operational outages.
• Ignoring mobile background refresh → Expect extra prompts and pre-communicate changes to your mobile user base.
• No break-glass exclusion → Always maintain two monitored, thoroughly tested break-glass accounts.

CAB One-Liner (Exec-Friendly)

We tied policy directly to the token lifecycle. With Continuous Access Evaluation and targeted revocation, risk or policy changes now take effect immediately, shrinking exposure windows without grinding daily work to a halt.