What Is CAEP (Continuous Access Evaluation)?

An attacker phishes an access token at 09:00. The user reports it at 09:15, IT disables the account at 09:20, and the attacker keeps reading mailbox data until 14:00. Nothing in that timeline is exotic. The gap is structural: an OAuth or OpenID Connect access token is a bearer credential with a fixed lifetime, and most resource servers honor it until it expires regardless of what happened to the account in between. Disabling the user in the identity provider does not reach back and invalidate the token already in the attacker's hands.

CAEP, the Continuous Access Evaluation Profile, closes that gap. It is a profile of the OpenID Foundation's Shared Signals Framework that lets an identity provider push a security event the moment risk changes, so the relying party can re-evaluate and cut access in near real time instead of waiting for token expiry. This guide covers what CAEP is, the token-lifetime problem it solves, how the Shared Signals plumbing actually moves an event from transmitter to receiver, the event types CAEP defines, how the open profile differs from Microsoft's Continuous Access Evaluation implementation, and where it sits in a zero trust design. It is written for the people who have to answer "why was that token still valid?" after the fact: SOC analysts, threat hunters, and DFIR responders working identity telemetry.

What is CAEP?

CAEP is a specification that defines a set of security event types and applies the OpenID Shared Signals Framework to them, so cooperating systems can communicate access-relevant changes continuously rather than only at login. The profile reached version 1.0 final status on August 29, 2025, published by the OpenID Foundation's Shared Signals Working Group, authored by Tim Cappalli and Atul Tulshibagwale. It is not an IETF standard, and it is not a Microsoft product. It is an open profile, and getting that attribution right matters because the parts come from different bodies.

Three layers stack here, and the names get conflated constantly. The Shared Signals Framework (SSF) is the transport: it defines transmitters, receivers, event streams, and how events are delivered. The Security Event Token (SET) is the message format, defined by IETF RFC 8417. CAEP is the vocabulary: the specific event types relevant to access decisions, expressed as SETs and carried over SSF. RISC, the Risk Incident Sharing and Coordination profile, is a sibling vocabulary on the same framework, aimed at account-level risk signals like account takeover rather than session-level access. All three (SSF, CAEP, RISC) went final on the same August 2025 date.

The short version: SSF is the pipe, SET is the envelope, CAEP is the set of letters you put in it. When someone says "CAEP," they usually mean the whole arrangement, but the standard itself is just the event definitions and their binding to the framework.

The problem: long-lived tokens outlive the risk

Access control at login is a single decision made with the information available at that instant. OAuth 2.0 and OpenID Connect formalized that decision into a token: the identity provider authenticates the user, evaluates policy, and issues an access token good for some lifetime, often an hour, sometimes much longer. The resource server then trusts that token until it expires. That design is what makes the model scale, because the resource server does not have to call back to the identity provider on every request.

The cost is a blind window. Between issuance and expiry, the token is valid by definition, and a lot can change inside that window. The user's password is reset because it leaked. The device falls out of compliance. The session is flagged as impossible travel. The account is disabled during an incident. None of those events reach a token that has already been minted. The resource server has no reason to ask again, so it keeps honoring the bearer credential until the clock runs out.

Shortening token lifetimes is the obvious lever, and it is the wrong one past a point. Drop the lifetime to five minutes and you flood the identity provider with refresh traffic and degrade the user experience for everyone to shave a few minutes off an attacker's window. Stretch it to reduce that load and you widen the window you were trying to close. The lifetime is a single static guess about how long the original decision stays valid, and no single value is right. CAEP removes the guess. Instead of betting on a duration, the identity provider tells the resource server when the decision is no longer valid, and the resource server acts on that signal.

How CAEP works: transmitters, receivers, and Security Event Tokens

CAEP rides on the Shared Signals Framework, so the mechanics are the framework's. Two roles do the work. A transmitter is the system that detects a change and emits an event, typically the identity provider or an identity protection service. A receiver is the system that consumes the event and acts on it, typically a relying party or resource server holding a session it might need to revoke. The two negotiate a stream: the receiver registers, declares which event types it wants, and the transmitter sends matching events on that stream as they occur.

Each event travels as a Security Event Token. A SET is a JSON Web Token carrying an events claim, defined by RFC 8417. SSF profiles it tightly: the token is explicitly typed secevent+jwt, and the framework forbids the sub and exp claims at the top level, because a security event is a statement about something that already happened, not a credential with a subject and an expiry. Inside the event, a subject identifier names what the event is about, a user, a session, a device, a token, using the standardized subject formats so the receiver can match it to a session it holds.

Delivery comes in two shapes, both defined by SSF. Push delivery sends each SET to the receiver over an HTTP POST (RFC 8935): the transmitter calls the receiver's endpoint as events happen. Poll delivery has the receiver pull queued SETs with an HTTP request (RFC 8936): the receiver asks for what is waiting. Push is lower latency and fits the real-time revocation case; poll is simpler for a receiver that cannot expose an inbound endpoint. Either way the receiver, on getting a Session Revoked or Credential Change event for a subject it recognizes, re-evaluates and can drop the session immediately rather than at token expiry.

The CAEP event types

CAEP 1.0 defines eight event types. They are the standard vocabulary; a transmitter sends the ones it supports, and a receiver subscribes to the ones it can act on.

The event types map to the risk changes that used to fall into the token blind window. A password reset becomes a Credential Change. A device dropping out of compliance becomes a Device Compliance Change. An incident-response account disable becomes a Session Revoked. Each one is an event the transmitter can push the instant it happens, and a receiver subscribed to it can re-evaluate before the old token would have expired on its own.

CAEP vs CAE: the open profile and Microsoft's implementation

The two acronyms are one letter apart and routinely swapped, which causes real confusion in incident notes. CAEP is the open OpenID profile. Continuous Access Evaluation (CAE) is Microsoft's implementation of it inside Microsoft Entra ID. Microsoft's own documentation states that CAE is "an industry standard based on OpenID Continuous Access Evaluation Profile." CAEP is the spec; CAE is one vendor's product built to it.

Concretely, Entra CAE wires the model into Microsoft services. Resource providers like Exchange Online, SharePoint Online, and Teams subscribe to critical Entra events, so when Entra detects a relevant change it can have those services re-evaluate near real time. The bidirectional model lets a resource provider report a property change such as network location back to the token issuer, and lets the issuer tell the resource provider to stop accepting tokens for a user after account compromise or disablement. The enforcement mechanism is a claims challenge: a resource provider can reject a token that has not expired and signal the client to go get a fresh one from Entra, which re-applies policy.

A practical detail that surprises people: under CAE, Entra increases access token lifetime to long-lived, up to 28 hours, rather than shortening it. That is the whole point of continuous evaluation. Once the provider can revoke on event, a long token is no longer a long blind window, because the window is closed by the signal, not by the clock. The same logic applies to any CAEP implementation: continuous evaluation lets you stop trading user experience against exposure on the token lifetime dial. Microsoft Entra is the most widely deployed implementation, but CAEP is vendor-neutral by design, which is what makes a Session Revoked event from one provider intelligible to a receiver built by another.

CAEP and zero trust

Zero trust starts from the assumption that no access is trusted by default and every request is verified in context. The hard part is the word "continuous." Verifying at login is easy; verifying continuously means the system has to react to context that changes after login, which is exactly the blind window an issued token creates. CAEP is a mechanism that makes continuous verification operational rather than aspirational. It gives the identity provider a way to say "the context I authorized against has changed" and the relying party a way to hear it and act.

This is the same shift that pushes authorization from a one-time gate toward a per-request, context-aware decision, the model that adaptive authentication and attribute-driven policy already aim at. CAEP supplies the missing piece: the out-of-band signal that lets a relying party re-evaluate a session it has already granted, without waiting for the user to come back and re-authenticate. Where attribute-based access control (ABAC) computes a decision from current attributes at request time, CAEP is how a change in those attributes (a device falling out of compliance, an assurance level dropping) reaches the systems holding live sessions so they can recompute.

For a defender, the payoff is twofold. Containment gets faster: disabling an account in the identity provider can actually terminate the attacker's active sessions instead of leaving them live until token expiry. And the signal stream is telemetry. Session Revoked, Credential Change, and Risk Level Change events are a record of access decisions changing in flight, exactly the kind of identity signal a hunt or an investigation wants, provided the receiver logs the events it consumes and not just the ones it acts on.

The bottom line

CAEP exists because an access token is a static decision with a fixed shelf life, and risk does not respect that shelf life. It is a profile of the OpenID Shared Signals Framework, not an IETF standard and not a Microsoft product, that defines eight event types (Session Revoked, Credential Change, Device Compliance Change, and the rest) carried as RFC 8417 Security Event Tokens from a transmitter to a receiver over push or poll delivery. When risk changes, the provider emits the event and the relying party re-evaluates, instead of honoring a stale token until it expires.

For a defender the distinction worth holding onto is CAEP versus CAE: CAEP is the open spec, CAE is Microsoft Entra's implementation of it, and the reason CAE can issue 28-hour tokens is that continuous evaluation closes the window the clock used to. The same signals that shrink an attacker's dwell time, a disabled account that actually drops live sessions, are identity telemetry worth collecting. The provider that can revoke on event is also the provider that can tell you, in an investigation, exactly when and why a session stopped being trusted.