The 28-Hour Revocation Gap: Why Entra ID Continuous Access Evaluation (CAE) Fails Against Session Token Theft

In modern enterprise identity architectures, Continuous Access Evaluation (CAE) is frequently regarded as the definitive solution to session hijacking and token theft. By transitioning from static, time-bound OAuth 2.0 access tokens to an event-driven trust model governed by OpenID Shared Signals and Events (SSE) and the Continuous Access Evaluation Profile (CAEP), Microsoft Entra ID promises near-instantaneous session revocation. When an account is disabled, a password changed, or high user risk detected, Entra ID broadcasts real-time revocation events to participating resource providers, theoretically neutralizing stolen access tokens immediately.

Yet, red teams and advanced threat actors operating Adversary-in-the-Middle (AiTM) phishing infrastructure and token-stealing infostealers (such as Lumma, Vidar, and Stealc) consistently demonstrate that CAE does not prevent post-compromise access. Architectural trade-offs inherent in Microsoft's CAE implementation introduce a dangerous paradox: access tokens issued under CAE have their valid lifetimes extended from the standard 60-90 minutes up to 28 hours. Coupled with a critical coverage gap where only approximately 4.5% of Microsoft enterprise services actively support CAE, this mechanism frequently grants attackers an expanded operational window rather than a tightened perimeter.

Engineering Architecture: The 28-Hour Window

Under the classic OAuth 2.0 framework in Entra ID, access tokens are short-lived JSON Web Tokens (JWTs) with an expiry (exp) timestamp set between 60 and 90 minutes. Resource providers validate tokens locally using cached public signing keys. The IdP cannot revoke a standalone token before expiration without high-throughput centralized checks that degrade latency.

CAE decouples token expiration from authorization validity via real-time telemetry backchannels. When a CAE-capable client authenticates, it embeds the xms_cc capability claim in the request:

{
  "access_token": {
    "xms_cc": {
      "values": ["cp1"]
    }
  }
}

The cp1 flag signals that the client can handle HTTP 401 claims challenges. Entra ID modifies token issuance:

1. Extended Token Lifetime: Token validity (exp minus nbf) expands to a sliding window of 20 to 28 hours (standardized at 86,400s with randomized drift).
2. Event Subscription Binding: The resource provider agrees to verify user validity against continuous event streams published by Entra ID via webhook-based security event tokens.

If an attacker extracts this 28-hour access token, the IdP issues no revocation event unless an explicit critical event occurs. If the attacker operates within the victim's existing security context, the 28-hour token remains completely valid.

The 4.5% Coverage Gap: Asymmetric Adoption

The primary operational failure of CAE stems from the disparity between marketing claims of "continuous evaluation" and actual API-level implementation. While Microsoft supports CAE across Exchange Online, SharePoint Online, Microsoft Teams, and select Microsoft Graph endpoints, the enterprise identity surface is drastically broader.

Across thousands of enterprise application service principals in a typical Entra ID tenant, approximately 4.5% of total accessible resource endpoints actively enforce CAE claims challenges and subscribe to SSE revocation webhooks. The remaining ~95.5% operate entirely on legacy OAuth 2.0 token validation.

This asymmetry enables Token Scope Degradation and Pivoting. When an AiTM proxy intercepts an authentication session, it captures both the session cookies (ESTSAUTH, ESTSAUTHPERSISTENT) and negotiated tokens. An attacker extracts a 28-hour credential for Exchange or SharePoint. Conversely, if the attacker uses the captured Primary Refresh Token (PRT) or session cookie to request tokens for non-CAE workloads—such as Azure Resource Manager (https://management.azure.com/)—Entra ID issues standard tokens. The attacker leverages the long-lived CAE session to persist on communication channels while pivoting through non-CAE administrative APIs without triggering continuous revocation checks.

Anatomy of the Revocation Gap

Why does an explicitly revoked user session still function following an AiTM interception or malware compromise? The answer lies in the specific conditions Entra ID classifies as "Critical Events."

Figure 1: Architectural and benchmark overview for The 28-Hour Revocation Gap: Why Entra ID Continuous Access Evaluation (CAE) Fails Against Session Token Theft.

CAE triggers only upon five distinct identity transitions:

• User Account is Deleted or Disabled
• Password for User is Changed or Reset
• MFA is enabled for the User
• Administrator explicitly revokes all Refresh Tokens
• Elevated User Risk is detected by Entra ID Identity Protection

Crucially, network location changes without Strict Location Enforcement, device compliance drift, and session anomaly detection without an associated risk score escalation do not trigger revocation.

The Network Location Fallacy

In over 90% of enterprise deployments, Conditional Access policies enforce trusted named locations (e.g., corporate egress IPs). When an infostealer extracts a CAE access token from an employee's machine and transmits it to an attacker in a different country, Exchange Online accepts the token without re-evaluating the IP address.

Unless the tenant administrator has explicitly enabled Strict Location Enforcement inside Conditional Access, resource providers evaluate location policies only during initial token issuance. Because an IP address change is categorized as an environmental condition rather than a critical identity event, no revocation event is generated by Entra ID, and no claims challenge is issued by the resource provider. The attacker retains unrestricted access to emails, files, and chat logs for up to 28 hours.

The Strict Location Catch-22

Enabling Strict Location Enforcement introduces operational friction. When mobile users transition between cellular and Wi-Fi networks, the resulting IP change triggers an HTTP 401 claims challenge. Rich clients (Outlook, Teams) often handle mid-session 401s poorly, causing authentication loops and sync failures. Consequently, security teams routinely leave Strict Location disabled, preserving the 28-hour replay window.

Protocol Breakdown: The Missing Claims Challenge

To observe the failure mechanism at the wire level, consider the HTTP traffic flow during a session replay attack. The attacker captures a CAE-enabled token originally issued to corporate IP 198.51.100.25 and replays it from 203.0.113.88:

GET /api/v2.0/me/messages HTTP/1.1
Host: outlook.office365.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...

Decoded JWT claims payload:

{
  "aud": "https://outlook.office365.com",
  "iss": "https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/",
  "iat": 1758240000,
  "nbf": 1758240000,
  "exp": 1758340800,
  "xms_cc": ["cp1"],
  "ipaddr": "198.51.100.25",
  "scp": "Mail.Read Mail.ReadWrite",
  "oid": "e3a89012-4567-489a-bcde-f0123456789a",
  "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47"
}

The difference between exp (1758340800) and iat (1758240000) is 100,800 seconds (28 hours). Exchange Online executes its validation pipeline:

1. Validates RSA-256 signature against Entra ID keys: Valid.
2. Checks current epoch against nbf and exp: Valid (within 28 hours).
3. Queries local revocation table for oid / tid: No revocation event found.
4. Strict Location Enforcement check: Disabled.

The server responds with HTTP 200 OK. The expected HTTP 401 Unauthorized with WWW-Authenticate: Bearer realm="", error="insufficient_claims" is never sent, granting immediate mailbox access.

Detection Engineering: Threat Hunting with KQL

Detecting stolen CAE token replay requires identifying discrepancies between the original token issuance context and subsequent resource utilization telemetry.

Identifying Replayed CAE Tokens via IP Drift

The following KQL query correlates non-interactive sign-ins with resource access anomalies, flagging CAE tokens utilized from an IP address divergent from the initial authentication event within the 28-hour window:

let TimeRange = 48h;
let CaeTokensIssued = SigninLogs
| where TimeGenerated >= ago(TimeRange)
| where ResultType == 0
| extend ParsedAuthDetails = todynamic(AuthenticationProcessingDetails)
| mv-expand ParsedAuthDetails
| where ParsedAuthDetails.key == "IsCAEToken" and ParsedAuthDetails.value == "True"
| project
    TokenIssueTime = TimeGenerated,
    UserPrincipalName,
    OriginalIP = IPAddress,
    OriginalLocation = Location,
    SessionId = CorrelationId;
let ResourceAccessEvents = AADNonInteractiveUserSignInLogs
| where TimeGenerated >= ago(TimeRange)
| where ResultType == 0
| extend ParsedAuthDetails = todynamic(AuthenticationProcessingDetails)
| mv-expand ParsedAuthDetails
| where ParsedAuthDetails.key == "IsCAEToken" and ParsedAuthDetails.value == "True"
| project
    ResourceAccessTime = TimeGenerated,
    UserPrincipalName,
    AccessIP = IPAddress,
    AccessLocation = Location,
    ResourceDisplayName,
    SessionId = CorrelationId;
CaeTokensIssued
| join kind=inner (ResourceAccessEvents) on UserPrincipalName
| where ResourceAccessTime > TokenIssueTime and ResourceAccessTime <= TokenIssueTime + 28h
| where OriginalIP != AccessIP
| project
    UserPrincipalName,
    TokenIssueTime,
    ResourceAccessTime,
    OriginalIP,
    AccessIP,
    OriginalLocation,
    AccessLocation,
    ResourceDisplayName
| sort by ResourceAccessTime desc

Hunting for Token Scope Pivoting

Detect attackers leveraging a valid CAE session to request tokens for non-CAE resource endpoints:

SigninLogs
| where TimeGenerated >= ago(24h) and ResultType == 0 and ClientAppUsed == "Browser"
| project InitialLoginTime = TimeGenerated, UserPrincipalName, InitialIP = IPAddress, UserAgent
| join kind=inner (
    AADNonInteractiveUserSignInLogs
    | where TimeGenerated >= ago(24h) and ResultType == 0
    | where AppDisplayName in ("Azure Resource Manager", "Azure DevOps")
    | project PivotedTime = TimeGenerated, UserPrincipalName, TargetResource = AppDisplayName, PivotIP = IPAddress, PivotUserAgent = UserAgent
) on UserPrincipalName
| where PivotedTime between (InitialLoginTime .. (InitialLoginTime + 2h))
| where InitialIP != PivotIP or UserAgent != PivotUserAgent
| project UserPrincipalName, InitialLoginTime, PivotedTime, InitialIP, PivotIP, TargetResource

Hardening Blueprint & Remediation Strategies

Relying on CAE as a standalone defense against session token theft is an architectural anti-pattern. Enterprise security architects must deploy defense-in-depth controls to eliminate token replayability.

1. Enforce Token Protection (Proof-of-Possession / DPoP)

Token Protection for Conditional Access (supported for Exchange and SharePoint on Entra-joined Windows/macOS devices) cryptographically binds tokens to the physical device's TPM 2.0 or Secure Enclave:

• The client generates an asymmetric key pair inside hardware.
• Entra ID embeds a cryptographic thumbprint (cnf claim) into the JWT.
• For subsequent requests, the client signs the payload with its private key.
• A stolen 28-hour CAE token cannot be replayed without the physical hardware key.

2. Implement Global Secure Access (GSA)

To overcome the routing failures of Strict Location Enforcement, organizations should deploy Microsoft Entra Internet Access (part of Global Secure Access):

• Client machines route traffic through a kernel-level client driver directly to Microsoft's edge.
• GSA applies Source IP Restoration, preserving original client egress identity regardless of downstream proxy chaining.
• Conditional Access mandates that CAE-enabled tokens are valid only when originating from the verified GSA tenant-bound tunnel.

3. Immediate Revocation Orchestration via Graph API

When incident responders suspect session compromise, calling Revoke-AzureADUserAllRefreshToken is insufficient. Responders must invoke the Microsoft Graph revokeSignInSessions endpoint and explicitly dispatch a user risk elevation event:

POST /v1.0/users/{user-id}/revokeSignInSessions HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer <Admin-Token>
Content-Type: application/json

{}

Simultaneously, confirm the user as compromised to force Entra ID Identity Protection to broadcast an immediate SSE critical revocation token to all subscribing CAE resource endpoints:

POST /v1.0/identityProtection/riskyUsers/confirmCompromised HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer <Admin-Token>
Content-Type: application/json

{
  "userIds": ["{user-id}"]
}

By combining hardware token binding, SSE orchestration, and source IP restoration, security engineering teams can systematically eliminate the 28-hour revocation gap.