TL;DR

Continuous Access Evaluation (CAE) enables real-time session enforcement in identity systems. The technical backbone is the Continuous Access Evaluation Profile (CAEP), which standardizes event types, and the Shared Signals Framework (SSF), which provides the transport for these events. Together, CAEP and SSF allow identity providers, applications, and security tools to publish and subscribe to security events, enabling immediate session enforcement and risk mitigation.

CAE vs. CAEP vs. SSF: What’s the Difference?

• CAE: The enforcement capability—real-time revocation and reauthentication during active sessions (e.g., in Microsoft Entra ID).
• CAEP: The standardized event vocabulary (e.g., session-revoked, credential-change, device-compliance-change) that defines what changes should trigger session re-evaluation.
• SSF: The transport and negotiation framework (webhook/poll with retries & acknowledgments) that connects transmitters (event publishers) and receivers (event consumers).

Signal Flow: How It Works

1. Detection: An identity provider (IdP) or security tool detects a change (e.g., risk, credential update, device compliance loss).
2. Transmission: The IdP transmits a CAEP event via SSF to subscribed applications/services.
3. Enforcement: Those applications invalidate tokens and issue claims challenges.
4. Additional Validation (optional): Some systems may use token introspection or extra checks to catch anything that slips past initial enforcement. This is an implementation choice, not a core CAEP requirement.

CAEP Event Types: The Field Guide

The OpenID CAEP spec lays out five key event types that transmitters use to signal receivers when it’s time to take another look at access permissions. These are:

• Session Revoked — revoke a session.
• Token Claims Change — a token’s claims were updated (supply the new claims object).
• Credential Change — a credential was created/updated/revoked (includes credential type & change type).
• Assurance Level Change — the authentication assurance (NIST AAL) increased or decreased.
• Device Compliance Change — a device’s compliance status switched between compliant and not-compliant.

CAEP Event Type	What It Means	Example Real-World Triggers
Session Revoked…/session-revoked	A session is no longer valid and must be terminated immediately.	Admin revokes tokens after a breach; Risk engine kills a session due to impossible travel; User manually signs out everywhere.
Token Claims Change…/token-claims-change	One or more token claims (attributes) have changed since issuance.	Account disabled (account_enabled:false); Account re-enabled (account_enabled:true); Risk level updated (risk_level: high); User location or IP updated; New conditional access requirement (requires_mfa:true).
Credential Change…/credential-change	A credential tied to the user has been created, updated, reset, or revoked.	User resets password after phishing attempt; Admin revokes a compromised FIDO2 key; User adds a new OTP authenticator.
Assurance Level Change…/assurance-level-change	The authentication assurance (e.g., NIST AAL) increases or decreases.	User upgrades from password-only (AAL1) to password + FIDO2 (AAL3); Step-down occurs when session reverts to weaker auth.
Device Compliance Change…/device-compliance-change	The compliance status of a device has changed.	Device becomes non-compliant because antivirus disabled or jailbroken; Device returns to compliant after patch installation.

Each event type has a canonical event-type URI under https://schemas.openid.net/secevent/caep/event-type/ and uses optional fields like event_timestamp, initiating_entity, and localized reason messages to provide context.

Here’s a quick example of how you can flag a risk update using the token-claims-change event.

{
"iss": "https://idp.example.com",
"iat": 1694500000,
"jti": "2f4d9c8e-3bfa-4f23-95a4-b13f7857a2cd",
"events": {
"https://schemas.openid.net/secevent/caep/event-type/token-claims-change": {
"subject": {
"format": "opaque",
"id": "8c3e0f0a-b6f5-42b8-9c7f-5c9df92c89a0"
},
"claims": {
"risk_level": "high",
"trusted_network": false
}
}
},
"event_timestamp": 1694500000,
"initiating_entity": "risk_engine",
"reason_admin#en": "User activity flagged as high risk"
}

What’s happening here:

• events → defines this as a token-claims-change.
• subject → identifies the session/token holder (opaque ID in this example).
• claims → new values for risk-related claims (risk_level: high, trusted_network: false).
• initiating_entity → risk_engine shows the source of the signal.
• reason_admin#en → gives a human-readable reason (in English).

This way, relying parties can immediately re-evaluate access policies (for example, force step-up auth, limit sensitive operations, or revoke access

Let’s look at a contrasting example of a ‘Session Revoked’ event—this time triggered by a risk-related reason.

{
"iss": "https://idp.example.com",
"iat": 1694505000,
"jti": "7f2e91d2-8b0a-4d2e-b13c-62de78f9d111",
"events": {
"https://schemas.openid.net/secevent/caep/event-type/session-revoked": {
"subject": {
"format": "opaque",
"id": "8c3e0f0a-b6f5-42b8-9c7f-5c9df92c89a0"
}
}
},
"event_timestamp": 1694505000,
"initiating_entity": "risk_engine",
"reason_admin#en": "Session revoked due to impossible travel activity"
}

Key differences vs. the token-claims-change example:

• No claims object — it’s not updating attributes, it’s terminating the session.
• Same subject format (opaque ID).
• Uses reason_admin#en for traceability (admin logs, auditing).
• Receivers should immediately end the session for this subject.

SSF Implementation Details

The Shared Signals Framework (SSF) is the emerging standard for transporting security event tokens (SETs) between transmitters and receivers. SSF supports asynchronous delivery, negotiation of event types, delivery mechanisms, and stream management. It enables organizations to react to security events in near real-time, reducing the window of risk.

SSF Key Features

• Standardized Transport: Secure webhooks and polling models for reliable communication.
• Negotiation: Transmitters and receivers negotiate supported event types and delivery mechanisms.
• Stream Management: Mechanisms for managing, verifying, and auditing event streams.

RISC: Account-Centric Security Signals

The Risk Incident Sharing and Coordination (RISC) specification defines event types used to communicate account-level security and lifecycle changes between services that share users. Examples include:

- account-disabled or account-enabled

- account-purged (account permanently deleted)

- account-credential-change-required

- identifier-changed or identifier-recycled

- sessions-revoked (revoke all sessions for a user)

Like CAEP, RISC events are delivered as Security Event Tokens (SETs) via the Shared Signals Framework (SSF).

While some signals overlap (for instance, both specs support session revocation), their scope is different:

RISC (Account-Centric)	CAEP (Session-Centric)
Focuses on account lifecycle and security state across providers.	Focuses on live session and access enforcement.
Examples: account disabled, account purged, identifier recycled.	Examples: session revoked, token claims change, credential change, assurance level change, device compliance change.
Keeps services in sync when a user’s account status changes.	Ensures access decisions adapt in real time to risk, policy, or device posture changes.

RISC ensures that account state is consistently reflected across systems, while CAEP ensures that sessions and access are continuously re-evaluated. Together, they provide a comprehensive framework for modern identity and security signals.

Now that OpenID has officially approved the final specs for SSF, CAEP, and RISC, organizations have a solid and interoperable framework to work with. This means they can coordinate real-time responses across identity, device, application, and endpoint systems, closing signal gaps and making Zero Trust not just a concept, but a truly adaptive reality.

Specifications

– https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html
– https://openid.net/specs/openid-caep-1_0-final.html
– https://openid.net/specs/openid-risc-1_0-final.html
– https://openid.net/three-shared-signals-final-specifications-approved/