CAEP and Entra Continuous Access Evaluation Guide

An access token that stays valid for an hour after the account behind it was disabled is an hour of access you no longer intended to grant. Continuous access evaluation closes that gap: the identity provider tells the applications that rely on it when something important changes, such as a revoked session, a reset password or a device falling out of compliance, and those applications act straight away instead of waiting for the token to expire. This guide covers the OpenID Continuous Access Evaluation Profile (CAEP) event types and what a receiver must do with each, the documented implementations from Google, Microsoft and Okta, each described in its own section, and how to make your own applications CAE aware. It is written for identity architects, application owners and zero trust programme leads. The transport layer (streams, push and poll delivery, subjects) is covered in the Shared Signals Framework Guide, so this page links to it rather than repeating it.

Key takeaways

CAEP is a published standard. OpenID Continuous Access Evaluation Profile 1.0 was published on 29 August 2025 by the OpenID Shared Signals working group and defines eight event types built on the Shared Signals Framework 1.0.
Several identity platforms document receiver or evaluation features. Google, Microsoft and Okta each publish their own setup steps; follow each platform's current documentation.
The receiver does the real work. A CAEP event only reduces risk if the receiving application maps it to a concrete action: end sessions, revoke refresh tokens, re-evaluate authorisation or require step-up.

What it is and who it applies to

CAEP is a profile of the Shared Signals Framework (SSF). A transmitter, usually an identity provider, sends signed Security Event Tokens (SETs, RFC 8417) to receivers, usually applications or other identity systems, over a stream. CAEP defines what the events mean for access; SSF defines how they move. The CAEP specification states that implementations should comply with SSF and warns that exchanging these events without SSF compliance may cause security issues.

Three groups need to care:

Identity platform owners: whether you run Google, Microsoft, Okta or another provider, your decisions are about which events to send or receive, which policies apply and which clients honour them.
SaaS and internal application owners: to honour revocation from your identity provider in near real time, your application becomes a CAEP or RISC receiver.
Security platform teams: endpoint, threat detection and SaaS security tools can act as transmitters that feed risk into the identity provider, which then ends sessions everywhere.

CAEP and RISC are complementary profiles of the same framework. CAEP carries session and access state changes between cooperating services for the same user. The RISC profile carries account level security events, such as a hijacked or disabled account, mainly between unrelated services. The Shared Signals Framework Guide lists both families in full.

Structure and key requirements

All CAEP event type URIs share the base https://schemas.openid.net/secevent/caep/event-type/. The table below lists the eight events with the decision a receiver should have made before going live. Field level detail is in the SSF guide and the specification.

Event	Receiver decision to make in advance	Typical policy
`session-revoked`	Which local sessions and refresh tokens derive from the revoked session	End them all; a complex subject revocation applies to every session derived from the matching claims
`token-claims-change`	Which cached authorisation depends on the changed claims	Re-evaluate roles and group based access immediately
`credential-change`	Which credential types and change types matter	End sessions on revoke or delete; alert on unexpected create
`assurance-level-change`	Which functions need a minimum assurance level	Require step-up when assurance falls; treat a missing previous level as unknown
`device-compliance-change`	Which resources need a compliant device	Restrict or end sessions until the device is compliant again
`session-established`	Whether you store provider session fingerprints	Correlate with local sessions
`session-presented`	How to compare user agent fingerprints	Alert or step up when a session appears from an unfamiliar agent
`risk-level-change`	Mapping of LOW, MEDIUM and HIGH to actions	Monitor, step up or revoke

Requirements that catch receivers out:

Optional claims are normal: most CAEP claims are optional, so code must work when reason_admin, event_timestamp or previous_level are absent.
Delivery is at least once: de-duplicate on the SET jti. Google states its RISC events may be redelivered and Okta requires a unique jti.
Verify before acting: check the signature against the transmitter's published JWKS, the iss and the aud. Use the SSF verification event (https://schemas.openid.net/secevent/ssf/event-type/verification) to prove the stream works end to end.
Delivery method: push uses urn:ietf:rfc:8935 and poll uses urn:ietf:rfc:8936; SSF says a transmitter must assume poll when a stream request omits delivery.

Implementations, listed alphabetically

Platforms are listed alphabetically. Each describes its own feature names; order is not a ranking.

Google: Cross-Account Protection. Google's receiver programme for apps that use Sign in with Google is based on the OpenID RISC standard. Google sends SETs to an HTTPS endpoint you register through the RISC API (https://risc.googleapis.com/v1beta/stream:update) using a service account with the RISC Configuration Admin role (roles/riscconfigs.admin). Events cover users who granted your app the profile or email scope. Google marks some responses as required: end open sessions on sessions-revoked and on account-disabled with reason hijacking, and delete the stored refresh token on token-revoked. Validate the token using the issuer and jwks_uri from https://accounts.google.com/.well-known/risc-configuration, return HTTP 202 on success, and send a test with stream:verify. Google states the signals may only be used for security, anti-fraud and session management purposes.

Microsoft: Entra Continuous Access Evaluation. Entra evaluates five critical events: account deleted or disabled, password changed or reset, MFA enabled for the user, an administrator revoking all refresh tokens, and high user risk from Entra ID Protection. Exchange Online, SharePoint Online, Teams and Microsoft Graph also synchronise IP based named location policies. When an event arrives, the resource rejects the token with a claims challenge and the client returns to Entra for a fresh evaluation. Microsoft notes propagation latency of up to 15 minutes for events, while IP location enforcement is instant. CAE sessions can receive access tokens of up to 28 hours, and the Conditional Access session control Customize continuous access evaluation manages it. Applications opt in by declaring the cp1 client capability and handling claims challenges.

Okta: Shared Signals receiver. Okta acts as an SSF receiver for third party transmitters as part of Identity Threat Protection. An administrator registers each transmitter as a security events provider, either from its SSF well-known configuration (/.well-known/ssf-configuration) or from an issuer and JWKS URL pair, through POST /api/v1/security-events-providers. Transmitters post RS256 signed SETs to /security/api/v1/security-events and receive HTTP 202 when accepted. Accepted signals appear in the System Log as user.risk.detect and security.events.provider.receive_event, and the entity risk policy can trigger Workflows or Universal Logout. See the Okta System Log Detection Guide.

Identity and NHI requirements

Continuous evaluation is usually discussed for people, but service principals hold long lived tokens too, and a compromised one keeps working until its token expires.

Workload identities: service principals and other workload identities hold tokens too. Check each platform's current documentation for which workload identity types its continuous evaluation covers, and use short token lifetimes and credential hygiene for the rest. See the Cloud Workload Identity Guide.
Machine transmitters need identities too: every SSF transmitter signs with a private key and every receiver trusts a JWKS. Inventory those keys as non-human credentials, rotate them, and review who can register a new security events provider, because a rogue transmitter can raise risk or force logout across the workforce.

Implementation steps

Inventory long lived access: list the applications and APIs that accept your identity provider's tokens, their token lifetimes and whether they already honour revocation. Prioritise email, file storage, admin consoles and finance systems.
Confirm platform settings: on each identity platform you run, confirm continuous evaluation or signal receipt is turned on for the right users and workloads, following that platform's documentation (for Microsoft, the Conditional Access session control and IP based named locations; for Google, Cross-Account Protection registration; for Okta, security events providers).
Make your clients aware: add claims challenge or revocation handling to in-house clients before declaring support, then test by revoking a test user's sessions and calling the API.
Connect receivers: register each stream with the relevant platform and confirm it with a verification event.
Write the action map: document per event and per application what happens, who is alerted and how a wrongly revoked user recovers. Review it with the help desk.

Making an application revocation aware

For your own APIs, the receiver logic is the same in any stack: keep a fast lookup of revoked sessions and subjects keyed by the identifiers in incoming SETs, check it on every request, and make the session store able to end all sessions for one subject in a single call. Where a platform answers a revoked token with a claims challenge, pass the challenge back to the token request, try silent acquisition first, fall back to interactive sign-in, then retry the call.

Choosing an approach

Situation	Approach	Trade-off
In-house SaaS with external identity providers	Build a CAEP and RISC receiver with an SSF stream	Engineering effort; needs a revocation lookup on every request
Small organisation without engineering capacity	Turn on the continuous evaluation features your identity platform documents and shorten session lifetimes elsewhere	Revocation in other apps waits for token expiry
Fixed egress addresses	Add IP based location policies that your platform evaluates continuously, after a staged pilot	Blocks legitimate users if any egress address is missing

Evidence and assessment

Auditors and internal reviewers will ask whether revocation is fast and whether it works. Collect:

Configuration evidence: exported platform settings for each identity platform: policies, named locations, registered streams and providers.
Test records: dated tests where a test user's sessions were revoked and access ended, with the time from revocation to denial.
Platform log evidence: Entra sign-in logs show whether a CAE token was issued, Google confirms streams with stream:verify, and Okta logs security.events.provider.receive_event per accepted SET. See the Entra ID Sign-In and Audit Log Detection Guide.
Receiver logs: for each custom receiver, a log of SETs received, verified, rejected and acted on.

Metrics that show it is working:

Median and 95th percentile time from revocation to denied request, per application.
Percentage of high value applications that are CAE aware or SSF receivers.
SETs rejected for signature or audience failure (should be near zero and investigated).
Verification event success rate per stream.

Mapping to other frameworks

Framework	Reference	How continuous evaluation supports it
NIST SP 800-53 Rev. 5	AC-12 Session Termination	Ends sessions on defined conditions rather than at a fixed time
NIST SP 800-53 Rev. 5	IA-11 Re-authentication	Claims challenges and step-up force re-authentication when conditions change
NIST SP 800-53 Rev. 5	AC-2 Account Management	Disabling or deleting an account takes effect in relying services
NIST CSF 2.0	PR.AA-03, PR.AA-05	Authentication and authorisation enforced continuously, not only at sign-in
NIST CSF 2.0	DE.CM-03	Risk signals from monitoring feed access decisions
NIST SP 800-207	Zero trust tenets	Per-session, dynamic policy evaluation. See the NIST SP 800-207 Zero Trust Architecture Guide
MITRE ATT&CK	T1550.001 Application Access Token, T1539 Steal Web Session Cookie	Shortens the useful life of stolen tokens and sessions

Common pitfalls

Assuming events replace explicit revocation: policy and group changes can take time to reach resources. After a compromise, revoke sessions explicitly on each platform.
Location policies that cannot be evaluated continuously: check which location types your platform evaluates in real time and which only at sign-in.
Receivers that only log: a stream that delivers events into a SIEM but never ends a session gives visibility without protection. Map each event to an action.
Unverified transmitters: accepting SETs without checking signature, issuer and audience lets anyone trigger mass logout or suppress risk.

Practitioner checklist

On each identity platform you run (listed alphabetically: Google, Microsoft, Okta), confirm continuous evaluation or signal receipt is turned on as its documentation describes.
Add claims challenge or revocation handling to in-house apps, then test with a session revocation.
Register each receiver stream and confirm it with a verification event.
Write and test an action map for all eight CAEP events in each receiving application.
Inventory transmitter signing keys and restrict who can add a transmitter.
Measure time from revocation to denial each quarter and report it.

CAEP and Continuous Access Evaluation: Revoke sessions and tokens in near real time