Sign-in frequency is a blunt instrument — CAE is the scalpel

Most people reach for sign-in frequency when they want tighter session control, crank it down, and assume they've solved token risk. They haven't — because sign-in frequency only governs when a user is periodically forced to re-authenticate, not what happens the instant something goes wrong mid-session. The two mechanisms below answer different questions, and you need both.

01Why sign-in frequency alone is weak

It's a timer, not a trigger.

Sign-in frequency is a Conditional Access session control that forces re-authentication after a set interval (hours or days). The problem is baked into how OAuth tokens work: an access token is typically valid for about an hour, and behind it a long-lived refresh token silently mints new access tokens. So if you disable a user, reset their password, or detect that their session is compromised, their existing access token keeps working until it expires — and sign-in frequency does nothing to pull it back early.

The gap, concretely

Set sign-in frequency to 8 hours and you've decided how often to ask again. You have not decided how fast you can cut someone off. An attacker who stole a token at 09:00 keeps access until roughly 10:00 (token expiry) even if you disabled the account at 09:05 — a blunt timer can't react to the event that just happened.

02What CAE actually does

Near-real-time revocation, driven by events instead of clocks.

Continuous Access Evaluation (CAE) establishes a channel between Entra ID and CAE-capable resource providers (Exchange Online, SharePoint, Teams, Microsoft Graph). Instead of trusting an access token blindly until expiry, the resource provider listens for critical security events from Entra and rejects the token the moment one fires — without waiting for the clock. The events that trigger near-instant revocation:

Critical event	What CAE does
User account disabled or deleted	Existing tokens rejected within minutes
Password changed / reset	Sessions invalidated near-instantly
Admin explicitly revokes tokens	All sessions dropped
Elevated user risk detected (Entra ID Protection)	Token challenged / revoked
Location change (with strict location enforcement)	Token re-evaluated against CA network conditions

The mechanism: a CAE-capable client presents its token to, say, Exchange; if a critical event has occurred, the resource returns a claims challenge (a 401 with a specific claim) instead of serving data, forcing the client back to Entra to obtain a fresh token — which now fails because the account is disabled. That round-trip is what collapses the revocation window from "up to an hour" to "a few minutes."

03Configure them together

Sign-in frequency sets the baseline; CAE handles the emergencies.

They're complementary, not either/or. In a Conditional Access policy, under Session:

# Conditional Access → Session controls
Sign-in frequency:
  - Periodic:    e.g. every 8 hours / 1 day  (the routine reauth baseline)
  - Every time:  for high-risk actions (e.g. accessing the security portal,
                 role activation) — forces fresh auth each attempt
Continuous access evaluation:
  - Enabled (default in most tenants) — leave ON
  - Strict location enforcement: optional — CAE re-checks IP against
    CA named-locations mid-session (use with care behind proxies/VPN)

Strict location enforcement has a footgun

Enabling strict location enforcement means CAE re-evaluates the client's IP against your named locations mid-session. Behind egress proxies, VPNs, or Secure Web Gateways the perceived IP can shift legitimately, causing unexpected re-auth loops. Roll it out to a pilot group and confirm your egress IPs are in the trusted named-locations list before applying broadly.

04How to read enforcement

Confirm the token was actually cut, not just re-timed.

After disabling a test account, watch the sign-in logs: a CAE-driven revocation appears as the resource rejecting the token and the client being sent back for re-auth, distinct from a routine sign-in-frequency prompt. The practical test is timing — with CAE working, a disabled user loses access to Exchange/SharePoint/Teams within minutes, not at the next frequency interval. If access persists for the full token lifetime, the client or resource isn't CAE-capable, and you're back to relying on the blunt timer.

The takeaway

Sign-in frequency decides how often you ask; CAE decides how fast you can revoke. Alone, sign-in frequency leaves stolen or orphaned tokens valid until expiry. Leave CAE enabled, pair it with a sensible sign-in-frequency baseline (and "every time" for high-risk actions), and a disabled account loses access in minutes instead of hours. Validate by disabling a test user and timing the cut-off.