Continuous Access Evaluation

Your fired employee is still reading email

09:00 Tuesday. The administrator disables the account at 09:01. In the pre-CAE model, or against a non-CAE-aware path, the ex-employee's open Outlook for the Web tab refreshes at 09:23, and pulls down new mail. This is not a bug. This is RFC 6749 working exactly as designed. Before Microsoft Entra shipped a production answer after a decade of standards and Zero Trust pressure, the access token that user held at 09:00 stayed cryptographically valid until 10:00 at the latest, and there was nothing Conditional Access could do about it [1227].

The window has a name now. It did not, for most of cloud identity's history. Microsoft's own documentation calls it "the lag between when conditions change for a user, and when policy changes are enforced" [124]. Between sign-in (Conditional Access territory) and the next token refresh (refresh-token territory) sits a stretch of time in which Conditional Access decisions have no enforcement surface. That stretch ranged from 60 minutes to 24 hours, depending on tenant configuration. For every OAuth 2.0 deployment from 2012 onward, this was the security debt the industry carried.

This chapter explains the engineering pattern that lets a Microsoft 365 tenant do two things that look contradictory at the same time: extend access-token lifetime from 1 hour to up to 28 hours, and revoke a disabled user's session in under 15 minutes [124]. The reconciling idea is a near-real-time push channel between the identity provider (Entra) and a small set of cooperating resource providers. When you can revoke a token in minutes rather than waiting for it to expire, expiry stops doing the security work, and the token can live as long as the user actually needs it.

The trade has a price. The 15-minute critical-event service-level objective is plausibly the price the channel pays for fanning out events across hyperscale Microsoft 365 infrastructure. Sub-second revocation is possible in smaller deployments, but at Exchange-Online volume Microsoft documents the operating point rather than the full cost model behind it.

For now: the OAuth 2.0 designers knew about this gap when they wrote RFC 6749 in 2012. They chose it on purpose. To see why, and to see why the obvious patches all failed, we have to walk back to the moment the trade was made.

The static-expiry compromise

In October 2012, Dick Hardt of Microsoft published RFC 6749: The OAuth 2.0 Authorization Framework: as the editor of record for an IETF working group that had spent about three and a half years arguing about it [1227]. Section 1.4 defines access tokens as carrying "specific scopes and durations of access," but the specification never characterizes them as short-lived. That an access token should be short enough to limit exposure was always convention, not a normative requirement: the closest the RFC comes is Section 1.5's aside that an access token "may have a shorter lifetime and fewer permissions" than the refresh token that renews it. Nothing in the protocol enforces a short lifetime. Nothing in the protocol provides revocation. Nothing in the protocol stops a server from issuing 24-hour bearer tokens that, once minted, stay cryptographically valid until they expire on their own.

This was a deliberate trade. To see why it was rational, remember what came before.

Web Access Management: the model OAuth replaced

Web Access Management dominated enterprise identity from the late 1990s into the early 2010s. Every protected HTTP request to a WAM-fronted application made a synchronous round-trip to a Policy Decision Point. The PDP held authoritative session and policy state. Revoke a user? The next request failed, immediately, because the PDP said no. No token-lifetime window. No gap between policy change and enforcement.

WAM was correct. WAM was also unworkable for the web that was coming. It did not scale: every request was a network hop. It did not federate: cross-organization SaaS meant the PDP could not live inside any one company's network. And it required every protected resource to participate in a single trust domain. By the time enterprises were running cross-organization SaaS at scale, the WAM model had run out of road.

The OAuth 2.0 authors made the opposite trade. Replace the chatty PDP round-trip with a self-contained signed bearer token: a JWT the resource server validates locally. Validation becomes O(1) cryptographic verification with no round-trip. Throughput scales horizontally. Federation works, because the JWT carries its own attestation of the issuer. Revocation becomes...approximated. By expiry. The token is valid until it isn't, and you trust that the lifetime is short enough.

For a 2012 web of forum logins and consumer mashups, "short enough" was a defensible answer. For a 2020 enterprise running compliance-bound SaaS across thousands of employees, it was not.

The Zero Trust pressure

The intellectual pressure that turned that gap into a procurement problem belongs to Zero Trust (Chapter 26): BeyondCorp's December 2014 argument that a session is a time-varying authorization rather than a one-shot decision at sign-in [1231], codified in August 2020 as NIST Special Publication 800-207, Zero Trust Architecture [1116]. One sentence in SP 800-207 made the engineering investment commercially rational: "Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established." A federal mandate for continuous re-evaluation pushed every cloud vendor with U.S. government contracts to find an implementation. CAE is the part of that story that lives after the token is issued; the philosophy and its thirteen-month standardization belong to Chapter 26.

A name for the problem

The third moment named the gap. On February 21, 2019, Atul Tulshibagwale, then an engineer at Google, published Re-thinking federated identity with the Continuous Access Evaluation Protocol on the Google Cloud blog [1232]. The post introduced a term (CAEP) and a framing: publish-and-subscribe between identity providers and resource providers, as a third option between WAM's per-request chattiness and OAuth's fire-and-forget expiry. We return to Tulshibagwale's actual proposal below. For now what matters: 2019 was the year the industry got a vocabulary for a problem it had been carrying for seven years.

The timeline is the important point, not the diagram. OAuth 2.0 standardized the static-expiry bargain in October 2012. OAuth token revocation followed in August 2013, introspection in October 2015, the Security Event Token envelope in July 2018, and SET push/poll delivery in November 2020. In parallel, BeyondCorp appeared in December 2014 and NIST SP 800-207 made Zero Trust federal guidance in August 2020. Atul Tulshibagwale named the Continuous Access Evaluation Protocol idea in February 2019; the OpenID Shared Signals working group formed that year; and SSF 1.0, CAEP 1.0, and RISC 1.0 reached Final Specification status in September 2025. Microsoft Entra CAE sits inside that arc: limited preview in April 2020, expanded public preview in October 2020, and general availability in January 2022.

The OAuth 2.0 designers traded revocation latency for throughput on purpose [1227]. Once that gap proved unacceptable, three obvious patches were tried. None of them worked. To see why none of them worked is to understand the negative space CAE was designed to fill.

Three patches, three failures

Between 2013 and the late 2010s, the OAuth community published three patches for RFC 6749's revocation gap. Each was rationally adopted; each was rationally abandoned at hyperscale. This section is the genealogy of those failures, because what each one got wrong defines the shape of the design that finally worked.

Patch 1: RFC 7009: the /revoke endpoint (August 2013)

In August 2013, Torsten Lodderstedt of Deutsche Telekom, Stefanie Dronia, and Marius Scurtescu of Google published RFC 7009, OAuth 2.0 Token Revocation [1234]. The contribution was a standardized HTTP endpoint, /revoke, that a client could POST a token to in order to invalidate it. The mental model is the logout button: when a user signs out, the client tells the authorization server "I'm done with this token, please retire it."

The failure mode is in the threat model. RFC 7009 is client-initiated. The token holder asks for revocation. But the scenario that motivates CAE is precisely the one where the token holder is uncooperative. A fired employee will not POST their access token to /revoke on the way out the door. An attacker who has stolen a token will certainly not. The administrator on the other side cannot use the endpoint either, because they do not possess the bearer token.

Worse, RFC 7009's Implementation Note (Section 3) is candid about self-contained tokens: the only standardized recourse is "some (currently non-standardized) backend interaction between the authorization server and the resource server" when immediate revocation is desired [1234]. Read that carefully. The spec admits there is no spec. The JWT in flight at the resource server is cryptographically valid until it expires. The authorization server can mark it revoked in a local database, but the resource server never asks. It validates the signature locally. The revocation event never crosses the wire.

RFC 7009 works for opaque tokens with a token-introspection back-channel. It does not, by itself, solve revocation for self-contained JWT bearers: which by the mid-2010s were the dominant pattern in the cloud.

Patch 2: RFC 7662: the /introspect endpoint (October 2015)

Two years later, in October 2015, Justin Richer published RFC 7662, OAuth 2.0 Token Introspection [1235]. The mechanism: on every request, the resource server calls a /introspect endpoint on the authorization server with the bearer token. The AS replies with the token's current state. If the token has been revoked, /introspect returns active: false, and the resource server denies the request.

This is correct. It also reintroduces the WAM bottleneck that OAuth was designed to escape.

For an AS serving billions of requests per day (Microsoft Entra ID as one example, Google's IdP as another) making /introspect the per-request critical path turns the authorization server into a synchronous dependency on every API call against every resource server in the estate. Latency adds up. Availability becomes shared. If the AS has a bad five minutes, every resource server has a bad five minutes simultaneously. The architecture OAuth bought with self-contained tokens (resource server scales independently of AS) gets traded back for exactly the WAM property that motivated OAuth's existence.

Patch 3: Make the token life so short revocation does not matter

The third patch was the obvious one. If you cannot revoke a token mid-life, make its life short. Issue access tokens with a minutes-long lifetime, the way early Microsoft experiments did. The revocation window collapses. Problem solved.

Microsoft tried it. The retrospective is unusually candid. On April 21, 2020, Alex Weinert, then Director of Identity Security at Microsoft, published Moving toward real time policy and security enforcement on the Azure Active Directory Identity Blog [1236]. (The original lives at post ID 1276933 on Microsoft's tech community; the full body is preserved in Microsoft's Japanese translation on the jpazureid GitHub mirror [1237].) The post names the failure mode in one sentence:

Two things break. First, user experience and reliability. Every short-lifetime boundary forces every active client to round-trip the IdP for a fresh token. For Outlook, Teams, Word Online, OneDrive, and every other client an enterprise user has open at once, that is a wave of token requests per user per cycle. Multiplied by Microsoft 365 active users, the load profile creates real outages. Network blips that would otherwise be invisible surface as failed refreshes, with user-visible re-authentication prompts. Second, it does not eliminate the risk. A minutes-long window is still a window. A fired employee can read or exfiltrate a great deal of email in that window. You have paid the full user-experience cost and still left a non-trivial breach surface.

This was the third failure. The negative space across the three patches defines the shape any real solution has to take: it must be server-initiated (not RFC 7009), it must be push-based rather than per-request poll (not RFC 7662), and it must separate revocation from expiry so the IdP does not pay for every revocation with a refresh-load spike (not the short-lifetime patch). The three failures exhaust the surface of the obvious fix.

If the patches all fail, the next move has to be architectural. The first published statement of that architecture was Atul Tulshibagwale's February 2019 Google blog post, and the move he proposed is the one Microsoft would ship three years later.

Four generations of session enforcement

Walk forward through the genealogy of session enforcement and the subscription/claims-challenge breakthrough stops looking like a stroke of genius and starts looking like the path that survived the scale and federation constraints. Four generations, each killed by a documented limit of the previous one.

Generation 0: WAM (pre-2012)

Per-request synchronous round-trip to a Policy Decision Point. Instant revocation; chatty bottleneck; no federation. Killed by cloud-scale request rates and the rise of cross-organization SaaS, where the protected resource and the policy authority no longer lived in the same trust domain. WAM remains valuable in single-tenant enterprise contexts, but for the public-cloud API mesh it cannot scale.

Generation 1: Static-expiry JWT (2012-2020)

Self-contained signed bearer tokens validated locally at the resource server. Revocation approximated by expiry per RFC 6749 [1227]. Throughput scales; federation works; revocation is acceptable when the lifetime is short and the threat model is benign. Killed by (a) the fired-employee window, (b) the three failed patches above, and (c) the philosophical pressure from Zero Trust to treat sessions as continuously re-evaluated.

Generation 2: Microsoft CAE (limited preview April 2020, GA January 10, 2022)

The first production solution. Limited preview launched in April 2020 with Alex Weinert's Moving toward real time policy and security enforcement announcement [1236]. Expanded public preview October 2020 [1238]. General Availability January 10, 2022, announced by Alex Simons, Corporate VP for Program Management in the Microsoft Identity Division [1239].

The architecture is a private push-subscription channel between Entra and a small set of Microsoft 365 resource providers, with a wire-level handshake (the claims challenge) for telling the client to re-acquire a token reflecting new state. Access-token lifetime extends from the default 1 hour to up to 28 hours specifically for CAE-aware sessions [124]. We will unpack the mechanism next.

The Gen-2 limitation that motivated Gen 3: the wire format is Microsoft-internal. A SaaS vendor that wants the same revocation properties for its own resource provider cannot use Microsoft's CAE channel. The protocol does not federate.

Generation 3: OpenID SSF 1.0 + CAEP 1.0 + RISC 1.0 (final specifications, September 2, 2025)

The OpenID Foundation generalized the Microsoft pattern into a vendor-neutral specification. On September 2, 2025, three Final Specifications were approved: the Shared Signals Framework 1.0 (SSF), the Continuous Access Evaluation Profile 1.0 (CAEP), and the Risk and Incident Sharing and Coordination 1.0 (RISC) [1229].

The wire envelope is IETF RFC 8417's Security Event Token (SET), published in July 2018 by Phil Hunt (Oracle), Michael Jones (Microsoft), William Denniss (Google), and Morteza Ansari (Cisco) [1240]. A SET is a signed JWT carrying a single security event. The transport layer is RFC 8935 push (POST over TLS from transmitter to receiver) and RFC 8936 poll (recipient-initiated retrieval), both published November 2020 by Annabelle Backman and collaborators [1241]. SSF defines the subscription model: streams, subjects, transmitter and receiver metadata endpoints. CAEP and RISC define the vocabulary of events that can ride that envelope.

Public documentation draws a bright line:

Read the OpenID stack from the bottom up. Layer 1 is RFC 8417, the signed Security Event Token envelope. Layer 2 is transport: RFC 8935 for HTTP push and RFC 8936 for polling. Layer 3 is SSF 1.0, which defines streams, subjects, transmitters, receivers, metadata, verification events, and stream-control endpoints. Layer 4 is vocabulary: CAEP 1.0 for session-level continuous access events and RISC 1.0 for account-risk and incident-sharing events.

The generation chain has a documented engineering reason for each transition. The comparison matrix below pulls the essentials together.

The generation chain is simple in prose: WAM gave instant per-request authorization but failed at cloud scale and federation. Static-expiry JWTs gave local validation and federation but created the fired-employee window. Microsoft CAE preserved local validation while adding push revocation and claims challenges, but only inside Microsoft's first-party estate. OpenID SSF and CAEP generalize the same pattern into a vendor-neutral signal framework.

Knowing the lineage is not knowing the trick. What is the actual mechanism CAE deploys: the thing that turns this standards-history arc into a feature that ships and makes 28-hour tokens defensible? It has three parts, and once you see them together, you understand why long tokens are safe.

Subscription, claims challenge, extended lifetime

Three innovations, none new in isolation, all unprecedented in combination.

Atul Tulshibagwale's 2019 framing names the move: "Our vision for continuous access evaluation is based on a publish-and-subscribe ('pub-sub') approach... It's complementary to federated or cert-based authentication... It's not as chatty as WAM... It doesn't impact latency for user access" [1232]. Pub-sub is the third option between WAM's per-request chattiness and RFC 6749's fire-and-forget. Subscription is the channel; claims challenge is the wire-level handshake; extended lifetime is the user-experience prize.

Part 1: Subscription

Microsoft's CAE concept page describes the architecture in one sentence that rewards close reading:

The word conversation is the architecture. The relying party (a CAE-aware Microsoft 365 workload such as Exchange Online) subscribes to a finite, documented set of critical events for the subjects it cares about. Entra pushes events to the RP as state changes. State is cached at the RP. On the hot path (the per-request data plane), the RP does an O(1) JWT signature verification plus an O(1) hash-table lookup of cached revocation state. No back-channel round-trip on the hot path. The 28-hour token costs no more to validate than the 1-hour token it replaced [124].

This is the move that defeats RFC 7662. The state lives at the RP, not at the AS. The control-plane cost scales with the rate of events, not the rate of requests. Push, not poll.

Part 2: The claims challenge

When state at the RP changes (because a push event has arrived saying "this user's password has been reset"), the RP cannot reach into a request that has already been accepted and is being served. CAE is in-band with the next request, not the current one. The next time the client presents the stale token, the RP rejects it with HTTP 401 and a specific header:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_claims",
                  claims="eyJhY2Nlc3NfdG9rZW4iOnsiYWNyc..."

The claims parameter is a base64url-encoded JSON object that tells the client what to re-acquire from the IdP. The Microsoft Authentication Library (MSAL) on the client decodes the challenge transparently and requests a new access token from Entra with the indicated claims. Entra either issues a fresh CAE-aware token (if authorization still holds) or rejects, forcing interactive re-authentication. The client retries the original API call with the new token [1228].

This is the move that defeats RFC 7009. Revocation is initiated by the resource provider's view of the IdP's state, not by the token holder. A fired employee's client cannot opt out of the claims challenge; the RP will not serve any further request until a fresh token arrives that reflects the post-revocation state.

The nbf (not-before) claim challenge is the most common shape: the RP is telling the client "give me a token issued after this moment." The client requests one. Entra checks current state. Did the user get disabled? did the password get reset? did the risk score elevate?, and either issues or denies. The wire format is simple enough to inspect in a browser tab, which is part of why the architecture has been able to standardize: there is no magic to reverse-engineer.

Part 3: Extended lifetime, the prize

The first two parts buy you the third. Once revocation is push-based and the claims challenge gives the RP a way to evict stale tokens on the next applicable request after it has received and applied a control-plane event, the expiry timer stops carrying the security weight. Tokens can live longer because the expiry is no longer the only revocation mechanism.

Microsoft documents the upper bound as "up to 28 hours" for CAE-aware sessions [124]. The default for non-CAE-capable clients remains 1 hour. This is the move that defeats the short-lifetime patch: the IdP load profile collapses because tokens refresh once a day, not on a per-minute cycle, and the revocation window is dramatically smaller. Not because expiry shrank, but because the channel now does the revocation work expiry used to do.

The full round trip

The three parts interlock. The complete flow, from a state change at Entra to a re-validated request, runs end-to-end through every layer this chapter has named.

The end-to-end flow is a six-step conversation. First, an administrator disables a user account in Microsoft Entra. Second, Entra pushes a critical-event notification to a participating resource provider such as Exchange Online. Third, the resource provider updates cached revocation state for the subject and tenant. Fourth, the client presents the old bearer token on the next request; the resource provider validates the JWT signature, then checks cached CAE state and sees that the token is stale. Fifth, the resource provider returns 401 Unauthorized with WWW-Authenticate: Bearer error="insufficient_claims" and a claims parameter. Sixth, MSAL requests a fresh token from Entra with those claims; because the account is disabled, Entra rejects the request and the session terminates rather than silently continuing.

Three moves, one design. Remove any one and the system collapses. Subscription without a claims challenge gives you push events the RP cannot act on at the wire. Claims challenge without subscription gives you a 401 mechanism with no information to decide when to fire it. Extended lifetime without either gives you Generation 1's fired-employee window. The 28-hour token is not the cost of CAE; it is what CAE purchases.

This is the design. What does it actually do in production today, and where does it stop?

CAE as deployed in Microsoft Entra (2026)

Concrete answers to concrete questions. Which events trigger CAE? Who participates? What is the actual SLA? How long do tokens actually live? No marketing language; only what Microsoft Learn currently documents.

Critical event evaluation events

Microsoft Learn lists exactly five events that drive critical event evaluation at the IdP-to-RP boundary [124]:

1. A user account is deleted or disabled.
2. A password for a user is changed or reset.
3. Multi-factor authentication is enabled for the user.
4. An administrator explicitly revokes all refresh tokens for a user.
5. High user risk is detected by Microsoft Entra ID Protection.

These five events propagate from Entra to the participating CAE-aware resource providers via the push channel. Microsoft's published service-level objective is "up to 15 minutes" for critical-event propagation [124]. That is not the same as "instant." The phrase to avoid is "CAE delivers instant revocation"; the accurate phrase is "CAE delivers near-real-time revocation, typically within 15 minutes for critical events."

A separate scenario (Conditional Access policy evaluation) covers network and IP-location changes. Here the SLA is different: IP-location enforcement is instant per Microsoft's published documentation [124]. The difference is mechanical. IP location is a property the RP sees directly on every request (the source IP of the incoming HTTP connection); the RP can compare it against the location constraints attached to the session and reject locally with no propagation delay. Critical events have to travel from Entra to the RP through the event channel, and that travel has a 15-minute budget at Microsoft 365 scale.

Workloads that participate

The CAE-aware resource-provider set, per Microsoft Learn [124]:

• Exchange Online: full CAE consumer (initial implementation, October 2020).
• SharePoint Online: full CAE consumer, with the user-risk caveat noted above.
• Microsoft Teams: full CAE consumer in the current Microsoft Learn workload list, with the client-surface caveats in the compatibility table [124].
• Microsoft Graph: consumes Conditional Access policy evaluation events (the IP-location instant path); narrower scope than the M365 productivity workloads.

Client-side support is also explicit. Microsoft's compatibility tables in the CAE concept page enumerate which client and server combinations are Supported, Partially supported, or Not Supported on every major operating system and form factor [124]. Office web apps against SharePoint Online and Exchange Online are documented as Not Supported on several combinations; every Teams client surface shows as Partially supported. The point is not that CAE is broken on these surfaces. It is that Microsoft documents the rough edges in primary source, and tenant administrators who care about specific scenarios must read the table.

Tokens and clients

The default access-token lifetime for CAE-aware sessions is up to 28 hours; the default for non-CAE-capable clients remains 1 hour [124]. Client support requires a current Microsoft Authentication Library (MSAL) release on the target platform. Microsoft Learn's Use Continuous Access Evaluation enabled APIs page enumerates the per-SDK knobs: .WithClientCapabilities(new[] {"cp1"}) for MSAL.NET, clientCapabilities: ["CP1"] for MSAL.js, client_capabilities=["cp1"] for MSAL Python, client_capabilities: "CP1" in MSAL Android JSON configuration, clientApplicationCapabilities = ["CP1"] for MSAL ObjC/iOS/macOS, and WithClientCapabilities([]string{"cp1"}) for MSAL Go [1228]. The important rule is not "edit one universal app-registration field"; it is that the client/application configuration must advertise CP1 and the code must handle the resulting claims challenge.

A migration note for older tenants

Tenant administrators with Conditional Access policies that pre-date GA may carry legacy "strict location enforcement" preview settings. Microsoft has since migrated the feature into GA, and the current Microsoft Learn page Strictly enforce location policies using continuous access evaluation documents the post-migration configuration model [1242]. Administrators should verify their policies after each major Conditional Access feature wave to ensure preview-to-GA migrations have been picked up.

CAE is one approach among several. Where does it sit relative to introspection-per-request, identity-aware proxies, DPoP, and the cross-vendor OpenID standard? The design space is small enough to map cleanly.

Proof surfaces on a live tenant

This chapter contains no lab capture. The evidence posture is therefore strictly documented: the probes below are reproducible tenant surfaces, and the expected shapes come from Microsoft Learn and the source analysis. They are not presented as captured output from this book's lab VM.

# Sign-in log surface: inspect recent sign-ins for event type, Conditional Access
# status, and CAE-related telemetry shape. Exact filtering depends on tenant
# volume and Graph permissions.
Get-MgAuditLogSignIn -Top 20 |
  Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName,
    SignInEventTypes, ConditionalAccessStatus

# Audit-log surface: correlate administrative revocation or password-reset events
# with later resource-provider 401 claims challenges.
Get-MgAuditLogDirectoryAudit -Top 20 |
  Select-Object ActivityDateTime, ActivityDisplayName, Result, InitiatedBy

Expected documented signals, not captured: sign-in logs expose sign-in event typing and Conditional Access status; directory audit logs contain administrator actions such as password reset and revocation of sign-in sessions; Microsoft documents the revocation flow in which Entra sends a revocation event to a resource provider, the resource provider denies the next stale-token request, and the client receives a 401 plus claims challenge. [124]

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer authorization_uri="https://login.windows.net/common/oauth2/authorize",
  error="insufficient_claims",
  claims="eyJhY2Nlc3NfdG9rZW4iOnsibmJmIjp7ImVzc2VudGlhbCI6dHJ1ZSwgInZhbHVlIjoiMTYwNDEwNjY1MSJ9fX0="

Expected documented meaning, not captured: the resource API rejected a token that may still be cryptographically unexpired; error="insufficient_claims" tells the client this is not an ordinary authentication failure; the claims value is passed to MSAL, which requests a new access token so Entra can re-evaluate current user, policy, risk, and location state. [1228]

Expected documented lifetime behavior, not captured: CAE-aware sessions can receive long-lived access tokens up to 28 hours; non-CAE-capable clients keep the default one-hour access-token lifetime; client readiness is advertised with the cp1 client capability, and applications that declare readiness must handle CAE claim challenges for CAE-enabled resource APIs. [124]

The proof is operational rather than theatrical. A Reasoner should be able to show four things in a tenant: the administrative or risk event that changed state, the sign-in or token-issuance shape that indicates CAE participation, the resource-provider 401 claims challenge, and the one-hour-versus-up-to-28-hour lifetime split. If any one of those surfaces is missing, the tenant has not proven the link end to end.

Competing approaches and their relation to CAE

Five named methods occupy adjacent positions in the design space. Some compete; some compose. The map matters because deployments that confuse the two get wrong answers.

CAE versus OpenID SSF and CAEP 1.0

Same architecture, different implementations. Microsoft CAE solves the Microsoft estate via a Microsoft-internal protocol; OpenID SSF and CAEP solve the cross-vendor SaaS long tail via a public standard atop RFC 8417 [1229][1243][1244]. The two are convergent rather than rivalrous: OpenID interop events show vendors building SSF transmitters and receivers around the same publish/subscribe model, while Microsoft continues to document its first-party CAE contract through Microsoft Learn rather than exposing the internal Entra-to-Microsoft-365 channel.

The Authenticate 2025 interop event in October 2025 was the first whose tested text was the Final-Specification version of SSF [1245]. Multi-vendor SSF and CAEP interoperability has been demonstrated at successive Gartner IAM Summit interop events as well. At the March 2024 London summit, SGNL's CAEP Hub interoperated as both transmitter and receiver with Cisco Duo, Okta, SailPoint, and Helisoft on the session-revoked CAEP event [1246]. Okta's own blog characterizes the March 2025 London summit as "a significant industry shift toward interconnected, real-time security" with "interoperable implementations from pioneers like Okta, Google, IBM, Omnissa, SailPoint, and Thales" [1247].

CAE versus RFC 7662 introspection

Parallel paths, not competitors. RFC 7662 introspection [1235] continues to be the right answer for opaque-token systems and on-premises IdPs where the AS-to-RP per-request round-trip is acceptable. CAE wins at hyperscale public-cloud volumes specifically because it inverts the per-request dependency: state pushes to the RP once and lives in cache; the data plane does not consult the AS on every request. If you are building a B2B integration with a small RP count and a few hundred requests per second, RFC 7662 is fine. If you are building Exchange Online, it is not.

CAE versus DPoP and mTLS-bound tokens

Complementary, not competitive. The threat model for CAE is stale authorization: the authorization decision at sign-in is no longer accurate, because the user has been disabled, their password has been reset, their risk score has changed, or their network location has shifted. The threat model for proof-of-possession is stolen tokens: an attacker holding a bearer token that was legitimately issued to a different party.

RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP), published September 2023 by Daniel Fett and collaborators [848], binds an access token to a client-held key pair: a DPoP-bound token can only be replayed by an attacker who also stole the private key. RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, published February 2020 by Brian Campbell and collaborators [1250], does the same thing using mTLS certificates. Both are sender-constrained-token mechanisms; both close the bearer-token-replay attack surface. They are the cloud-token expression of the same proof-of-possession principle the front-door chapters already rely on: the device-bound key behind Windows Hello (Chapter 20) and the origin-bound credential behind WebAuthn and Passkeys (Chapter 21): bind the credential to a key the holder cannot exfiltrate, and possession alone stops being enough.

The consequence follows directly: combine CAE with DPoP or mTLS-binding where the application threat model includes both stale authorization and bearer-token replay. CAE supplies the revocation channel; sender-constraint supplies proof that the presenter still holds the bound key. On Microsoft Entra ID specifically, standard RFC 9449 DPoP is not yet available for Microsoft 365 workloads (Exchange Online, SharePoint, Graph); the shipping sender-constraint there is Token Protection, a Conditional Access session control that binds the issued token to a TPM-backed device key.

CAE versus BeyondCorp-style identity-aware proxies

Different architectural layer. Identity-aware proxies (Google IAP, Cloudflare Access, AWS Verified Access) sit in front of the resource server and enforce policy at the proxy. They have full visibility into per-request state and can do instant revocation by terminating the connection at the proxy when policy changes. This is correct for proxy-fronted workloads but does not scale to the long tail of API surfaces that cannot or will not sit behind a proxy. CAE pushes the enforcement into the resource server itself, which is what lets it work for native cloud APIs and federated SaaS where the proxy model would not.

A note on PRT theft

CAE does not address attacks at the Primary Refresh Token (PRT) layer: the subject of Pass-the-Hash to Pass-the-PRT (Chapter 19). The PRT is a long-lived refresh credential Windows uses to mint access tokens silently from a logged-in session. A stolen PRT can mint CAE-aware access tokens that are, from Entra's perspective, legitimately issued. The attacker holds a credential the IdP still recognizes. CAE will only catch this if the user is revoked, the password is reset, or one of the other critical events fires after the PRT theft. The Pass-the-PRT attack class therefore bypasses CAE entirely; Chapter 19 makes the boundary precise by labeling CAE a dwell-time control over PRT theft (it shortens the window between extraction and detection-driven revocation) rather than an extraction control that could prevent the theft in the first place.