Parag Mali - tag: continuous-access-evaluation

The 28-Hour Bargain: How Continuous Access Evaluation Made Long-Lived Tokens Safe

noreply@paragmali.com (Parag Mali) — Sat, 30 May 2026 00:00:00 GMT

**Microsoft Entra Continuous Access Evaluation (CAE) lets access tokens safely live up to 28 hours.** It works by maintaining a push-subscription channel between Entra and Microsoft 365 resource providers, so that when a user is disabled, has their password reset, or has MFA enabled, the resource provider rejects the next request with a `401` and a claims challenge -- typically within 15 minutes for critical events, instantly for IP-location changes [@ms-cae-concept]. The same pattern was standardized by the OpenID Foundation on September 2, 2025 as SSF 1.0, CAEP 1.0, and RISC 1.0 Final Specifications [@openid-three-final-specs], opening the door to vendor-neutral cross-SaaS revocation. CAE does **not** solve token theft (use DPoP for that) and does **not** cover Microsoft Defender for Endpoint or Intune as resource providers (they are signal sources into Conditional Access, not CAE consumers).

1. Your Fired Employee Is Still Reading Email

09:00 Tuesday. The administrator disables the account at 09:01. At 09:23, the ex-employee's open Outlook for the Web tab refreshes -- and pulls down new mail. This is not a bug. This is RFC 6749 working exactly as designed. Until Microsoft Entra shipped a fix that took ten years and three standards bodies -- the IETF, the OpenID Foundation, and NIST -- to develop, 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 [@rfc-6749].

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" [@ms-cae-concept]. 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.

Note: "Microsoft Entra ID" is the rebranded name for what most engineers learned as "Azure Active Directory" or "Azure AD." Microsoft announced the rename in July 2023 [@ms-entra-rename-2023]; the underlying service, tenants, app registrations, and APIs are unchanged. Throughout this article, "Entra" and the older "Azure AD" refer to the same identity platform.

This article 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 [@ms-cae-concept]. 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.

Microsoft Entra's push-subscription channel between the identity provider and cooperating resource providers (Exchange Online, SharePoint Online, Teams, and Microsoft Graph). CAE lets a resource provider revoke an already-issued access token in near-real-time -- up to 15 minutes for critical events, instantly for IP-location changes -- without waiting for the token to expire [@ms-cae-concept].

The trade has a price. The 15-minute critical-event service-level objective is the price the channel pays for fanning out events across hyperscale Microsoft 365 infrastructure. Sub-second revocation is possible -- other vendors demonstrate it at smaller scales -- but at Exchange-Online volume, 15 minutes is the engineering economics. We will earn that number by Section 8.

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.

2. 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 five years arguing about it [@rfc-6749]. Section 1.4 carries one of the most consequential adjectives in cloud-identity history. Access tokens, it says, are credentials "usually with a short lifetime" used by the client to access a protected resource. The word usually is doing heavy lifting. Nothing in the protocol enforces it. 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

The pre-2012 enterprise-identity pattern in which every protected HTTP request synchronously queried a central policy decision point. Strength: instant revocation, because every request consulted authoritative state. Weakness: a chatty bottleneck that did not scale to cloud volumes and could not federate trust across organizations.

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

Two intellectual pressures forced the question. The first came from Google. In December 2014, Rory Ward and Betsy Beyer published BeyondCorp: A New Approach to Enterprise Security in USENIX ;login: [@ward-beyer-2014-beyondcorp].Beyer would later co-author Site Reliability Engineering (O'Reilly, 2016); BeyondCorp came out of the same Google culture of evidence-driven infrastructure engineering. The argument was philosophical: a session is not a one-shot decision at sign-in. It is a time-varying authorization. Trust signals -- device posture, network location, behavioral risk -- change continuously, and the access decision should change with them. BeyondCorp was not a CAE implementation; it predates the term. But it planted the seed that login-time enforcement was not enough.

The second pressure was bureaucratic. In August 2020, NIST published Special Publication 800-207, Zero Trust Architecture, by Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly [@nist-sp-800-207]. SP 800-207 codified the BeyondCorp philosophy as U.S. federal guidance. One sentence 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. The gap RFC 6749 had left was now a procurement problem.

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 [@tulshibagwale-2019-google-blog]. 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 in Section 5. For now what matters: 2019 was the year the industry got a vocabulary for a problem it had been carrying for seven years.

The OpenID Foundation working group that grew out of Tulshibagwale's proposal was originally chartered as the Shared Signals & Events (SSE) working group. It was renamed Shared Signals in subsequent years, but older industry write-ups from 2020-2022 still use the SSE abbreviation [@idsalliance-2022-11-cae].

gantt title CAE and Shared Signals timeline (2012-2025) dateFormat YYYY-MM axisFormat %Y section IETF standards RFC 6749 OAuth 2.0 :done, a1, 2012-10, 30d RFC 7009 Token Revocation :done, a2, 2013-08, 30d RFC 7662 Token Introspection :done, a3, 2015-10, 30d RFC 8417 SET :done, a4, 2018-07, 30d RFC 8935 SET Push :done, a5, 2020-11, 30d RFC 8936 SET Poll :done, a6, 2020-11, 30d section Zero Trust thinking BeyondCorp paper :done, b1, 2014-12, 30d NIST SP 800-207 Final :done, b2, 2020-08, 30d section CAEP origin and OIDF Tulshibagwale CAEP post :done, c1, 2019-02, 30d OIDF Shared Signals WG :done, c2, 2019-09, 30d SSF 1.0 CAEP 1.0 RISC 1.0 :done, c3, 2025-09, 30d section Microsoft Entra CAE Limited preview Weinert :done, d1, 2020-04, 30d Expanded preview Simons :done, d2, 2020-10, 30d General Availability :done, d3, 2022-01, 30d

The OAuth 2.0 designers traded revocation latency for throughput on purpose [@rfc-6749]. 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.

3. 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 [@rfc-7009]. 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 [@rfc-7009]. 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 [@rfc-7662]. 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 Graph 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.

RFC 7662 introspection is alive and well. It remains the right choice for opaque-token systems and on-premises IdPs where the resource server count is small, the per-request latency budget is generous, and the AS is well within capacity. The criticism here is structural and only applies at hyperscale public-cloud volumes. RFC 7662 was not killed by RFC 7009 or by CAE; it is a parallel path that continues to serve a substantial fraction of the deployed OAuth surface.

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 towards real time policy and security enforcement on the Azure Active Directory Identity Blog [@weinert-2020-04-real-time]. (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 [@jpazureid-blog-1-japanese].) The post names the failure mode in one sentence:

"We have experimented with the "blunt object" approach of reduced token lifetimes but found they can degrade user experiences and reliability without eliminating risks." -- Alex Weinert, Microsoft, April 21, 2020 [@weinert-2020-04-real-time]

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.

Note: Each of the three patches fails for a different reason; together they rule out everything except server-initiated push subscription that decouples revocation from expiry.

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.

4. Four Generations of Session Enforcement

Walk forward through the genealogy of session enforcement and the breakthrough in Section 5 stops looking like a stroke of genius and starts looking like the only move the design space had left. 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 [@rfc-6749]. 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 Section 3 patches, 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 towards real time policy and security enforcement announcement [@weinert-2020-04-real-time]. Expanded public preview October 2020 [@simons-2020-10-expanded-preview; @vansurksum-2020-10-10]. General Availability January 10, 2022, announced by Alex Simons, Corporate VP for Program Management in the Microsoft Identity Division [@simons-2022-01-ga-rss].

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 [@ms-cae-concept]. We will unpack the mechanism in Section 5.

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) [@openid-three-final-specs; @openid-sharedsignals-wg].

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) [@rfc-8417]. 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 [@rfc-8935; @rfc-8936]. 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.

IETF RFC 8417's standardized signed-JWT envelope for transmitting security-relevant events between systems. Each SET carries exactly one event with a well-defined event-type URI; the envelope is signature-protected and timestamp-bearing. SET is the wire format underlying CAEP, SSF, and RISC, as well as Microsoft's internal CAE protocol [@rfc-8417].

RFC 8417 was a cross-vendor IETF effort that pre-dated the OpenID Shared Signals working group by a year. Phil Hunt was at Oracle; Michael Jones at Microsoft; William Denniss at Google; Morteza Ansari at Cisco. The envelope-only design -- leaving event vocabularies to higher-layer profiles -- is what allowed both Microsoft's internal protocol and the OpenID profiles to converge on the same wire format without coordination [@rfc-8417].

flowchart TD L4["Layer 4: Event vocabularies
CAEP 1.0 (session) and RISC 1.0 (account)"] L3["Layer 3: Subscription and stream model
OpenID SSF 1.0"] L2["Layer 2: HTTP transport
RFC 8935 push, RFC 8936 poll"] L1["Layer 1: Signed event envelope
RFC 8417 Security Event Token (SET)"] L4 --> L3 L3 --> L2 L2 --> L1

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

Approach	Year	Revocation latency	Strengths	Weaknesses
WAM (Gen 0)	pre-2012	Instant	Authoritative state, instant enforcement	No federation, per-request bottleneck
Static-expiry JWT (Gen 1)	2012-2020	Up to token lifetime (1h-24h)	O(1) RP validation, federation works	No revocation; fired-employee window
Short-lifetime patch	mid-2010s	Minutes	Conceptually simple	Load amplification, window remains, UX degradation
RFC 7662 introspection	2015 onward	Instant	Standardized, works for opaque tokens	AS becomes per-request critical path
Microsoft CAE (Gen 2)	2020-2022	Up to 15 min critical; instant IP	Push, decoupled from request rate, long tokens safe	Microsoft-internal protocol; tiny RP set
OpenID SSF/CAEP (Gen 3)	2025 onward	Vendor-dependent	Vendor-neutral standard, cross-SaaS	Receiver adoption still early

flowchart LR G0["Gen 0: WAM
per-request PDP"] G1["Gen 1: Static-expiry JWT
RFC 6749 (2012)"] G2["Gen 2: Microsoft CAE
GA January 2022"] G3["Gen 3: OpenID SSF and CAEP
Final September 2025"] G0 -- "cloud scale and federation" --> G1 G1 -- "fired-employee window, patches fail" --> G2 G2 -- "Microsoft-only, no cross-SaaS" --> G3

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.

5. Subscription, Claims Challenge, Extended Lifetime

Three innovations, none new in isolation, all unprecedented in combination. This is the section where you see the trick.

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" [@tulshibagwale-2019-google-blog]. 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:

Timely response to policy violations or security issues really requires a 'conversation' between the token issuer Microsoft Entra, and the relying party (enlightened app). -- Microsoft Learn, *Continuous access evaluation in Microsoft Entra* [@ms-cae-concept]

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 [@ms-cae-concept].

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 [@ms-cae-app-resilience].

The HTTP-level mechanism by which a CAE-aware resource provider signals to a client that the presented token must be re-acquired with fresh state. The challenge is conveyed as a `WWW-Authenticate: Bearer error="insufficient_claims"` header with a base64url-encoded `claims` parameter; current Microsoft Authentication Library (MSAL) releases decode and handle it automatically when the client app registration declares the `xms_cc` capability `["cp1"]` [@ms-cae-app-resilience].

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.

{` // A real-shape WWW-Authenticate header from a CAE-aware resource provider. // The 'claims' parameter is base64url-encoded JSON. const header = 'Bearer error="insufficient_claims", claims="eyJhY2Nlc3NfdG9rZW4iOnsibmJmIjp7ImVzc2VudGlhbCI6dHJ1ZSwgInZhbHVlIjoiMTcyMDQ4MDA0MyJ9fX0="';

// Extract the claims parameter const match = header.match(/claims="([^"]+)"/); const b64 = match ? match[1] : null;

// base64url decode (Node 'Buffer' would work; here we use the browser-safe approach) function b64urlDecode(s) { s = s.replace(/-/g, '+').replace(/_/g, '/'); while (s.length % 4) s += '='; return atob(s); }

const claimsJson = b64urlDecode(b64); console.log(JSON.parse(claimsJson)); // { // "access_token": { // "nbf": { // "essential": true, // "value": "1720480043" // } // } // } // MSAL reads this and requests a new token whose 'nbf' (not-before) is at least // the supplied timestamp -- i.e., a token issued after the state change. `}

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 within seconds of seeing 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 [@ms-cae-concept; @ms-cae-app-resilience]. 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.

Key idea: Long-lived access tokens are safe only when paired with a near-real-time revocation channel. CAE is the channel. Subscription provides the push, the claims challenge is the in-band handshake the push enables, and the 28-hour lifetime is what the channel buys -- not what the channel costs.

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 the article has named.

sequenceDiagram participant Admin participant Entra as Microsoft Entra participant Client as Client (MSAL) participant RP as Resource Provider (e.g. Exchange Online) Admin->>Entra: Disable user account Entra->>RP: Push critical-event SET (account disabled) Note over RP: Updates cached revocation state for (sub, tenant) Client->>RP: GET /me/messages (Authorization Bearer old token) Note over RP: Validates JWT signature O(1), checks cached state RP-->>Client: 401 plus WWW-Authenticate insufficient_claims Note over Client: MSAL parses claims challenge from header Client->>Entra: Token request with claims Note over Entra: Checks current user state, account is disabled Entra-->>Client: 400 invalid_grant or interactive re-auth required Note over Client: User cannot recover, session terminates

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?

6. 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 [@ms-cae-concept]:

A user account is deleted or disabled.
A password for a user is changed or reset.
Multi-factor authentication is enabled for the user.
An administrator explicitly revokes all refresh tokens for a user.
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 [@ms-cae-concept]. 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 [@ms-cae-concept]. 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.

Event	Source	Propagation	Notes
Account deleted or disabled	Entra ID directory	Up to 15 min	Honored by Exchange Online, SharePoint Online, Teams, Graph (CA)
Password changed or reset	Entra ID directory	Up to 15 min	Same RP set
MFA enabled for user	Entra ID directory	Up to 15 min	Same RP set
All refresh tokens revoked (admin)	Entra ID admin action	Up to 15 min	Same RP set
High user risk detected	Entra ID Protection	Up to 15 min	SharePoint Online does not honor user-risk events [@ms-cae-concept]
IP location changed (CA policy)	Resource-provider observation	Instant	Conditional Access policy evaluation path; strict location enforcement [@ms-strict-location-enforcement]

Note: Microsoft Defender for Endpoint and Microsoft Intune (MDM) are signal sources into Conditional Access. They contribute to the risk score and device-compliance state that drive CA policy decisions, but they are not CAE-consuming resource providers. They do not subscribe to Entra critical-event notifications and they do not enforce the claims-challenge handshake on token-bearing requests. The CAE-aware RP set is exactly: Exchange Online, SharePoint Online, Microsoft Teams, and Microsoft Graph (the last only for Conditional Access policy evaluation) [@ms-cae-concept]. If you read older deck slides or vendor blog posts that list MDE or Intune as CAE participants, they are conflating the signal-source role with the resource-provider role.

The SharePoint Online user-risk caveat is a concrete example of why "CAE-aware" is not a binary property at the workload level. SharePoint Online is fully CAE-aware for the first four critical events on the list; it just does not subscribe to user-risk events specifically. The lesson is that you must read the per-workload documentation carefully when designing controls that depend on a specific event's enforcement [@ms-cae-concept].

Workloads that participate

The CAE-aware resource-provider set, per Microsoft Learn [@ms-cae-concept]:

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 (initial implementation), per Alex Simons's January 2022 GA announcement [@simons-2022-01-ga-rss].
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 [@ms-cae-concept]. 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 [@ms-cae-concept; @ms-cae-app-resilience]. Client support requires a current Microsoft Authentication Library (MSAL) release on the target platform: the 4.x line for .NET and JavaScript; the appropriate current line for Python, Java, Android, iOS, or macOS, per each SDK's own release stream. Microsoft Learn's Use Continuous Access Evaluation enabled APIs page enumerates per-SDK guidance [@ms-cae-app-resilience]. The app registration must also declare the xms_cc client capability with value ["cp1"] to advertise CAE-handling support to the IdP [@ms-cae-app-resilience].

An app-registration claim by which a client advertises support for CAE-aware token issuance. The canonical wire-level value in the issued JWT is lowercase `"cp1"` (Microsoft's developer docs show both `"cp1"` and `"CP1"`; negotiation is case-insensitive but the token claim is lowercase). It signals that the client's MSAL implementation can decode and act on a `WWW-Authenticate: Bearer error="insufficient_claims"` response by parsing the `claims` parameter and re-acquiring a token. Without it, Entra issues the default 1-hour token and the resource provider falls back to standard expiry [@ms-cae-app-resilience]. A Microsoft 365 workload (Exchange Online, SharePoint Online, Teams, or Microsoft Graph for Conditional Access policy) that consumes Entra's critical-event notifications and enforces them on subsequent token-bearing requests via the claims-challenge handshake. This is a narrower meaning than the generic OAuth 2.0 sense of "resource server"; in CAE, "resource provider" specifically means a workload that has implemented the CAE participation contract with Entra [@ms-cae-concept]. Microsoft documents an *upper bound* on token lifetime. The actual lifetime issued for any given session is variable and can be shorter. CAE-aware sessions can also be refreshed silently as long as the channel signals nothing has changed. Practically, this means most users with CAE-aware clients on M365 productivity workloads almost never see an interactive re-authentication prompt during normal working hours [@ms-cae-concept].

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 [@ms-strict-location-enforcement]. 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.

7. 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 [@openid-three-final-specs; @openid-ssf-1_0-final; @openid-caep-1_0]. The two are convergent rather than rivalrous: Microsoft is moving toward also acting as an SSF transmitter and receiver alongside its first-party CAE protocol, and other vendors are building SSF receivers that can consume signals from any transmitter, including Microsoft.

The Authenticate 2025 interop event in October 2025 was the first whose tested text was the Final-Specification version of SSF [@openid-authenticate-2025-interop]. 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 [@sgnl-2024-04-interop]. 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" [@okta-shared-signals].

Tim Cappalli, who joined Okta after his time at Microsoft, co-chairs the OpenID Shared Signals Working Group alongside Atul Tulshibagwale (SGNL, formerly Google) [@tulshibagwale-sgnl-2023-08-qanda; @openid-sharedsignals-wg]. The cross-vendor co-chair arrangement is part of why the Final Specifications passed without significant vendor pushback: the people doing the standardization had visibility into both Microsoft's and Google's prior implementations.

CAE versus RFC 7662 introspection

Parallel paths, not competitors. RFC 7662 introspection [@rfc-7662] 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 [@rfc-9449-dpop], 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 [@rfc-8705-mtls], does the same thing using mTLS certificates. Both are sender-constrained-token mechanisms; both close the bearer-token-replay attack surface.

CAE does not address token theft. A stolen CAE-aware token is still usable by the attacker until the IdP or RP becomes aware of the compromise. A DPoP-bound CAE-aware token closes both gaps: the attacker cannot replay it, and even if they could, the channel can revoke it within minutes. The correct deployment pattern is to combine CAE with DPoP or mTLS-binding where the application threat model warrants both.

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 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; defenses for that layer are out of scope here and are a separate engineering problem.

Mapping the design space

The table is the cleanest way to see who competes with whom and who composes with whom.

Approach	Solves	Composes with CAE	Competes with CAE
OpenID SSF/CAEP 1.0	Cross-vendor revocation	Yes (CAE is a Microsoft implementation of the same pattern)	No
RFC 7662 introspection	Opaque-token revocation at modest scale	Parallel path	At hyperscale only
DPoP (RFC 9449)	Sender-constrained tokens	Yes (compose for full coverage)	No
mTLS-bound tokens (RFC 8705)	Sender-constrained tokens	Yes (compose for full coverage)	No
Identity-aware proxy	Per-request policy at the proxy edge	Composes for proxy-fronted workloads	Different layer
Short access-token lifetime	Reduces revocation window mechanically	Falls back when CAE not available	Yes, and loses on the trade

The reader who came to this article expecting a binary contest -- "which one wins?" -- has the wrong frame. The actual answer is that CAE is one move in a layered defense, and most production deployments will end up composing it with DPoP or mTLS for token binding, falling back to short lifetimes for non-CAE clients, and continuing to use introspection for opaque-token internal APIs.

That handles deployment. But every architecture has limits. The reader has spent six sections climbing; the next section is the humility beat where the descent begins.

8. Theoretical Limits: What CAE Cannot Do

Every architecture has a floor. The reader has spent six sections climbing; this is where the limits show up -- not as vendor laziness, but as physics, scale, and trust topology.

Limit 1: cannot revoke a token already in flight

Once a request has been accepted and is being served by the resource provider, CAE cannot reach into the RP's execution thread and abort it. The revocation applies to the next request. A long-running operation -- a bulk Outlook export, a large SharePoint upload -- that began at 10:23:00 may complete normally even if the user is disabled at 10:23:01. The revocation takes effect the next time the client presents the token [@ms-cae-concept]. For most use cases the in-flight window is sub-second and the consequence is negligible; for long-running data egress, it matters.

Limit 2: cannot beat the 15-minute critical-event SLA for most events

Microsoft's published SLA is "up to 15 minutes" for critical-event propagation [@ms-cae-concept]. Only IP-location enforcement is instant. The 15-minute number is not a fundamental limit; it is engineering economics at hyperscale. Fanning out an event to every CAE-aware RP for every potentially affected subject across Microsoft 365's global infrastructure is what produces the budget. Smaller-scale deployments demonstrate much better numbers: TigerIdentity's commercial deployment self-reports sub-second end-to-end revocation in a tuned CAEP receiver configuration [@tigeridentity-caep-explained]. The architecture allows sub-second; Microsoft's particular deployment chooses 15 minutes because the alternative at its fan-out scale is prohibitively expensive.

The strict physical floor sits below even the tuned implementations. An RP cannot enforce a revocation it has not yet learned about. The one-way network latency $L$ between IdP and RP sets the absolute minimum: with a transcontinental $L \approx 70,\text{ms}$, no push protocol can revoke faster than that, and pull protocols are necessarily worse. In practice, queuing, scheduling, and event-fanout dominate $L$ at scale -- but the floor remains.

Key idea: The 15-minute SLA is not a fundamental limit; it is engineering economics at hyperscale. Sub-second is feasible at smaller fan-outs, and is the direction of travel as receiver implementations improve and as Microsoft's own event-distribution infrastructure ages well. But the strict physical floor is the network latency between IdP and RP; no cooperative protocol can do better than that.

Limit 3: cannot cover non-CAE-aware clients or resource providers

CAE is a cooperative protocol. Both the client (via the xms_cc=cp1 capability declaration) and the resource provider (via implementing the participation contract) must be CAE-aware [@ms-cae-app-resilience]. A non-CAE client receives a default 1-hour token and never sees a claims challenge; it relies on standard expiry. A non-CAE RP silently falls back to standard token expiry as well; the IdP's events have no consumer. The CAE-aware portion of the estate enjoys the new contract; the rest carries the old security debt unchanged.

This is why audit posture matters. A tenant administrator who wants to argue that revocation latency for their workforce is "under 15 minutes" must be able to demonstrate that the client and RP combinations the workforce actually uses are CAE-aware. Microsoft's compatibility tables [@ms-cae-concept] document several Office-web-app and OneDrive-Win32-versus-SharePoint combinations as Not Supported or Partially supported; those gaps are part of the tenant's effective revocation profile, not someone else's problem.

Limit 4: cannot help if the resource provider itself is compromised

Revocation state lives at the RP. A compromised RP can simply ignore revocation events: keep serving requests against tokens Entra has signaled are invalid; misreport its own subscription state; drop events on the floor. CAE is a cooperative protocol between trustworthy parties. It is not a defense against an RP that has been pwned. The OpenID SSF specification addresses this implicitly by defining receiver requirements (verification events, stream-control endpoints, signature verification on SETs), but no receiver requirement can compel a compromised receiver to obey the protocol.

The threat model implication: an attacker who has compromised an RP does not need to bypass CAE. They simply do not implement it from the inside, and the protocol's design has no remedy. RP integrity is a prerequisite, not a guarantee.

Limit 5: cannot revoke a stolen PRT before it mints a new access token

As noted in Section 7, the Primary Refresh Token sits outside CAE's scope. A stolen PRT mints new CAE-aware access tokens that Entra treats as legitimately issued, because from Entra's perspective they are legitimately issued -- the attacker is presenting a credential the IdP recognizes. CAE catches PRT theft only when one of the five critical events fires after the theft. If the attacker exfiltrates a PRT, refreshes a token, and immediately uses it, the access token is valid and the revocation channel has nothing to revoke.

The SharePoint Online user-risk-event caveat is a useful concrete example of the per-feature limit pattern. Even within the four CAE-consuming RPs, feature support is not uniform; you cannot reason about CAE as a single boolean property at the workload level. Every event you care about must be checked against the specific RP that will enforce it [@ms-cae-concept].

The bounded design space

Put together, the five limits draw the perimeter of what CAE can do. It cannot stop in-flight requests. It cannot beat network latency at the strict floor or 15 minutes at Microsoft's chosen operating point. It cannot help non-participating clients or RPs. It cannot fix a compromised RP. It cannot revoke PRT-layer credentials before they mint new tokens. The honest summary is that the design space is bounded -- the reader who internalizes the five limits has a calibrated sense of what is fundamentally possible, and can stop expecting CAE to be a single fix for revocation in all situations.

The limits also map the open frontier. If those are the structural constraints, what are the OpenID Foundation and the SaaS long tail working on in 2026?

9. Open Problems (2026)

Final Specifications are necessary but not sufficient. CAEP 1.0, SSF 1.0, and RISC 1.0 were approved on September 2, 2025 [@openid-three-final-specs]. The question for 2026 is what adoption and extension look like. Five live problems.

1. Third-party SaaS receiver-adoption depth

The Final Specifications give every SaaS vendor a clean target to build against. The question is whether they will. Google Workspace shipped its SSF receiver in Closed Beta, supporting only the session-revoked CAEP event at launch [@google-workspace-ssf-api]. That is one event out of CAEP 1.0's eight. The SaaS long tail -- Workday, ServiceNow, GitHub Enterprise, Atlassian, Salesforce -- has not, as of the Final Specification's first anniversary, shipped public receivers.

For the "fired employee with N SaaS apps" scenario to be fully solved, every SaaS app in the user's bundle has to be a CAEP receiver subscribed to events from the enterprise IdP. The architecture is in place; the integration work is per-vendor and per-customer. This is the largest single determinant of CAE's real-world value over the next several years.

Note: The Microsoft 365 estate enjoys near-complete CAE coverage because Microsoft built both the IdP and the resource providers. The cross-vendor story is fundamentally a coordination problem: every receiver has to be built, deployed, and configured to subscribe to events from every transmitter the enterprise uses. SSF 1.0 makes the integration tractable; it does not make the work disappear. Watch receiver coverage in 2026-2028 as the leading indicator of CAE's industry-wide impact.

2. CAE for non-human and agent identities

CAEP subject identifiers assume user-shaped or device-shaped subjects [@openid-caep-1_0]. Workload identities, service principals, and emerging AI-agent identities sit outside the model as currently profiled. An agent acting on behalf of a user, with its own identity and its own session, is not yet covered by a Final-Specification profile. The Microsoft Entra Conditional Access for Agent Identities workstream is a documented Microsoft Learn surface as of 2026 [@ms-conditional-access-agent-id] and is one of the workstreams that will eventually produce a CAEP profile for non-human subjects, but as of mid-2026 the cross-vendor standardization gap is open.

3. Cross-IdP federation of SSF streams

When tenant A federates to tenant B, the event-flow path crosses a trust boundary the current Final Specifications do not explicitly profile. If a user is disabled in tenant A's IdP, how does the revocation event reach the resource providers downstream in tenant B? The pieces -- transmitter, receiver, SET envelope, signed events -- are all in place; what is missing is the canonical profile for cross-IdP federation of SSF streams. This is a 2026-2027 OpenID Foundation workstream rather than a Final-Specification gap.

4. Bidirectional signal sharing

Today's CAE and CAEP deployments are largely IdP-as-transmitter, RP-as-receiver. The full vision is bidirectional: an RP that detects anomalous behavior (unusual access patterns, suspected automation, post-authentication risk signals) should be able to transmit those signals back to the IdP, which can then incorporate them into the next authorization decision. SGNL and similar vendors are building toward this model. The Final Specifications support bidirectional flow at the protocol level; the policy and operational pieces -- who trusts whom, what events flow which way, how an IdP weighs signals from an RP -- are still being worked out.

5. Reason-code convergence between CAEP and RISC

CAEP 1.0 and RISC 1.0 cover overlapping ground around credential mutation. CAEP defines a credential-change event; RISC defines account-credential-change-required [@openid-caep-1_0; @openid-sharedsignals-wg]. Implementers must choose, and vendor extensions proliferate where the spec leaves room. Reason-code convergence between the two profiles is incomplete; some receivers will subscribe to both streams to be safe, others will pick one and hope upstream transmitters agree. Over time the WG will likely consolidate; for 2026, the practical guidance is to support both event vocabularies in receiver code.

The first interoperability event whose tested text was the Final-Specification version of SSF took place at Authenticate 2025 in San Diego, October 13-15, 2025, hosted by the FIDO Alliance and coordinated by the OpenID Foundation Shared Signals Working Group [@openid-authenticate-2025-interop]. The event required that all participants with an SSF Transmitter pass the OpenID Foundation's free, open-source conformance tests. This was the fourth in a series of Gartner-IAM and Authenticate interops since March 2024, and the first conducted after SSF 1.0 was approved Final on September 2, 2025. The list of vendor participants has grown at each event; cross-vendor receiver coverage is the metric to watch.

Given all this -- the architecture, the limits, the open frontier -- what should you actually do this week in your tenant and your code?

10. Turning CAE On in Your Tenant and Your Code

Three audiences, three checklists. Each section is what an engineer in that role needs to confirm or change to make CAE work in their environment.

For the tenant administrator

CAE has been auto-enabled by default for new Microsoft Entra tenants since the January 2022 GA [@simons-2022-01-ga-rss]. Tenants created before then may need to verify enablement in Conditional Access -> Session controls -> Customize continuous access evaluation. The relevant signals to check:

CAE enablement state. Confirm that the tenant-wide CAE policy is set to Enabled rather than Disabled or Strict location.
Per-policy disable flags. Some legacy CA policies carry per-policy CAE overrides. Audit any that explicitly disable CAE; the right default is to honor it.
Strict location enforcement migration. Tenants with pre-GA "strict location enforcement" preview settings should verify that the policy has migrated to the current GA configuration model documented in Microsoft Learn [@ms-strict-location-enforcement].
Audit log baselines. Sign-in logs surface signInEventTypes with CAE-related entries; refresh-token issuance events and revocation events appear in the Entra ID audit log. Build a baseline before changing policies so you can detect drift.

For the MSAL client developer

The client side has three things to confirm and one thing to test:

MSAL version. Use a current MSAL release on your client platform: 4.x for MSAL.NET and MSAL.js; the appropriate current line for MSAL Python, MSAL Java, MSAL Android, and MSAL for iOS/macOS, per each SDK's own release stream. Microsoft Learn's Use Continuous Access Evaluation enabled APIs page enumerates the per-SDK guidance [@ms-cae-app-resilience]. Earlier major-version lines do not handle the claims challenge transparently.
Capability declaration. The app registration must declare xms_cc with value ["cp1"] (lowercase is the canonical token-claim form; uppercase "CP1" also works because negotiation is case-insensitive). This is the wire-level signal to Entra that the client can handle a CAE-aware token and the claims challenge that comes with it.
Claims-challenge handling. MSAL helpers do this transparently in current SDK versions, but custom HTTP pipelines that bypass MSAL must implement the WWW-Authenticate: Bearer error="insufficient_claims" response handler manually. Decode the claims parameter (base64url), pass it to AcquireTokenInteractive or the equivalent, retry the original request with the new token.
End-to-end test. Trigger an admin password reset against a test user in a non-production tenant and verify that the next API call from a signed-in MSAL session surfaces the claims challenge and recovers cleanly. This is the single most useful confidence test; it exercises every layer of the protocol in one round trip.

{` // Illustrative: inspect an MSAL JS token-cache entry for the xms_cc capability // marker. In real apps, MSAL handles capability negotiation; this is for // educational inspection only.

// A real-shape AccessTokenEntity from MSAL JS cache const tokenEntity = { homeAccountId: 'abc.def-tenant', environment: 'login.microsoftonline.com', credentialType: 'AccessToken', clientId: '11111111-2222-3333-4444-555555555555', tenantId: 'tenant-id', target: 'User.Read Mail.Read', // expiresOn is up to ~28 hours after cachedAt for CAE-aware sessions cachedAt: '1748534400', expiresOn: '1748635200', // 28h later extendedExpiresOn: '1748635200', // Capability declaration the app advertised at acquisition time requestedClaims: { xms_cc: ['cp1'] } };

const ttlSeconds = parseInt(tokenEntity.expiresOn) - parseInt(tokenEntity.cachedAt); const ttlHours = ttlSeconds / 3600; const isCaeAware = tokenEntity.requestedClaims && tokenEntity.requestedClaims.xms_cc && tokenEntity.requestedClaims.xms_cc .some(c => c.toLowerCase() === 'cp1');

console.log('TTL hours:', ttlHours.toFixed(1)); console.log('CAE-aware:', isCaeAware); // TTL hours: 28.0 // CAE-aware: true // A TTL above ~1 hour with xms_cc cp1 is a strong indicator the session is // CAE-aware and Entra issued an extended-lifetime token. `}

For the custom-API author

This is the hardest path. To make a custom protected API a CAE-aware resource provider today, the first-party Microsoft pathway is not publicly available -- the CAE participation contract for the M365 productivity workloads is internal to Microsoft. The community-canonical implementation pattern is Damien Bowden's damienbod/AspNetCoreMeIDCAE reference repository on GitHub [@damienbod-aspnetcoremeidcae], with an accompanying blog post walkthrough [@damienbod-blog-2022-04]. The repository (initial version April 3, 2022; updated through .NET 10 in late 2025) demonstrates:

The xms_cc=cp1 capability declaration on both the client and the API app registrations.
The Microsoft.Identity.Web claims-challenge handling on the API side.
The Razor Page client flow that catches a 401 with the challenge header and re-acquires the token.

For a fully standards-track pathway, the same custom API can be built as an OpenID SSF receiver consuming CAEP events from any SSF-compliant transmitter, using the RFC 8417 SET envelope over the RFC 8935 push transport [@rfc-8417; @rfc-8935]. Production-grade SSF receiver code is now available in commercial CAEP Hub products (SGNL, TigerIdentity) and a growing set of open-source libraries.

Note: CAE itself does not require add-on licensing for the basic critical-event evaluation across Microsoft 365 -- it is part of the Entra ID baseline for new tenants. The Microsoft Entra ID Protection feed that drives high user risk detected events, however, requires Microsoft Entra ID P2 (or an equivalent SKU that includes Identity Protection). Confirm current licensing terms in the Microsoft licensing documentation before making procurement decisions; the lower SKUs cover four of the five critical events but not the risk-based one [@ms-cae-concept].

Observability

Sign-in logs and audit logs are where CAE behavior shows up. Look for:

Sign-in logs: filter by signInEventTypes containing CAE-related entries. CAE-aware sign-ins have a different telemetry shape than non-CAE sign-ins.
Token-issuance events: refresh-token issuance against CAE-aware app registrations should show the extended lifetime.
Audit log revocation entries: administrator revocation actions and Identity-Protection-driven revocations appear here; cross-correlate with the resource-provider-side telemetry to validate end-to-end propagation.

Use Microsoft Graph PowerShell to enumerate the tenant's CAE configuration and then trigger a synthetic test: 1) read `Get-MgIdentityConditionalAccessPolicy` to verify the relevant CA policies have CAE enabled in their `SessionControls.ContinuousAccessEvaluation` block; 2) create a test user, sign them in via Outlook on the Web; 3) reset their password via `Update-MgUser`; 4) observe in the audit log that the password reset propagates to a CAE event, and verify in Outlook on the Web that the next refresh surfaces a re-authentication prompt within the 15-minute SLA. This is the simplest end-to-end confidence test that does not require modifying any production resource.

Defaults are good

The most common engineering recommendation here is to leave the defaults alone. CAE on, default tenant settings, current MSAL clients, xms_cc=cp1 on every new app registration. The configuration surface area is small precisely because the design is right: there are not many knobs to turn. The work is in confirming that the client and RP combinations your users actually exercise are CAE-aware, and in monitoring the audit logs to catch drift.

That is what to do. The last section is what to remember -- the misconceptions every team carries into a CAE conversation, and the answers that close them.

11. FAQ and Coda

No. The published SLA is up to 15 minutes for the five critical events; only IP-location enforcement is instant. See Section 6 for the mechanical reason for the asymmetry and Section 8 Limit 2 for why 15 minutes is engineering economics rather than a fundamental limit [@ms-cae-concept]. No. CAE addresses *stale authorization* (the original authorization decision is no longer correct), not *stolen tokens* (an attacker is presenting a token that was legitimately issued to someone else). For token theft, use a sender-constrained-token construction: DPoP per RFC 9449 [@rfc-9449-dpop] or mTLS-bound tokens per RFC 8705 [@rfc-8705-mtls]. Both compose cleanly with CAE; a DPoP-bound CAE-aware token is the strongest commonly-deployed combination today, closing both the replay attack surface and the stale-authorization gap. No. SSF 1.0, CAEP 1.0, and RISC 1.0 were approved as OpenID Foundation Final Specifications on September 2, 2025 -- see Section 4 for the standards-stack treatment [@openid-three-final-specs]. No. MDE and Intune are signal sources into Conditional Access, not CAE-consuming resource providers; see the Section 6 Common-misconception callout for the full distinction and the CAE-aware RP set [@ms-cae-concept]. *Not when the resource provider is CAE-aware.* The token lifetime stops carrying the revocation weight; the channel does. A CAE-aware RP can revoke a 28-hour token within 15 minutes of a critical event, which is a strictly better revocation profile than a 1-hour token with no channel (revocable only at the 1-hour expiry boundary in the worst case) [@ms-cae-concept]. *Yes*, however, when the RP is *not* CAE-aware: the token then carries its full lifetime as the revocation window, and longer is worse. The architectural rule: only issue extended-lifetime tokens to clients whose RPs are CAE-aware -- which is exactly what the `xms_cc=cp1` capability negotiation enforces [@ms-cae-app-resilience]. No. CAE is specific to OAuth 2.0 and OpenID Connect access tokens. SAML assertions have their own lifetime and replay-protection model and are not in scope for the CAE participation contract or for the OpenID SSF/CAEP profiles [@ms-cae-concept; @openid-caep-1_0]. If you are still operating SAML-fronted workloads, the analogous design problem (revocation between sign-in and assertion expiry) is solved differently and is largely a per-product implementation question rather than a standards story.

Coda: the bargain

The OAuth 2.0 designers in 2012 took a deliberate trade: short-lived self-contained tokens were the price they paid to escape the WAM bottleneck. The trade was correct for the web they were designing for. It became wrong the moment enterprises ran compliance-bound SaaS at scale on top of those tokens. Three obvious patches were tried -- the /revoke endpoint, the /introspect endpoint, the short-lifetime experiment -- and each failed for a distinct reason: the wrong party initiates revocation; the AS becomes a per-request critical path; expiry as a blunt instrument creates load and reliability problems while still leaving a window.

What replaced them was an architecture that took two facts seriously. First, revocation has to be push from the IdP to the RP -- not pull from RP to AS, not client-initiated POST to /revoke. Second, expiry and revocation can be separated: once the channel handles revocation, expiry can be measured in days rather than minutes. The 15-minute critical-event SLA and the up-to-28-hour token lifetime are two halves of the same bargain. Microsoft Entra ships them together because they only work together; the OpenID Foundation has standardized the same pattern across vendors because the long tail of SaaS faces the same problem.

The architecture is settled; the adoption is in progress. The CAEP, SSF, and RISC Final Specifications give every SaaS vendor a tractable target. The Microsoft 365 estate is already covered. Cross-vendor receiver coverage is the metric that will decide how much of the 2026 enterprise identity surface actually inherits the bargain -- and that, more than any further protocol work, is the story to watch over the next several years.

Who Decided This Token Is Good? A Field Guide to Conditional Access and Entra ID Protection

noreply@paragmali.com (Parag Mali) — Tue, 26 May 2026 00:00:00 GMT

**Conditional Access is Microsoft's Zero Trust policy engine, not a feature.** Every interactive sign-in to a licensed Microsoft 365 tenant flows through three planes: a signal plane (Entra ID Protection's machine-learning risk scoring), a policy plane (Conditional Access's JSON rule evaluator), and a session plane (Continuous Access Evaluation's event-driven revocation channel). This article assembles the wire format of all three -- the `riskDetection` resource on Microsoft Graph, the `conditionalAccessPolicy` schema, the `cp1` client capability that opts a client into 28-hour tokens, and the `401 + insufficient_claims` claims challenge -- into one end-to-end picture, then names the five things this architecture fundamentally cannot do.

1. Who decided this token is good?

It is 09:02 on a Tuesday in Lisbon. Alice opens Outlook on a managed laptop in a hotel and the reading pane populates with mail in under a second. She did not type a password. She did not approve a push. She did not touch a hardware key.

Who decided that was fine?

The question is harder than it looks. Alice's password lives in a token cache from yesterday's sign-in at the office. Outlook's client silently acquires a fresh access token from Entra. That request may match a Conditional Access policy. The policy may consult an Identity Protection risk score. The result is either an access token or a refusal. Exchange Online receives the token, validates it, and may yet revoke it mid-session because something changed in the last sixty seconds. Bytes return to Alice.

Microsoft Entra ID's policy engine for evaluating sign-in attempts. A Conditional Access policy is a JSON object that matches a set of users, cloud apps, and conditions (network location, device state, sign-in risk, user risk, client app, platform) against a set of grants (block, require MFA, require compliant device, require Authentication Strength, and so on). Policies are evaluated after first-factor authentication; a block grant in any matching policy overrides all allow grants [@ms-ca-overview]. The machine-learning signal plane that scores sign-ins and users for risk. ID Protection emits `riskDetection` events tagged with `riskEventType` (anonymized IP, leaked credentials, password spray, atypical travel, and roughly two dozen others), `riskLevel` (low, medium, high), `riskState`, and `detectionTimingType` (realtime, nearRealtime, or offline). Available only on Microsoft Entra ID P2 [@ms-id-protection-overview]. The session plane. CAE is an event-driven channel between Microsoft Entra and CAE-aware resource APIs (Exchange Online, SharePoint Online, Teams, Microsoft Graph). When a critical event fires -- account disabled, password reset, high user risk, network location change -- the resource API returns `HTTP 401` with a `WWW-Authenticate: Bearer error="insufficient_claims"` challenge. The client replays the embedded claims to Entra and acquires a fresh token. In exchange for this channel, CAE tokens live up to 28 hours [@ms-cae-concept].

Every component in this chain is individually documented on Microsoft Learn. The Conditional Access policy schema is on the Graph reference [@ms-graph-capolicy]. The riskDetection resource is on the Graph reference too [@ms-graph-riskdetection]. The cp1 client capability is in the claims-challenge document [@ms-claims-challenge]. The "up to 15 minutes" propagation ceiling for CAE non-IP events is in the CAE concept document [@ms-cae-concept].

But the chain is not assembled anywhere. That is what this article does.

This article is for the architect or the detection engineer who already knows what a JWT is, what a service principal is, and what an MDM does. If you have ever stared at a Sign-in log entry that reads "Conditional Access: Success" and wondered what exactly the policy engine concluded, this is for you.

Three moments of insight are coming. First, why MFA without context fails not because MFA is weak but because the unit is wrong (Section 3). Second, why the architectural breakthrough was a separation and not a new algorithm (Section 5). Third, why the system has limits that no engineering will fix (Section 8).

How did the industry end up with a token-issuance and claims-challenge model? The answer begins in 1975, with a paper that did not mention identity once.

2. From perimeter to identity boundary

In September 1975, Jerome Saltzer and Michael Schroeder published an eight-principle paper on operating-system protection that nobody at MIT thought of as a paper about cloud identity [@saltzer-schroeder-1975]. Half a century later, two of those eight -- complete mediation and least privilege -- are the implicit theorems every Conditional Access policy evaluates against. Where did the industry go in between?

Saltzer and Schroeder: the unstated theorems

Complete mediation says "every access to every object must be checked for authority." Least privilege says "every program and every user of the system should operate using the least set of privileges necessary to complete the job." These are stated as design principles, not theorems. But they function as theorems for anyone building an access-control system: violate either of them and you have, by construction, a vulnerability. Conditional Access does not derive the principles. It re-states them as a JSON schema and a runtime evaluator.

Jericho Forum: the perimeter dissolves

In 2003, David Lacey of the Royal Mail and a loose affiliation of corporate CISOs began arguing, against the prevailing castle-and-moat consensus, that the corporate network perimeter could no longer be relied on as the trust boundary. The Jericho Forum formally launched under the Open Group umbrella in January 2004 [@wikipedia-jericho-forum]. They coined the term "de-perimeterisation" to describe what their member firms were already living: data and identity travelling outside the firewall faster than the firewall could be moved.

Microsoft's own retrospective puts the quote precisely: the Jericho Forum "promoted a new concept of security called de-perimeterisation that focused on how to protect enterprise data flowing in and out of your enterprise network boundary instead of striving to convince users and the business to keep it on the corporate network" [@simos-2020-jericho]. The first sentence of Microsoft Learn's CA overview today is a direct descendant: "modern security extends beyond an organization's network perimeter" [@ms-ca-overview].

Kindervag: the name

John Kindervag, then a principal analyst at Forrester Research, gave the model its marketable name in a September 2010 report titled "No More Chewy Centers: Introducing the Zero Trust Model of Information Security" [@kindervag-2010-zero-trust]. Three tenets: all resources are accessed securely regardless of location; access control is on strict need-to-know and strictly enforced; all traffic is inspected and logged.

The label stuck. Microsoft Learn now calls CA "Microsoft's Zero Trust policy engine" in its first sentence [@ms-ca-overview]. The lineage from Kindervag's 14-page Forrester report to that sentence is direct.

The original Kindervag PDF is gated behind Forrester's paywall. The widely cited copy on ndm.net redirects to an unrelated managed-IT-services company; the only reliably accessible mirror is the Wayback Machine snapshot. Treat the lineage as well documented and the URL as a curiosity of how academic ideas survive the open web.

BeyondCorp: the alternative

In December 2014, Rory Ward and Betsy Beyer published "BeyondCorp: A New Approach to Enterprise Security" in USENIX ;login: [@ward-beyer-2014-beyondcorp]. The paper described Google's internal Zero Trust deployment: every request authenticated and authorized by an access proxy, no implicit network trust, device inventory and user identity as the inputs to access decisions. A follow-up in 2016 documented the production rollout [@osborn-2016-beyondcorp].

This is the architectural fork Section 7 returns to. BeyondCorp puts the policy engine in the data path, as a reverse proxy that sees every HTTP request. CA puts the policy engine at token issuance and re-evaluates via claims challenges. Both work. They are not interchangeable.

NIST SP 800-207: the vocabulary

In August 2020, NIST published Special Publication 800-207, Zero Trust Architecture [@nist-sp-800-207-2020]. It codified the U.S. federal reference architecture: a Policy Engine that decides, a Policy Administrator that effects the decision, and a Policy Enforcement Point that intercepts the access.

That trio is the vocabulary the Microsoft Learn CA documentation now uses. In the SP 800-207 mapping, Conditional Access is the Policy Engine and Policy Administrator; Exchange Online, SharePoint Online, Teams, and Microsoft Graph are the Policy Enforcement Points; Entra ID Protection is the trust algorithm that feeds the Policy Engine.

If you ever have to map Conditional Access to SP 800-207 for a compliance review, the cleanest correspondences are: PE = the CA evaluator inside Entra; PA = Entra's token issuer (because the decision is effected by issuing or refusing a token); PEP = the resource API (Exchange, SharePoint, Graph) that validates the token, plus, for CAE-aware resources, the same API enforcing claims-challenge revocation mid-session. ID Protection is the "trust algorithm" input to the PE.

The doctrine was settled by 2020. But Microsoft had already been trying to build a perimeter on identity for six years, starting in 2014 with a much smaller idea.

3. Per-user MFA and the limits of binary controls

In 2014, Microsoft's only cloud-era access control was a per-user toggle that said MFA: yes or MFA: no. The toggle worked. It was a real improvement over passwords alone. It also produced the most exploited security failure of the next decade: MFA fatigue [@weinert-2023-managed-policies].

How does a control improve security and create a new attack class at the same time?

The per-user MFA state machine

Per-user MFA lives on the user object as a tri-state: Disabled, Enabled, or Enforced. Microsoft Learn now says the quiet part out loud: "The best way to protect users with Microsoft Entra MFA is to create a Conditional Access policy" and "Don't enable or enforce per-user Microsoft Entra multifactor authentication if you use Conditional Access policies" [@ms-howto-mfa-userstates]. That guidance carries a generation of operational pain inside it. Mixing the two surfaces, in practice, produces unpredictable prompts: a CA policy says "no MFA required for this location," the per-user state says "always MFA," and the user gets prompted twice.

Note: Microsoft's explicit guidance is to pick one surface. If you have Entra ID P1 or higher, use Conditional Access. The per-user state should remain Disabled for those accounts. Mixed configurations produce both false-positive prompts and, occasionally, false-negative skips [@ms-howto-mfa-userstates].

Trusted IP rules: one-dimensional context

Office 365 added a second knob in the same era: "trusted IPs." Sign-ins from a configured public IP range would skip the MFA challenge [@ms-ca-network]. The idea was that "on the corporate network" meant "more trustworthy." This was reasonable in 2014. By 2017, it was already eroded by full-tunnel VPNs (every employee egresses through the corporate /16 from home), split-tunnel VPNs (some traffic does, some does not), and the realisation that "corporate network" had stopped being a useful synonym for "trusted." Trusted IP is one-dimensional context, and one dimension was not enough.

Security Defaults: the Free-SKU descendant

Since 22 October 2019, every new Entra ID tenant has Security Defaults turned on by default at creation [@ms-security-defaults]. Security Defaults is a tenant-wide on/off switch that requires MFA for all admin roles, MFA for users when they show risk, blocks legacy authentication, and forces MFA registration. Microsoft's number on the impact is striking: "more than 99.9% of those common identity-related attacks are stopped by using multifactor authentication and blocking legacy authentication" [@ms-security-defaults].

For Entra ID Free tenants in 2026, Security Defaults is still the only available baseline. There is no per-app policy, no per-risk gating, no Conditional Access. This is the licensing reality Section 10 returns to.

Active Directory Federation Services -- AD FS -- is the on-prem federation product that ran the access-control story before any of this. It is still operational in many tenants. It is no longer Microsoft's strategic identity provider; the Microsoft Learn AD FS overview now opens with the explicit guidance "Instead of upgrading to the latest version of AD FS, Microsoft highly recommends migrating to Microsoft Entra ID" [@ms-ad-fs-overview]. AD FS claim rules functioned as a kind of policy engine, but they evaluated only at federation time and they had no concept of risk.

The four failure modes of the binary toggle

The first-generation controls -- per-user MFA, trusted IPs, Security Defaults -- share four documented limits:

No expression of context. The toggle is either on or off. It cannot say "MFA from a new country but not from the office."
Trusted IP is thin context. A public IP range is one bit of information; modern attacks include matching network egress.
No per-app policy. The toggle applies to all apps the user accesses. You cannot say "MFA for the admin portal, not for Outlook."
No exclusion semantics for break-glass accounts. Emergency-access accounts need to be reachable when everything else has failed. The binary toggle either includes them or excludes them; it does not let you say "exclude these accounts but log every sign-in as a high-priority alert."

MFA fatigue: when a control becomes a credential

The canonical failure of the binary toggle is push-bombing. The attacker has the password. The system requires MFA. The user gets four "approve sign-in?" notifications during a morning meeting. One gets a thumbs-up by reflex. The system did exactly what it was configured to do.

The attack works because the control has no concept of whether this is a normal sign-in. The same flow runs whether the request originates from the user's office WiFi or an anonymizing proxy in another country. The MFA challenge carries no risk-weighted information; the user has no signal that this prompt is different from yesterday's prompt. Fatigue is the consequence. Microsoft's own Entra blog catalogued the attack pattern and the operational mitigations in the wake of the 2022 incident cluster [@ms-techcom-mfa-fatigue].

Focusing on password rules, rather than things that can really help -- like multi-factor authentication (MFA), or great threat detection -- is just a distraction. -- Alex Weinert, Microsoft Identity, July 2019 [@weinert-2019-password]

Weinert's 2019 piece is now infamous in the identity community for its title alone -- "Your Pa$$word doesn't matter." The argument was that a password's composition rules carry no information that helps the system tell a real user from an attacker; what does carry information is context. The system needed a place to put that context.

If MFA yes/no cannot express context, the next step is obvious: make context the input. But to make context the input, the system needs a place to put it. The history of CA from 2015 forward is the history of giving context a home.

4. Generation by generation

The next eight years produced six generations of access control, each one closing a specific failure of the previous one. They look like product launches in a marketing chronology. They are something more interesting: a sequence of negative results, each followed by a positive engineering response.

timeline title Conditional Access timeline 2014 : Gen 1 per-user MFA and trusted IPs 2015 : CA enters public preview 2016 : Gen 2 Conditional Access general availability 2016 : ID Protection enters preview 2018 : Gen 3 risk-based CA conditions broadly available 2020 : CAE enters preview 2022 : Gen 4 Continuous Access Evaluation general availability 2023 : Gen 5 CA for workload identities 2023 : Gen 6 Microsoft-managed policies and Authentication Strengths 2026 : CA for AI agent identities

The 2026 milestone -- Conditional Access for AI agent identities -- is itself still emerging; Microsoft's current framing in the Conditional Access Optimization Agent announcement names it explicitly as a frontier rather than a finished generation [@ms-techcom-ca-optimization-agent]. Section 9.1 returns to the open problems.

Gen 1 (2014 to 2016): per-user MFA

Documented in Section 3. The control has no concept of context. The failure motivates Gen 2.

Gen 2 (September 2016 GA): Conditional Access with static rules

The September 27, 2016 CloudBlogs post announcing CA general availability framed it as "Protect your data at the front door" -- the "front door" framing that Microsoft documentation still uses [@ms-techcom-ca-frontdoor-2016]. The policy schema (users + cloud apps + conditions to grants) was introduced in the 2015 preview [@ms-techcom-ca-preview-2015] and survived essentially unchanged into 2016 GA.

Gen 2 closed Gen 1's failure mode: context now had a home. A policy could match on network location, on the app being accessed, on the user's group membership, on the device platform. It could express "block country X" or "require MFA when not on the corporate network."

The remaining documented limit: no risk feed. The engine could express what to check for but not whether this specific sign-in looks suspicious. A policy could block credential-stuffing attempts only if you happened to know in advance which IPs to deny. Motivated Gen 3.

Gen 3 (2017 to 2018): risk-based fusion

Identity Protection had been generating risk signals since its March 2016 preview. Through 2017 and 2018, two new condition keys appeared in the CA policy schema: signInRiskLevels and userRiskLevels. Both take values from the set low, medium, high. The risk feed plugged into the policy plane through exactly two keys. The legacy ID-Protection-side risk policies (which were a parallel policy surface inside ID Protection itself) are now retiring on 1 October 2026; the canonical surface is CA [@ms-id-protection-policies].

The remaining limit: pre-issuance only. The CA evaluator runs at sign-in time. Once a token is issued, the policy plane has no way to undo the decision until the token expires. Microsoft's own retrospective is honest about what they tried first: "Microsoft experimented with the 'blunt object' approach of reduced token lifetimes but found they degrade user experiences and reliability without eliminating risks" [@ms-cae-concept]. A one-hour token cuts the worst-case revocation latency to an hour, but it also means a user with intermittent connectivity gets prompted every hour, and a mobile app with retry storms can hammer the IdP. The trade-off was unacceptable. Motivated Gen 4.

Gen 4 (January 2022 GA): Continuous Access Evaluation

CAE inverted the trade-off. Instead of shortening the token, lengthen it -- up to 28 hours [@ms-cae-concept]. Then add a side channel: when a critical event fires (account disabled, password reset, high user risk, IP location change), the resource API issues an HTTP 401 with a WWW-Authenticate claims challenge, and the client replays to Entra for a fresh token. Latency on the side channel is bounded: "up to 15 minutes" for non-IP events, "instant" for IP locations [@ms-cae-concept]. CAE was tied to an emerging open standard from day one, the OpenID Continuous Access Evaluation Profile [@ms-cae-concept]. The general-availability announcement landed on 10 January 2022 [@ms-techcom-cae-ga-2022].

Remaining limit: applies to humans only. Service principals do not consume CAE-aware client libraries; they cannot perform a claims challenge. Motivated Gen 5.

Gen 5 (2023 GA): Conditional Access for workload identities

Same engine, constrained grant set. The Microsoft Learn page is blunt on the boundaries: "Workload Identities Premium licenses are required" and the constraint set is unusual -- "Policy can be applied to single tenant service principals that are registered in your tenant. Microsoft and third-party SaaS applications, including multitenant apps, are not covered by these policies. Managed identities aren't covered by policy" and "Under Grant, Block access is the only available option" [@ms-workload-identity-ca]. The public preview of CA filters for workload identities opened on 26 October 2022 [@vansurksum-2022-workload-ca]; the Microsoft Entra Workload Identities standalone product followed in late November 2022, and the Conditional Access feature for workload identities itself reached general availability later in 2023.

The single-tenant restriction is a structural choice. Multi-tenant SaaS apps appear in many tenants' service principal directories at once; policy scoping on them would require a cross-tenant resolution protocol the engine does not have. Managed identities are excluded because they belong to Azure subscriptions, not to user identity, and Microsoft has chosen not to extend the surface there. Group assignments do not work either: "Conditional Access policies assigned to a group that contains a service principal are not enforced for that service principal" [@ms-workload-identity-ca].

Remaining limit: under-configured in most tenants because the grant taxonomy is so narrow that admins do not see immediate value. Motivated Gen 6.

Gen 6 (November 2023 onwards): Microsoft-managed policies and Authentication Strengths

In November 2023, Alex Weinert announced Microsoft-managed Conditional Access policies: a set of baselines that Microsoft would auto-deploy into tenants in Report-only mode and then auto-enable after a waiting period [@weinert-2023-managed-policies]. The launch announcement specified a 90-day window [@helpnet-2023-microsoft-entra-policies]. The current Microsoft Learn documentation specifies "Microsoft enables these policies no less than 45 days after they're introduced in your tenant if they're left in the Report-only state" with a 28-day pre-enablement notification [@ms-managed-policies].

The window shrank deliberately. The 90-day window in the 2023 launch announcement was a calibration window; the 45-day window in current documentation is the post-calibration setting. Both numbers are correct in their respective time frames. The article uses the current number throughout.

Parallel to the managed policies, Microsoft shipped Authentication Strengths -- a named bundle of acceptable authentication methods that can be required as a grant. The three built-in strengths are MFA strength, Passwordless MFA strength, and Phishing-resistant MFA strength (FIDO2 security key, Windows Hello for Business, multifactor certificate-based authentication) [@ms-auth-strengths]. The phishing-resistant strength is the modern way to express "no adversary-in-the-middle phishing kit should be able to defeat this grant."

The pattern: extension, not replacement

From Gen 3 onward, each generation extends the prior schema rather than replacing it. The conditionalAccessPolicy JSON shape that shipped in 2016 still drives the engine in 2026 -- with new condition keys added, new grant types added, new session controls added. By the standards of cloud control surfaces, that is a long run without a rewrite.

The reason is the architectural decision the next section is about.

5. The two-plane separation

The breakthrough is not a model, not a token format, not a wire protocol. It is a separation: the signal plane that produces risk detections from the policy plane that consumes them.

Stated like that, it sounds banal. Read it the other direction -- a policy engine whose risk model can change without changing the policy semantics, and whose policy can change without retraining the model -- and it is the design that makes the system maintainable at trillions of daily signals across hundreds of thousands of tenants.

The two planes, precisely

The signal plane is Microsoft Entra ID Protection. It runs detection logic on every interactive sign-in (and, for offline detections, on historical sign-ins) and emits a riskDetection resource into a per-tenant log on Microsoft Graph at /identityProtection/riskDetections. Each detection carries five fields you care about: riskEventType (one of about two dozen named detection types like anonymizedIPAddress, leakedCredentials, unlikelyTravel), riskLevel (low, medium, high, plus the bookkeeping values hidden and none), riskState (atRisk, confirmedCompromised, dismissed, remediated), detectionTimingType (realtime, nearRealtime, offline), and additionalInfo (a JSON blob with user-agent, IP, alert URL, reason codes) [@ms-graph-riskdetection][@ms-id-protection-risks].

The policy plane is Conditional Access. It is a JSON object at /identity/conditionalAccess/policies/{id} on the Graph API [@ms-graph-capolicy]. Each policy has displayName, state (enabled, disabled, enabledForReportingButNotEnforced), conditions, grantControls, and sessionControls. The conditions block contains the per-policy targeting: which users, which apps, which platforms, which network locations -- and two condition keys named signInRiskLevels and userRiskLevels.

**Sign-in risk** is a per-sign-in probability that the credential being used is being used by someone other than the legitimate owner *at this moment*. **User risk** is a per-user probability that the account itself has been compromised over its recent history. A user with leaked credentials in a breach corpus carries persistent user risk until the password is reset; a user signing in from an anonymizing proxy carries sign-in risk for that session. CA policies can match on either, both, or neither. Risk-based conditions require Entra ID P2 [@ms-id-protection-policies].

Those two condition keys -- signInRiskLevels and userRiskLevels -- are the entire API surface between the signal plane and the policy plane. Everything else about ID Protection is hidden behind them. The policy plane does not know whether high came from a transformer or a logistic regression or a hardcoded rule. The signal plane does not know which policies will read its output. The contract is two strings.

flowchart LR subgraph SP[Signal plane Entra ID Protection] DET[Detection pipeline] RD[(riskDetection log)] RL[Risk level low medium high] end subgraph PP[Policy plane Conditional Access] EV[Policy evaluator] POL[(conditionalAccessPolicy JSON)] TOK[Token issuer] end subgraph SES[Session plane CAE] CH[Critical event channel] RP[Resource API] end DET --> RD DET --> RL RL -. signInRiskLevels userRiskLevels .-> EV POL --> EV EV --> TOK TOK -- access token --> RP DET -. user risk events .-> CH CH -. 401 insufficient claims .-> RP

Why the separation matters

Three concrete consequences fall out of the design:

The risk model is re-trainable without policy rewrites. Microsoft's ID Protection team can change the underlying detection algorithm tomorrow. Add a new riskEventType. Replace the classifier for unlikelyTravel. Re-tune the threshold that maps a score to low/medium/high. None of these require tenants to rewrite their CA policies, because policies match on the level, not the signal.

Tenants without the licence simply do not use the risk conditions. An Entra ID P1 tenant can deploy CA policies that match on users, apps, locations, devices, client apps, and platforms. P2 unlocks the risk conditions. The schema accommodates both: P1 policies just leave the risk arrays empty. There is no parallel policy surface for the non-risk-aware tenants; they use the same engine.

CAE is a third plane layered onto the same skeleton. Continuous Access Evaluation did not require redesign of the policy plane. The CAE channel is a new event delivery mechanism; the events it propagates are things the signal plane already knew about (high user risk, password reset, account disabled) plus new ones the policy plane introduced (network-location-policy changed). The architecture absorbed CAE because the design was already a separation of concerns.

Key idea: The signal plane and the policy plane are separable; the contract between them is two condition keys (signInRiskLevels and userRiskLevels). That is what makes the system maintainable across a decade of evolution.

The "pit of success" framing

Alex Weinert calls this the "pit of success." His November 2023 piece on Microsoft-managed policies put the metric on it: a decade ago Microsoft turned on a "radical" tenant-wide policy requiring MFA for every consumer Microsoft account, and "today, 100 percent of consumer Microsoft accounts older than 60 days have multifactor authentication" [@weinert-2023-managed-policies].

The 100 percent number is achievable because the policy plane and the signal plane can each evolve independently. Microsoft can ship a managed policy that says "require MFA for high-risk sign-ins" without committing to a fixed definition of "high risk." The definition lives on the signal plane and changes weekly. The policy lives on the policy plane and is stable for years.

With the separation as the spine, the next section walks the end-to-end pipeline in one continuous trace, from signal to grant to token to session, on a real sign-in -- the trace no public Microsoft document assembles in one place.

6. The end-to-end pipeline

Take Alice's Tuesday morning from Section 1 and walk it forward. This section has six subsections. By the end of them, the question "who decided?" has six independently sourced answers and one combined picture.

6.1 What the signal plane sees

Identity Protection's detection taxonomy splits into five rough groups, based on what kind of information triggered the detection. The canonical taxonomy is the Microsoft Learn page on risk types [@ms-id-protection-risks]; the wire-format enum on the Graph schema is at [@ms-graph-riskdetection].

Network signals. anonymizedIPAddress, maliciousIPAddress, nationStateIP, riskyIPAddress. The signal is the source IP and reputation databases that ID Protection ingests.
Behavioural signals. unlikelyTravel, mcasImpossibleTravel, newCountry, unfamiliarFeatures, anomalousUserActivity. The signal is a deviation from the tenant's or the user's historical baseline.
Credential signals. leakedCredentials, passwordSpray. The signal is a match against a corpus of breached credentials or a velocity-based pattern across tenants.
Token and session signals. anomalousToken, tokenIssuerAnomaly, attemptedPrtAccess, attackerinTheMiddle, authenticatorPhishing. The signal is on the token itself or on the way the authenticator flow ran.
Inbox behaviour. suspiciousInboxForwarding, mcasSuspiciousInboxManipulationRules. The signal is on what happened after the sign-in -- a post-compromise indicator that retroactively flags the sign-in that enabled it.

Each detection is also tagged with a timing: real-time, near-real-time, or offline. Microsoft Learn is precise about the latencies: "Detections triggered in real-time take 5-10 minutes to surface details in the reports. Offline detections take up to 48 hours" [@ms-risk-detection-types].

The detection is mapped to a risk level, not a probability. Microsoft Learn calls the level "calculated by our machine learning algorithms" and explicitly notes the meaning: low/medium/high "represent how confident Microsoft is that one or more of the user's credentials are known by an unauthorized entity" [@ms-risk-detection-types]."Confidence" here is meant in the everyday sense, not the strict statistical sense of a confidence interval. Microsoft has not published a calibration study that would let you map a "high" risk level to a frequentist probability of compromise.

The figure you sometimes see in Microsoft marketing materials -- "more than 100 trillion signals processed per day" [@ms-managed-policies], or, in older sources, "78 trillion" [@ms-id-protection-overview] -- is the aggregate signal volume across all tenants and product surfaces, not per-sign-in features per user. The article keeps the two carefully separate.

Microsoft has not publicly disclosed the production model architecture, the feature vector size, or per-detection precision and recall. The 2021 Microsoft Security Blog interview with Maria Puertas Calvo describes the existence of the ML team and the operational scale ("hundreds of terabytes every day") but stops well short of architecture details [@ms-puertas-calvo-interview]. The model class is publicly unspecified; the taxonomy and the operating output are both public.

6.2 How risk surfaces

Two parallel logs matter for risk. The Sign-in log is the universe: every interactive and non-interactive sign-in produces an entry. The riskDetections log is the sparse overlay: a riskDetection is emitted only when a detection fires for the sign-in. Most sign-ins produce a Sign-in log entry with no corresponding riskDetection. Only flagged sign-ins do [@ms-graph-riskdetection].

This is a common source of confusion. It is tempting to assume "ID Protection scored every sign-in," and in a sense it did -- the detectors ran -- but the durable artefact exists only when at least one detector fired. To compute a per-sign-in distribution of risk you need to join the Sign-in log with the riskDetections log and treat the unjoined rows as "no risk flagged at the moment of issuance."

There is one more wrinkle. The detection taxonomy on the Microsoft Learn concept page and the riskEventType enum on the Graph schema are not perfectly aligned. The concept page lists mcasImpossibleTravel and authenticatorPhishing as named detection types; the Graph enum lists impossibleTravel (without the mcas prefix). The two surfaces sometimes use different value names for the same logical detection -- a UI display string versus a Graph enum value. Detection engineers writing KQL against the Sign-in logs should account for both.

6.3 How CA consumes risk

Conditional Access evaluation runs in a fixed order: assignments are checked first (does this sign-in match this policy at all?), then conditions (do all the condition predicates hold?), then grants (which controls are demanded?), then session controls (which token lifetime, sign-in frequency, persistent browser).

The key semantic, repeated across the Microsoft Learn documentation: a block grant in any policy matching the sign-in overrides any allow grant in any other policy. The policy plane is not just additive; it has an explicit precedence rule.

flowchart TD A[Sign-in request] --> B[First-factor auth] B --> C[Enumerate matching policies] C --> D{Any policy matches?} D -- No --> E[Default allow with token] D -- Yes --> F[Evaluate conditions per policy] F --> G{Block grant in any match?} G -- Yes --> H[Deny access return error] G -- No --> I[Aggregate required grants] I --> J{All grants satisfied?} J -- No --> K[Issue challenge MFA or device] J -- Yes --> L[Apply session controls] L --> M[Issue access token]

The pseudocode below is a compressed restatement of that flow. It is not Microsoft source code; it is the algorithmic shape an admin should keep in their head when reading a policy or debugging a sign-in.

{` function evaluate(signin) { const matching = allPolicies.filter(p => p.state !== 'disabled' && matchesAssignments(p.conditions, signin) && matchesConditions(p.conditions, signin) );

// Block precedence: any block grant wins if (matching.some(p => p.grantControls.builtInControls.includes('block'))) { return { decision: 'DENY', reason: 'block grant matched' }; }

// Aggregate required grants across matching policies const requiredGrants = new Set(); for (const p of matching) { for (const g of p.grantControls.builtInControls) requiredGrants.add(g); if (p.grantControls.authenticationStrength) { requiredGrants.add('authStrength:' + p.grantControls.authenticationStrength.id); } }

const satisfied = [...requiredGrants].every(g => signin.satisfies(g)); if (!satisfied) { return { decision: 'CHALLENGE', missing: [...requiredGrants].filter(g => !signin.satisfies(g)) }; }

// Apply session controls (token lifetime, sign-in frequency, persistent browser) const session = mergeSessionControls(matching.map(p => p.sessionControls)); return { decision: 'ALLOW', session }; }

const result = evaluate({ user: 'alice@contoso.com', app: 'Office365 Exchange Online', location: { ip: '203.0.113.42', country: 'PT' }, device: { compliant: true, joinType: 'Entra' }, signInRisk: 'low', userRisk: 'none', satisfies(grant) { const mfa = ['mfa', 'authStrength:phishingResistantMfa']; return mfa.includes(grant) || grant === 'compliantDevice'; }, }); console.log(JSON.stringify(result, null, 2)); `}

Risk-based conditions require Entra ID P2 [@ms-id-protection-overview]. Without that licence, the signInRiskLevels and userRiskLevels arrays in a policy are ignored. The rest of the engine works the same.

6.4 The grants

Each policy declares a set of grants. The grants are additive within a policy (all required to satisfy the policy) but the block grant in any matching policy takes precedence over allow grants in any other policy. Here are the grants currently in the schema:

Grant	What it requires	Notes
`block`	Deny access.	Always wins against allow grants.
`mfa`	Any MFA method registered for the user.	The legacy generic-MFA grant; replaced in modern deployments by Authentication Strength.
`requireAuthenticationStrength`	A named bundle of acceptable methods.	The modern grant. Built-in strengths include phishing-resistant [@ms-auth-strengths].
`compliantDevice`	The device record has `isCompliant: true`.	Set by Intune or a third-party compliance partner.
`domainJoinedDevice`	Hybrid Azure AD joined device.	Requires Entra Connect on-prem trust.
`approvedApplication`	Use an approved client app.	A small allow-list of Microsoft mobile apps.
`compliantApplication`	An app under an Intune App Protection Policy.	Mobile app management.
`passwordChange`	User must change their password.	Used for password-leaked recovery.
`requireTermsOfUse`	User must accept a terms-of-use document.	Used for compliance and guest scenarios.

A named, ordered bundle of acceptable authentication methods that a CA grant can demand. The three built-in strengths are *MFA strength* (any registered second factor), *Passwordless MFA strength* (no password used), and *Phishing-resistant MFA strength* (FIDO2 security key, Windows Hello for Business or a platform credential, or multifactor certificate-based authentication) [@ms-auth-strengths]. The phishing-resistant strength is the canonical modern grant for high-value access.

The Authentication Strength grant is where the phishing-resistance story lives in 2026. A policy that demands the phishing-resistant strength refuses to accept TOTP or SMS or push as the second factor. Only credentials with cryptographic binding to the device or hardware token will satisfy the grant. That class of credential, by construction, cannot be replayed by an adversary-in-the-middle phishing kit -- because the underlying WebAuthn ceremony is bound to the origin of the relying party.

6.5 The Windows-side handoff

PRT issuance is an interactive sign-in. It goes through CA like any other.

A long-lived refresh token issued to a Windows session at user sign-in to Entra-joined or hybrid-Entra-joined devices. The PRT is bound to the device's TPM where one is available, and it grants the user single sign-on to all CA-targeted apps from that Windows session. Issuance is subject to CA evaluation; if a CA policy demands compliant device, the device must already be marked `isCompliant` before the PRT is issued.

The compliance state lands on the device object as isCompliant. Intune (or a third-party MDM through Intune's compliance-partner API) writes that field after evaluating the device against a compliance policy: disk encrypted, OS patched, antivirus running, jailbreak detection clean, and so on. CA reads it on subsequent policy evaluations. If a policy requires compliantDevice and the device object says isCompliant: false, the grant is not satisfied.

The operational seam to on-prem Active Directory runs the other direction. Kerberos and NTLM against on-prem domain controllers never consult Entra. The Microsoft Learn CA overview is explicit: CA is a cloud control plane; on-prem authentication is outside its scope [@ms-ca-overview]. This is the limit Section 8 will name precisely.

6.6 CAE in session

The third plane. Wire format lives in two Microsoft Learn pages: the claims-challenge page [@ms-claims-challenge] and the app-resilience CAE page [@ms-app-resilience-cae].

A client opts in to CAE by advertising the cp1 capability via the xms_cc claim in token requests. In MSAL, that opt-in looks like WithClientCapabilities(new[] { "cp1" }) [@ms-app-resilience-cae]. The Microsoft Learn claims-challenge page says it cleanly: "The only currently known value is cp1" [@ms-claims-challenge].

When the policy plane sees a critical event after the token was issued, the resource API responds to the next call with HTTP 401 Unauthorized and a WWW-Authenticate header of the shape:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer authorization_uri="<entra-authorize-endpoint>", error="insufficient_claims", claims="<base64-encoded JSON>"

The claims value is a base64-encoded JSON object that the client passes verbatim to the token endpoint when acquiring a fresh token [@ms-claims-challenge][@ms-app-resilience-cae]. The IdP evaluates the embedded claims, runs CA again with the new context, and issues a new token (or refuses).

The HTTP wire format CAE uses to revoke a session mid-flight. A CAE-aware resource API returns `HTTP 401` with `WWW-Authenticate: Bearer error="insufficient_claims", claims=""`. The client replays the base64 blob to Entra; Entra re-runs CA with the new context; the client receives a fresh token or a definitive refusal. The wire format is documented at [@ms-claims-challenge] and demonstrated at [@ms-app-resilience-cae].

Note: The CAE-aware capability is signalled by the client, not by the token. The client advertises cp1 via xms_cc; the token's CAE-awareness shows up as its lifetime (up to 28 hours) and the resource API's willingness to issue a claims challenge. Folk knowledge that says "look for a cae claim in the JWT" is incorrect.

The Microsoft Learn CAE document enumerates five critical events: account disabled or deleted, password change or reset, MFA enabled by an administrator, administrator token revocation, and high user risk detected by ID Protection [@ms-cae-concept]. A parallel pathway, Conditional Access policy evaluation, propagates network-location and policy changes to CAE-aware resource providers on the same channel. For IP-location changes the latency is "instant"; for everything else the ceiling is up to 15 minutes [@ms-cae-concept].

sequenceDiagram participant C as Client app participant R as Resource API CAE aware participant E as Entra token issuer participant P as ID Protection Note over C: Client holds long-lived CAE token C->>R: GET messages with bearer token R->>R: Token still cryptographically valid P->>E: High user risk event for Alice E->>R: Push critical event Alice high risk C->>R: GET messages with bearer token again R->>C: 401 WWW-Authenticate insufficient_claims claims base64 C->>E: Token request with claims blob and cp1 capability E->>E: Re-run CA with new context E-->>C: New token or definitive refusal C->>R: Retry with new token

{` // Simplified MSAL.js-shaped pseudocode for CAE opt-in and challenge handling const ENTRA_AUTHORITY = ''; const EXCHANGE_ENDPOINT = ''; const MAIL_READ_SCOPE = '';

const msal = new PublicClientApplication({ auth: { clientId: '', authority: ENTRA_AUTHORITY }, });

async function callExchange() { let token = await msal.acquireTokenSilent({ scopes: [MAIL_READ_SCOPE], clientCapabilities: ['cp1'], // advertise CAE awareness });

let res = await fetch(EXCHANGE_ENDPOINT, { headers: { Authorization: 'Bearer ' + token.accessToken }, });

if (res.status === 401) { const header = res.headers.get('WWW-Authenticate') || ''; const m = /claims="([^"]+)"/.exec(header); if (m) { // Replay the embedded claims to acquire a fresh token token = await msal.acquireTokenSilent({ scopes: [MAIL_READ_SCOPE], claims: Buffer.from(m[1], 'base64').toString('utf8'), clientCapabilities: ['cp1'], }); res = await fetch(EXCHANGE_ENDPOINT, { headers: { Authorization: 'Bearer ' + token.accessToken }, }); } }

console.log('HTTP', res.status); }

callExchange(); `}

Key idea: CAE inverts the conventional trade-off: lengthen the token, shorten the revocation. The token can live 28 hours because revocation is an event, not a clock.

The chain is now visible. The signal plane scored Alice's Tuesday sign-in. The policy plane evaluated the policies. The token issuer issued an access token (CAE-aware because Outlook advertises cp1). Exchange Online accepted the token and returned mail. If, twelve minutes from now, Alice's account is flagged high risk because a different sign-in attempt fires leakedCredentials, the critical event will fire, Exchange will issue a claims challenge, and Outlook will either acquire a fresh token (passing the new CA evaluation) or surface the refusal to the user.

Six independent components co-decided on one access event. Microsoft is one vendor. The same problem has been solved differently by Google, Okta, AWS, Cloudflare, and Zscaler. The Microsoft answer is not the only correct answer.

7. How others do it

Microsoft chose to enforce at token issuance and claims challenge. Google chose to enforce at every HTTP request via a reverse proxy. AWS chose a decidable policy DSL. These are not minor variations; they are different answers to "where does the policy engine live in the data path?"

Both Microsoft's and Google's models scale. Neither is strictly better. The choice is a function of what the enterprise already runs.

Google BeyondCorp, IAP, Chrome Enterprise Premium

Google's Identity-Aware Proxy puts the policy engine in the data path. The documentation calls it bluntly: "IAP lets you establish a central authorization layer for applications accessed by HTTPS, so you can use an application-level access control model instead of relying on network-level firewalls" [@google-iap]. Every HTTP request to an IAP-protected app passes through the proxy. The proxy authenticates the user (via Google Account, Workforce Identity Federation, or Identity Platform), evaluates a Common Expression Language policy against the request context, and -- on allow -- forwards the request to the backend with signed identity headers.

The BeyondCorp Enterprise product (recently rebranded as Chrome Enterprise Premium) layers context-aware access on top: device posture, geographic location, time of day [@google-bce-overview]. The architecture matches the 2014 USENIX paper [@ward-beyer-2014-beyondcorp] and the 2016 production follow-up [@osborn-2016-beyondcorp].

The strength is per-request authorization: every HTTP call is its own decision point. The weakness, from the M365 perspective, is that IAP does not gate Microsoft 365 first-party API traffic. The Outlook client does not route through Google's IAP; it routes through Entra and Exchange Online. For Microsoft 365 workloads, IAP is complementary at best.

Okta Identity Engine and ThreatInsight

Okta's policy engine is closer to Microsoft's structurally: the identity provider is the policy engine, app sign-on policies live on the IdP, and the resource side relies on the IdP's token rather than a per-request proxy. The Okta Identity Engine documents the rule shape: "App sign-in policies define how a user must authenticate to gain access to an app. They verify ... group membership, the IP zone they're signing in from, risk level, and others" [@okta-sign-on-policies]. Every new app gets a default policy with a single catch-all rule that allows access with two factors.

Okta ThreatInsight is the IP-reputation feed. The documentation describes it operationally: "Okta ThreatInsight aggregates data about sign-in activity across the Okta customer base to analyze and detect potentially malicious IP addresses ... password spraying, credential stuffing, brute-force cryptographic attacks" [@okta-threatinsight]. The signal coverage is narrower than ID Protection: ThreatInsight is IP-centric, where ID Protection runs a multi-detection ML pipeline on tokens, sessions, behaviour, and credentials.

AWS IAM Identity Center and Verified Access

AWS splits the problem. IAM Identity Center handles workforce SSO and trusted identity propagation to AWS services [@aws-iam-identity-center]. AWS Verified Access handles per-request authorization for HTTPS-fronted apps -- the ZTNA piece. The Verified Access docs put it plainly: "Verified Access evaluates each application access request in real time" and "verifies the trustworthiness of users and devices against a set of security requirements" [@aws-verified-access].

The interesting bit is the policy language: Cedar. Cedar is a deliberately decidable language for authorization policy. "Decidable" here is a precise term: the safety question (will some policy edit, in some future edit chain, leak this right?) is answerable by a static analyser for any Cedar policy [@cedar-security].

Cedar's intentional non-Turing-completeness is the language-design hedge against the Harrison-Ruzzo-Ullman undecidability result the next section will name. The trade-off is expressiveness: Cedar cannot express arbitrary computational predicates, which is the price of being analysable [@cedar-security].

Cloudflare Access and Zscaler Private Access

Cloudflare Access is an edge proxy. Policies are deny-by-default, with four building blocks: Actions (Allow, Block, Bypass, Service Auth), Rule types (Include, Require, Exclude), Selectors, and Values [@cloudflare-access-policies]. The deny-by-default semantics are explicit: "Since Access is deny by default, users who do not match a Block policy will still be denied access unless they explicitly match an Allow policy" [@cloudflare-access-policies]. Cloudflare also ships a policy tester that lets administrators dry-run a policy against the existing user population [@cloudflare-access-policy-mgmt].

Zscaler Private Access is a broker-based ZTNA: the user connects to a Zscaler edge node, the broker establishes a connection to the private app, and "users never access the corporate network, and apps are never exposed to the public internet" [@zscaler-zpa]. Zscaler's own marketing surveys put the VPN-replacement framing in numbers: "91% of organizations are concerned that VPNs compromise their security" and "56% of organizations suffered one or more VPN-related attacks in 2023-2024" [@zscaler-zpa].

Architecturally, Cloudflare Access and ZPA both sit closer to BeyondCorp than to Microsoft CA: the policy engine is in the data path; the protected resource is fronted by the proxy rather than gated at token issuance.

OpenID Shared Signals Framework and CAEP

Not a competitor: the cross-vendor wire format for what Microsoft built into CAE. On 22 September 2025, the OpenID Foundation approved three Final Specifications: the Shared Signals Framework 1.0, the Continuous Access Evaluation Profile 1.0, and the Risk Incident Sharing and Coordination Profile 1.0 [@helpnet-2025-openid][@openid-caep-final]. CAEP defines five event types -- Session Revoked, Token Claims Change, Credential Change, Assurance Level Change, Device Compliance Change -- as the cross-vendor revocation vocabulary.

Microsoft's CAE implementation is, in Microsoft's own words, "an industry standard based on Open ID Continuous Access Evaluation Profile" [@ms-cae-concept]. The Final Specifications from September 2025 are the canonical post-2025 reference; older drafts at OpenID's site are superseded.

Head-to-head comparison

The differences worth memorising:

System	Enforcement point	Native risk feed	Post-issuance revocation	Gates M365 first-party?	Best suited for
Microsoft Entra CA + ID Protection + CAE	Token issuer + CAE-aware resource APIs	ID Protection ML pipeline	CAE up to 15 min, instant for IP	Yes	M365 tenants
Google IAP / Chrome Enterprise Premium	HTTPS reverse proxy	Context-aware access signals	Per-request (always re-decides)	No	Google Cloud workloads
Okta Identity Engine + ThreatInsight	IdP token issuance	ThreatInsight IP feed	Limited, IdP-dependent	No	Vendor-neutral front door
AWS IAM Identity Center + Verified Access	Verified Access proxy + IAM	Trust providers (third-party)	Per-request for Verified Access	No	AWS-hosted apps
Cloudflare Access	Edge proxy	Risk score + identity factors	Per-request	No	Public web apps
Zscaler Private Access	Broker / edge node	Posture + identity	Per-request	No	Private app access

Per-cell sourcing for the table: the Microsoft row's "Yes" cell on M365 first-party gating is the directly-stated claim from the Microsoft Learn CA overview [@ms-ca-overview]. The other rows' "No" cells are negative inferences drawn from each peer's own product documentation, none of which advertises Microsoft 365 first-party API gating: Google IAP gates HTTPS-fronted apps behind the proxy [@google-iap]; Cloudflare Access deny-by-default applies to the apps fronted by Cloudflare [@cloudflare-access-policies]; Verified Access "evaluates each application access request" for HTTPS apps behind AWS [@aws-verified-access]; Zscaler ZPA brokers private app access [@zscaler-zpa]; Okta sign-on policies gate apps wired into Okta's IdP [@okta-sign-on-policies]. The cell semantics are "does the system gate Outlook/Teams/SharePoint/Graph first-party traffic" and the answer is structurally No outside Microsoft.

flowchart LR subgraph TOK[Token issuance model Microsoft Okta] U1[User] --> AT[Acquire token] AT --> CA1[CA evaluator] CA1 --> IS[Issue token] IS --> R1[Resource API validates token] R1 -. CAE 401 .-> AT end subgraph PRX[Data path proxy model Google BeyondCorp AWS Verified Access Cloudflare Zscaler] U2[User] --> PXY[Proxy intercepts every request] PXY --> POL[Policy evaluator at the proxy] POL --> BCK[Backend application] end

The honest observation worth sitting with: none of the proxy systems gates M365 first-party API traffic. Outlook, Teams, SharePoint, and Microsoft Graph route through Entra. For those workloads, Entra remains the only effective policy plane. The proxy systems gate the apps that sit behind the proxy -- internal apps, partner-facing apps, custom workloads. That makes BeyondCorp, Okta, Cloudflare Access, and ZPA complementary to Entra CA in an M365 environment, not substitutes for it.

Six systems, six architectural choices. None of them wrong. But what do they all leave on the table?

8. What Conditional Access fundamentally cannot do

Section 7 cannot be the ending. There are at least five things Conditional Access -- and every peer in Section 7 -- cannot do. Some are engineering limits; some are theorems. Both classes are worth naming.

(a) On-prem authentication

CA is a cloud control plane. Kerberos and NTLM against on-prem domain controllers do not consult Entra. There is no policy hook for the legacy Windows protocols. If a domain user signs in to a domain-joined workstation, authenticates to a file server, and accesses a share, no piece of that flow touches Conditional Access. The Microsoft Learn overview is explicit about the scope [@ms-ca-overview].

This is the operational seam between cloud identity and on-prem identity. State it plainly; do not soften.

Note: Conditional Access does not gate Kerberos or NTLM against on-prem domain controllers. If your threat model includes lateral movement after credential theft on the on-prem side, CA is not your defence. Layer in Defender for Identity, on-prem MFA gateways, or a privileged-access workstation architecture instead.

(b) Post-issuance token theft

Once a refresh token is exfiltrated -- whether via an adversary-in-the-middle phishing kit like Evilginx [@ms-aitm-phishing-blog], an infostealer that scrapes the token cache, or a malicious browser extension -- the pre-issuance CA evaluation is bypassed. The attacker has a bearer token. They can present it to the resource API directly. CAE-aware resource providers can revoke mid-session on the published critical-event list, but the latency ceiling is "up to 15 minutes" for non-IP events [@ms-cae-concept]. In fifteen minutes a competent attacker has done plenty.

The mitigation is device-bound credentials: Primary Refresh Tokens bound to TPM hardware, FIDO2 with hardware attestation, certificate-based authentication with hardware-protected keys [@ms-prt-concept]. A bearer token bound to a TPM is not exfiltratable in the same way; the wrapped key material never leaves the device.

(c) Consent-grant phishing

CA evaluates authentication, not authorization grants that a user makes to a malicious OAuth app. A user who clicks "Allow" on a permissions-consent prompt for an attacker-controlled app has performed an OAuth authorization, not a sign-in. The malicious app now has the user's delegated permissions for whatever scopes were granted. CA was not invoked because CA gates the user's sign-ins; it does not inspect the user's OAuth grants. Microsoft Defender for Cloud Apps documents the attack class as "risky OAuth apps" and ships investigation and remediation tooling on a separate plane from CA [@ms-illicit-consent-grant].

Admin consent settings, app governance policies, and explicit allow-listing of acceptable publishers live on that different plane. The policy admin who deploys CA needs to deploy app governance separately.

(d) Risk evaluation is probabilistic

Identity Protection produces a score, not a proof. A "high" risk level is a confidence; it is not the assertion "this sign-in is definitely an attack." No vendor in the Section 7 survey publishes precision or recall numbers for its risk engine. The operating point -- the threshold that maps a continuous score to discrete buckets -- is a trade-off that the vendor calibrates and the customer does not see.

This is a structural lower bound on any ML-driven risk plane, not a Microsoft-specific failure. Any classifier has false positives and false negatives. A risk-aware CA policy that says "block at high risk" will, with non-zero probability, block a legitimate sign-in. A policy that says "require MFA at medium risk" will, with non-zero probability, let through a sophisticated attacker whose detections fall under the threshold.

(e) Workload-identity CA is constrained by design

Block-only grants. No managed identities. No group assignments. The full human grant taxonomy does not transfer because a service principal cannot perform an MFA challenge, cannot register a FIDO2 key, cannot accept a terms-of-use document. The Microsoft Learn page on workload-identity CA enumerates the constraints precisely [@ms-workload-identity-ca]. Section 9 will name this as an open problem; for now, treat it as a documented limit.

The theorems behind the limits

Some of these limits are engineering choices that could be different in a future product. Some are deeper.

Saltzer and Schroeder 1975 [@saltzer-schroeder-1975] give the upper bound on aspirations: complete mediation across every authentication and authorization decision within scope of mediation. The principle does not constrain what is in scope. It constrains what you must do for whatever you have decided is in scope. On-prem AD is out of scope for CA by Microsoft's product decision; complete mediation cannot fix that, because the principle is about consistency within the boundary, not about expanding the boundary.

Harrison-Ruzzo-Ullman 1976 -- usually shortened to HRU [@harrison-ruzzo-ullman-1976] -- gives the lower bound on static analysis. The safety question in the general access-matrix model is undecidable. In informal terms: there is no general algorithm that proves a Conditional Access policy edit cannot, under some future edit chain, leak a sensitive right. This is why every vendor in the survey relies on evaluation-time mediation (the engine decides at the moment of the request) rather than static-proof analysis (the engine certifies in advance that no edit can ever leak). Cedar's intentional restriction to a decidable fragment, in AWS Verified Access, is the counter-strategy: trade expressiveness for analysability.

The bearer-token revocation trade-off is informal but real: the worst-case revocation latency is bounded below by the token's natural lifetime, unless a side channel exists. CAE is that side channel. Its latency is bounded by the propagation time of the channel (up to 15 minutes for non-IP events, instant for IP). Shorten the channel further and you discover that the IdP-to-resource-API event delivery has its own infrastructure costs.

The practical implication of HRU for a CA admin is that there is no tool, anywhere, that can examine your tenant's CA policies and certify that no sequence of policy edits could ever leak access to a sensitive resource. Vendors offer policy *testers* that simulate a single edit against the current population; that is decidable. The question "is the system safe under all possible future edits?" is not. This is why audit trails, change-control gates, and least-privilege role assignments on the CA admin role matter as much as the CA policies themselves.

Naming the limits clears the way to name the active unsolved problems -- the ones the field is still working on, where the current state of the art admits it is partial.

9. Where the policy plane is still incomplete

Microsoft's own 2026 documentation for Conditional Access on AI agents calls the current implementation "a lightweight enforcement mechanism designed to block unauthorized or risky agents, not a full policy suite." That is not marketing modesty. It is an admission that the most active frontier of policy enforcement -- agent identities -- is deliberately under-specified.

Five open problems sit on that frontier in 2026.

Organizations are expanding Zero Trust across more users, applications, and now a growing population of AI agent identities ... the Conditional Access Optimization Agent moves beyond static guidance to continuous, context-aware identity posture optimization. [@ms-techcom-ca-optimization-agent]

9.1 Agent identity policy semantics

What grants should exist for AI agents beyond block and allow? Useful candidate grants include: "read-but-not-move" for mail or files; "business-hours-only"; "any autonomous action requires a fresh sign-off from the on-behalf-of human." None of these exist as first-class CA grant types in 2026.

What does exist: CA targeting of agent identities -- the ability to match a policy on the agent identity rather than the human -- and the Conditional Access Optimization Agent, which gives administrators continuous recommendations on policy posture [@ms-techcom-ca-optimization-agent]. The targeting is there. The grant taxonomy is still mostly the human one, applied imperfectly.

9.2 Cross-vendor CAEP interop

The wire format was finalised in September 2025 [@helpnet-2025-openid][@openid-caep-final]. Production receiver coverage outside Microsoft Entra-internal resource providers is partial. Two large vendors agreeing on an event schema is necessary but not sufficient for cross-vendor revocation to work in practice; the receiving side needs to act on the events. The next eighteen months are the period in which CAEP either becomes the cross-vendor wire format for revocation, or it does not.

9.3 Workload-identity grant set

What richer expressions could exist for non-human identities? The current Microsoft Learn page lists workload-identity detections: investigationsThreatIntelligence, suspiciousSignins, adminConfirmedServicePrincipalCompromised, leakedCredentials, maliciousApplication, suspiciousApplication, anomalousServicePrincipalActivity, suspiciousAPITraffic [@ms-workload-identity-risk]. The detections exist; the grant taxonomy stops at block.

Candidate richer grants: "workload attestation" (the service principal proves it is running on attested infrastructure), "verifiable claim from a trusted attester" (a third party signs a statement about the workload), "step-up authorization for sensitive scopes" (a higher-privilege scope requires a separate per-request authorization step). None of these is generally available in 2026.

A non-human identity in Entra ID: a service principal, an application registration's owned service principal, or a managed identity in Azure. Workload identities authenticate via client secrets, client certificates, federated credentials, or (for managed identities) instance-metadata-service tokens. Conditional Access for workload identities currently applies only to single-tenant service principals registered in the tenant; it does not cover multi-tenant SaaS apps or managed identities [@ms-workload-identity-ca].

9.4 The break-glass paradox

Emergency-access accounts must be excluded from CA. If a CA misconfiguration locks out every admin, the break-glass account is the recovery path. But exclusion creates a high-value bypass: an attacker who compromises a break-glass account inherits its exclusion.

There is no clean answer. Microsoft's guidance is exclusion plus FIDO2 binding plus alerting: the break-glass accounts have hardware-bound FIDO2 keys (so they cannot be phished), they are excluded from all CA policies (so misconfiguration cannot lock them out), and every sign-in is alerted on (so misuse is detected within minutes) [@ms-emergency-access].

Run two break-glass accounts, not one. Store the FIDO2 keys in separate physical safes under separate custodians. Never use them for anything but a recovery exercise once per quarter; if they sign in unexpectedly, treat the alert as a P1 incident. The operational pattern accepts that you have a bypass and treats the bypass as the highest-value alert in the tenant [@ms-emergency-access].

9.5 The risk-engine transparency problem

No vendor in the Section 7 survey publishes model architecture, feature vector size, or per-detection precision and recall. Microsoft does not. Okta does not. Google does not. Defenders, auditors, and regulators must accept a black-box score.

This matters in three places. First, for incident response: when an "atypical travel" detection fires for an executive, the responder cannot see which features contributed and how strongly. Second, for compliance: an auditor asked to evidence the effectiveness of the control plane gets the operating output (3-tier risk levels) but not a quantitative evaluation. Third, for the risk-engine vendors themselves, who must respond to legitimate regulatory questions about model bias and operational reliability without revealing the architecture that attackers would use to evade detection.

The article does not predict a resolution. It names the gap.

The architecture is incomplete by admission. It is also actionable today. A competent tenant administrator can deploy a sensible baseline in an afternoon.

10. Using Conditional Access today

The architectural story ends; the operational story begins. Here is what a competent tenant looks like in 2026.

The licensing reality

Conditional Access is not a feature every Microsoft 365 tenant gets. It is a feature gated by SKU. The licensing tiers are:

Entra ID Free. Security Defaults only [@ms-security-defaults]. No Conditional Access policies. No risk-based conditions. No CA-driven CAE (the critical-event-evaluation subsystem -- for events like account disable, password reset, and high user risk -- still propagates to CAE-aware M365 services at the service layer regardless of SKU; see Section 6.6) [@ms-cae-concept].
Entra ID P1. Conditional Access is unlocked [@ms-ca-overview]. You can author policies with any of the non-risk conditions: users, apps, locations, devices, client app, platform. You can demand any of the non-risk grants.
Entra ID P2. Adds risk-based conditions. signInRiskLevels and userRiskLevels become usable [@ms-id-protection-overview]. ID Protection's full report pane (risky users, risky sign-ins, risk detections) is accessible. The legacy ID-Protection-side risk policies retire 1 October 2026 [@ms-id-protection-policies].
Workload Identities Premium. A separate SKU. Unlocks CA scoped to service principals [@ms-workload-identity-ca].

This corrects a premise discarded earlier: "Conditional Access is the policy plane every M365 tenant runs on" is not true. Many tenants run on Security Defaults. The "policy plane every tenant runs on" is the cloud sign-in pipeline; CA is the configurable richer layer that P1+ tenants opt into.

Start with the managed baselines

Microsoft-managed Conditional Access policies are the recommended starting point [@ms-managed-policies]. They auto-deploy in Report-only mode, run for at least 45 days while administrators review the impact in the Sign-in logs, and are auto-enabled with a 28-day pre-enablement notification unless administrators opt out [@ms-managed-policies]. The currently shipping baselines, per Microsoft Learn, include:

MFA for admins accessing Microsoft admin portals (the most-privileged roles).
MFA for users who already have per-user MFA enabled (a migration aid).
MFA and reauthentication for risky sign-ins (the P2 baseline).
Block legacy authentication.
Block access for high-risk users (P2-tier protection on the user-risk surface).
Block all high-risk agents accessing all resources (Preview, AI-agent surface).

The original announcement called for a 90-day report-only window [@weinert-2023-managed-policies][@helpnet-2023-microsoft-entra-policies]. The current default is 45 days [@ms-managed-policies]; the window shrank as Microsoft gained confidence that customers were not surprised by the auto-enablement.

Five custom policies on top of the baselines

Beyond the managed policies, every well-run tenant in operational experience runs five custom policies on top of the baselines [@ms-ca-policy-common]: block legacy authentication unconditionally [@ms-managed-policies]; require the phishing-resistant Authentication Strength for any user in a privileged role [@ms-auth-strengths]; require compliantDevice for admin centres, finance apps, and customer-data exports [@ms-intune-compliance-partners]; restrict privileged sign-ins to a named-location allow-list with block-or-step-up outside it [@ms-ca-network]; and, where Entra ID P2 is licensed, demand a sign-in-risk-based step-up (MFA at high risk, a passwordless or phishing-resistant method at medium risk) [@ms-id-protection-policies].

Note: 1. Block legacy authentication. 2. Phishing-resistant Authentication Strength for admin roles. 3. Require compliant device for sensitive applications. 4. Named-location restrictions for privileged roles. 5. Sign-in-risk-based step-up where Entra ID P2 is available.

Automation entry points (Microsoft Graph)

The Graph endpoints administrators care about:

GET /identity/conditionalAccess/policies -- list policies. POST to create, PATCH to update [@ms-graph-capolicy].
GET /identityProtection/riskDetections -- the per-detection log. Filterable by riskLevel, riskState, userPrincipalName, activityDateTime [@ms-graph-riskdetection].
GET /identityProtection/riskyUsers -- the per-user risk view.

A policy authored in code looks like this (truncated for readability):

{
  "displayName": "Require phishing-resistant for admins",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": { "includeRoles": ["62e90394-69f5-4237-9190-012177145e10"] },
    "applications": { "includeApplications": ["All"] }
  },
  "grantControls": {
    "operator": "OR",
    "authenticationStrength": { "id": "00000000-0000-0000-0000-000000000004" }
  }
}

The recommended deployment dance is enabledForReportingButNotEnforced first; let the Sign-in log show you the impact for a calibration window; promote to enabled only after the report-only data matches expectations [@ms-ca-report-only].

Audit-time visibility

Three surfaces matter:

Sign-in logs in the Entra portal show the per-sign-in evaluation, including which CA policies matched and which grants were satisfied.
Risk-detection log in Identity Protection (P2 only) shows the per-detection narrative: which riskEventType fired, with what additionalInfo, against which user.
The What-If tool simulates a policy evaluation for a hypothetical sign-in, before you enable a policy.

Detection engineering

For E5 tenants, the Sign-in logs and risk detections flow into Microsoft Sentinel (via the Microsoft Entra ID connector) or Defender XDR [@ms-sentinel-aad-connector]. A KQL skeleton for high-risk-with-CA-failure looks like:

SigninLogs
| where ResultType != 0
| join kind=inner (AADRiskDetections | where RiskLevel == "high") on UserPrincipalName, CorrelationId
| project TimeGenerated, UserPrincipalName, IPAddress, ConditionalAccessStatus, RiskEventType, FailureReason

The aggregate scale figure is worth remembering: Microsoft processes "more than 100 trillion security signals" daily across all identity products [@ms-managed-policies]. The detection engineer is consuming a small slice that landed in their tenant.

Run the following in Microsoft Sentinel or the Entra advanced hunting blade to surface sign-ins that succeeded *despite* a high-confidence risk detection -- the most operationally interesting subset. The query is original to this article; the schema it targets is the canonical Microsoft Sentinel Entra ID connector tables `SigninLogs` and `AADRiskDetections` [@ms-sentinel-aad-connector], and the join-and-filter pattern follows the practice documented in Microsoft's Sentinel hunting guidance [@ms-sentinel-hunting].

let window = 7d;
SigninLogs
| where TimeGenerated > ago(window)
| where ResultType == 0
| where ConditionalAccessStatus == "success"
| join kind=inner (
    AADRiskDetections
    | where TimeGenerated > ago(window)
    | where RiskLevel == "high"
) on UserPrincipalName, CorrelationId
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, RiskEventType, ConditionalAccessPolicies
| order by TimeGenerated desc

The expected count for a well-tuned tenant is small. Spikes warrant a P2 investigation.

Break-glass

Two emergency-access accounts. FIDO2-bound. Excluded from every CA policy. Stored as separate hardware tokens in separate safes. Every sign-in is wired to a P1 alert. Per Section 9.4 and Microsoft Learn's emergency-access guidance, this is the acknowledged operational compromise to the break-glass paradox [@ms-emergency-access].

A non-personal Entra ID administrator account excluded from Conditional Access and from MFA enforcement, used only when the primary identity infrastructure has failed. Best practice: at least two such accounts, with hardware FIDO2 keys stored separately, monitored by an unconditional alert on any sign-in.

The article has answered "who decided?" five times over: by signal, by policy, by token, by session, by operational pattern. One section remains: the misconceptions that keep recurring.

11. Misconceptions that recur

Every time these questions come up in practice, the same wrong answers come back. The corrections are worth memorising.

Only if you have Entra ID P1 or higher and have configured CA policies. Free SKU tenants run Security Defaults, which is a coarse tenant-wide on/off switch, not CA [@ms-security-defaults]. CA is unlocked at P1 [@ms-ca-overview]; risk-based conditions are unlocked at P2 [@ms-id-protection-overview]. The "every tenant runs on CA" framing you sometimes see in marketing material is incorrect. No. CA is a cloud control plane. Kerberos and NTLM against on-prem domain controllers do not consult Entra at all [@ms-ca-overview]. If your threat model includes on-prem lateral movement, layer in Defender for Identity and the standard on-prem hardening playbook. No. CAE is event-driven push from the policy plane to CAE-aware resource APIs. The Microsoft Learn CAE document gives the latency ceiling precisely: "the goal for critical event evaluation is for response to be near real time, but latency of up to 15 minutes might be observed because of event propagation time; however, IP locations policy enforcement is instant" [@ms-cae-concept]. There is no 30-second poll. The token can live up to 28 hours because the revocation is event-driven. No. Clients advertise CAE-readiness via the `cp1` client capability in token requests, specifically by adding `cp1` to the `xms_cc` claim mechanism (or by calling `WithClientCapabilities(new[] { "cp1" })` in MSAL) [@ms-claims-challenge][@ms-app-resilience-cae]. The Microsoft Learn claims-challenge page is explicit: "The only currently known value is `cp1`" [@ms-claims-challenge]. The CAE-aware token is recognisable by its long lifetime (up to 28 hours) and by the resource API's willingness to issue an `insufficient_claims` challenge, not by a Boolean claim. No. Third-party MDM compliance partners can write the device compliance state into Entra via Intune's compliance-partner API [@ms-intune-compliance-partners]. The CA grant reads `isCompliant` on the device object; it does not care which MDM wrote that value. Microsoft's preferred deployment is Intune, but the integration point is open by design. In 2023. The public preview of CA filters for workload identities opened on 26 October 2022 [@vansurksum-2022-workload-ca]; the Microsoft Entra Workload Identities standalone product reached GA in late November 2022, and the Conditional Access feature itself reached general availability later in 2023 [@ms-workload-identity-ca]. Any article asserting a 2025 GA date for workload-identity CA is incorrect. No. Every sign-in produces a Sign-in log entry; ID Protection emits a `riskDetection` only when at least one detector fires for that sign-in [@ms-graph-riskdetection]. Most sign-ins produce no `riskDetection`. Detection engineers querying for risk should join the Sign-in log with the riskDetections log and treat unjoined rows as "no risk flagged at the moment." No Microsoft primary source publicly describes the production model architecture or names a per-sign-in feature-vector size. What is published is the detection taxonomy (about two dozen named `riskEventType` values [@ms-id-protection-risks][@ms-graph-riskdetection]), the timing split (real-time / near-real-time / offline [@ms-risk-detection-types]), and the three-tier risk output. The "transformer with 80+ signals" framing is folk knowledge with no Microsoft primary source behind it. The article reframes it as "ML-based with detailed architecture publicly undisclosed." Not on its own. A standard MFA grant does not defeat a kit like Evilginx, which proxies both the password and the MFA challenge in real time. The defence is to require the *phishing-resistant Authentication Strength* in CA: FIDO2 with hardware attestation, Windows Hello for Business, or multifactor certificate-based authentication [@ms-auth-strengths]. The cryptographic origin-binding in WebAuthn-class credentials defeats AitM by construction. But the defence only works *when the grant is applied*. A CA policy that demands phishing-resistant for admin roles but not for users will block AitM against admins and not against users.

12. Two planes, one boundary

Replay Alice's Tuesday.

Identity Protection's signal plane scored her 09:02 sign-in. The score was below the medium-risk threshold. Conditional Access's policy plane evaluated four matching policies. Two demanded MFA; her cached refresh token already satisfied that grant from yesterday. One demanded a compliant device; Intune had marked her laptop compliant overnight. None demanded the block grant. The token issuer issued a CAE-aware bearer token with a 28-hour lifetime. Exchange Online accepted the token. Outlook's data path opened. Bytes returned to Alice.

If, twelve minutes later, an attacker tries to sign in with Alice's credentials from an anonymizing proxy, ID Protection will fire a detection. The detection will lift her user risk to high. CAE will deliver the high-user-risk event to Exchange. Exchange will issue a claims challenge on the next call from Alice's Outlook. Outlook will replay the challenge to Entra. Entra will re-run CA, see the elevated risk, demand step-up MFA, and either issue a fresh token (after Alice satisfies the step-up) or refuse.

The modern identity boundary is not a wall. It is a conversation between planes.

Key idea: The boundary is a conversation between planes, not a wall.

The open frontier is real. Agent identities want a richer grant taxonomy than the human one provides. Cross-vendor CAEP wants production receivers outside Microsoft. Workload-identity policy wants grants that go beyond block. The break-glass paradox wants an answer that does not depend on operational discipline. None of these problems will resolve in 2026. They are the next frontier.

What the reader should now be able to do: trace a sign-in through the signal, policy, token, and session planes; read a conditionalAccessPolicy JSON and predict the evaluation outcome; identify which class of attack each grant defends against; and name, by reference to specific Microsoft Learn pages, what CA does not defend against. The promise from Section 1 is delivered.

Today, 100 percent of consumer Microsoft accounts older than 60 days have multifactor authentication. -- Alex Weinert, Microsoft Identity, November 2023 [@weinert-2023-managed-policies]

Who decided this token is good? The boundary itself decided, by composing the work of every plane named above.