Shared Signals Framework Guide: CAEP and RISC

When an identity provider disables an account, revokes a session or detects a compromised credential, the applications that trusted its earlier sign-in usually keep honouring sessions and tokens until they expire. The OpenID Shared Signals Framework (SSF) closes that gap by giving identity providers, SaaS applications, device management tools and security platforms a standard way to send each other security events in near real time. Its two main profiles are CAEP, the Continuous Access Evaluation Profile, for session and access changes, and RISC, Risk Incident Sharing and Coordination, for account-level incidents. All three are now Final specifications at the OpenID Foundation. This guide explains how the framework works, what each event means, how to deploy a transmitter or receiver safely and how to measure whether it is working. It is for identity engineers, SaaS platform teams and detection engineers; token and session fundamentals are covered in the Token and Session Security Guide.

Key takeaways

• SSF is the transport and management layer. It defines Security Event Tokens, subject identifiers, transmitter discovery at /.well-known/ssf-configuration, push and poll delivery, and a stream management API.
• CAEP carries access changes. Eight event types cover session revoked, token claims change, credential change, assurance level change, device compliance change, session established, session presented and risk level change.
• RISC carries account incidents. Events such as account disabled (with reason hijacking or bulk-account), credential compromise, identifier recycled and recovery information changed help relying parties protect linked accounts.
• Receiving a signal is only half the job. Value comes from a documented action per event type, such as ending sessions, revoking refresh tokens or forcing step-up, tested end to end with verification events.
• The streams themselves are sensitive. A forged or suppressed event can lock users out or keep an attacker in, so authenticate stream management, validate every SET signature and audience, and monitor stream health.

Why continuous signals are needed

Federation is a one-time decision. At sign-in, the identity provider vouches for the user and the application issues its own session and often its own tokens. Later changes at the provider, such as an account disabled by the help desk, a password reset after phishing, a device falling out of compliance or a risk engine flagging a hijack, do not reach the application. The usual workarounds are short session lifetimes, which annoy users, or periodic polling, which is slow and expensive.

SSF replaces both with events. The party that observes a change, the Transmitter, sends a signed event to every Receiver that has subscribed to that subject, and each receiver decides what to do. Signals flow in both directions: an application can transmit to the identity provider just as easily, for example to report that a session was presented from an unexpected network. Microsoft documents its Entra Continuous Access Evaluation as based on CAEP, with resource providers and Entra exchanging events so that tokens stop being honoured after critical changes. The same pattern is central to the continuous verification principle in the Zero Trust Identity Guide.

Specification status

The framework builds on IETF standards: Security Event Tokens (RFC 8417), push delivery (RFC 8935), poll delivery (RFC 8936) and subject identifiers (RFC 9493). The OpenID Foundation also lists a formal security analysis of SSF transmitter configuration discovery, dated April 2024.

How the framework works

Security Event Tokens

• Format: each event is a signed JWT with explicit type typ: secevent+jwt. The events claim holds the event type URI and its fields.
• Claims: iss must match the stream configuration and the discovery issuer; aud identifies the receiver; jti is unique per token; txn should be set and unique to the underlying event, so related events can be correlated.
• What is absent: SETs must not include sub or exp. They describe something that already happened, so receivers do not reject them as expired; Google's RISC documentation tells receivers to skip the expiry check for that reason.
• Forward compatibility: receivers must ignore fields they do not understand.

Subjects

• Primary subject: the top-level sub_id claim. Older CAEP and RISC events may also use a subject field inside the event, but transmitters must still include sub_id, and new event types use only sub_id.
• Formats: RFC 9493 identifiers such as email, phone_number, iss_sub and opaque, plus SSF additions jwt_id, saml_assertion_id and ip-addresses.
• Complex subjects: combine members such as user, device, session, application, tenant, org_unit and group, so an event can target "this user's session on this device". Receivers must discard events containing critical members they cannot process.

Discovery, delivery and streams

• Transmitter metadata: published at /.well-known/ssf-configuration (inserted before any issuer path, per RFC 8615), listing the issuer, jwks_uri, supported delivery methods, management endpoints, authorisation schemes, critical subject members and default_subjects (ALL or NONE). RISC transmitters may still use the older /risc-configuration path.
• Push delivery (RFC 8935): the transmitter POSTs SETs to an HTTPS endpoint the receiver supplies. Lowest latency; the receiver must be reachable.
• Poll delivery (RFC 8936): the receiver fetches SETs from an endpoint the transmitter supplies and acknowledges them. Suits receivers behind firewalls or with bursty processing.
• Stream management API: create (POST), read (GET), update (PATCH), replace (PUT) and delete (DELETE) a stream; set status to enabled, paused or disabled; add and remove subjects; and request a verification event. Transmitters must send a Stream Updated event when they change a stream's status themselves. The API is optional for transmitters but recommended.
• Authorisation of management calls: must use standard HTTP authentication unless another trust mechanism exists, and must tie each receiver to its own stream IDs and audience values.

Push or poll

CAEP events and how to act on them

All CAEP event types use the base URI https://schemas.openid.net/secevent/caep/event-type/ and share optional fields: event_timestamp, initiating_entity (admin, user, policy or system), reason_admin and reason_user, the last two keyed by language tag.

Session established and session presented together are a building block for detecting stolen session cookies (MITRE ATT&CK T1539, Steal Web Session Cookie): if a provider and an application share fingerprints, a session presented from an unfamiliar user agent stands out. See the Session Hijacking and Cookie Theft Guide.

RISC events and the RISC profile

RISC targets a different problem: an attacker who takes over a user's email or identity provider account can use it to recover or sign in to every linked account. RISC lets the provider tell relying parties promptly. Event URIs use the base https://schemas.openid.net/secevent/risc/event-type/.

The RISC sessions-revoked event is deprecated; new implementations use CAEP session-revoked. Google's Cross-Account Protection is a widely documented RISC deployment, and its documentation shows the practical details: receivers register through a service account holding the RISC Configuration Admin role and the risc.googleapis.com stream API, validate tokens against keys from https://accounts.google.com/.well-known/risc-configuration, return HTTP 202 for valid tokens, and de-duplicate on jti because events may be redelivered. Google sends events only for users who granted the app the profile or email scope, does not currently send them for Workspace users, and still uses the deprecated subject_type field, so receivers need tolerant parsing. For the fraud side of account takeover, see the Account Takeover Prevention Guide.

Choosing a role and an architecture

• Receiver only: the common starting point for SaaS applications and internal apps that federate to an identity provider. Highest value: session revoked and credential change from the provider.
• Transmitter only: identity providers, device management and endpoint tools, and risk engines that hold signals other systems need.
• Both: large platforms and identity providers that want feedback from resource applications, for example IP or device context, which is the two-way model Microsoft describes for CAE.
• Hub: larger organisations often route signals through one broker or ITDR platform that receives from several transmitters, applies policy and fans out actions, so each application integrates once. See the ITDR Guide.

Small organisations: usually consume SSF through features their identity provider and major SaaS vendors already ship. Ask vendors which SSF, CAEP and RISC versions and event types they support, whether they transmit, receive or both, and what action each received event triggers. Large organisations: need an event catalogue, an owner per stream, a policy per event type and application, and monitoring of stream health as production infrastructure.

How to implement

1. Define the actions first. For each event type you will accept, write the action, its scope (session, user, device) and who is notified. Without this, events land in a log and nothing changes.
2. Start with one pair and one event. Identity provider to your most sensitive SaaS application, receiving session-revoked. The CAEP Interoperability Profile requires implementations to support at least one of session revocation, credential change or device compliance change, so most vendors cover one of these.
3. Configure the stream securely. Discover the transmitter from its well-known metadata, create the stream requesting only the event types you have mapped, register subjects explicitly unless default_subjects is ALL by design, and protect management calls with OAuth. The interoperability profile uses scopes ssf.read and ssf.manage, tokens valid for no more than 60 minutes, sent in the header only.
4. Validate every SET. Check the kid against the transmitter's jwks_uri, the signature, iss and aud, and reject duplicates by jti. The interoperability profile signs with RS256 using keys of at least 2048 bits and requires TLS 1.2 or later.
5. Test end to end. Use the verification event to prove delivery, then trigger real events in a test tenant: disable a test user, reset a password, mark a device non-compliant. Measure time from the change to the session actually ending.
6. Run in observe mode, then enforce. Log the action the receiver would take for two weeks, compare with expectations, then enable enforcement per event type. Roll back by setting the action to log-only, not by disabling the stream, so you keep visibility.
7. Extend. Add credential change, device compliance and risk level events, then RISC for consumer-facing sign-in, then transmission from your own applications back to the provider.

Where non-human identities fit

SSF subjects are not limited to people: the framework lists devices, tenants, organisational units, groups and applications, and complex subjects can carry an application member. In practice most shipped events concern users and sessions, so do not assume a vendor transmits events about service accounts or OAuth client credentials. The gap matters: in the Salesloft Drift breach, stolen OAuth tokens for one integration were used across many Salesforce tenants from 8 to 18 August 2025 until all Drift tokens were revoked on 20 August, with Google revoking the Drift Email tokens on 28 August. Revocation was coordinated by the vendors through advisories rather than through a standard signal each customer system could act on automatically. Ask providers whether they emit credential-change or token-claims-change for integrations and agents, and pair SSF with the controls in the OAuth Token Theft Incident Playbook.

Detection and measurement

• Stream health: stream status changes (including Stream Updated events from the transmitter), delivery failures and retries, poll backlog, and time since the last verification event succeeded. A paused or disabled stream silently removes protection; Google notes that it does not buffer events while a stream is paused.
• Security of the channel: SET signature or audience failures, events from unknown issuers, subject removal requests (the SSF specification flags malicious subject removal and subject probing as threats), and changes to stream configuration.
• Effect: for each received event, whether the mapped action ran and how long it took. In Microsoft's CAE, critical events are applied in near real time with propagation latency of up to 15 minutes, which is a realistic benchmark.

Common failure patterns

• Ending the session but not the tokens. A receiver that clears its web session on session-revoked but leaves refresh tokens and API tokens valid leaves the attacker's access intact.
• Subscribing without acting. Events reach a SIEM, nobody owns the action, and the application keeps serving the session.
• Subject mismatch. The transmitter sends iss_sub while the receiver indexes users by email, so events match nobody. Agree formats up front; the interoperability profile requires receivers to accept email and iss_sub.
• Weak stream management authorisation. A shared, long-lived token for the management API lets anyone holding it remove subjects or disable the stream, quietly turning off protection.
• Rejecting SETs as expired or treating them as access tokens. SETs carry no exp and are not credentials; applying access token validation logic breaks delivery.
• Version drift. Products built on Implementer's Drafts use older field names, such as subject instead of sub_id or RISC subject_type; parse tolerantly and test against each peer.

Framework mapping

Practitioner checklist

• Inventory which of your identity providers, SaaS applications and device tools transmit or receive SSF events, and which spec versions they implement.
• Write an action per accepted event type, with owner and scope, before enabling any stream.
• Start with session-revoked from the identity provider to your most sensitive applications.
• Make receivers revoke refresh and API tokens as well as web sessions.
• Validate SET signature, iss, aud and jti on every event, and never check exp.
• Protect stream management with short-lived OAuth tokens scoped to ssf.read and ssf.manage.
• Agree subject identifier formats with each peer and test matching with real accounts.
• Alert on stream pause, disable, delivery failure and missing verification events.
• Measure time from provider change to session end every month with test accounts.
• Ask vendors whether they emit events for integrations, OAuth clients and agents, not only users.

Standards and references

• OpenID Foundation: Shared Signals Framework Specification 1.0
• OpenID Foundation: Continuous Access Evaluation Profile 1.0
• OpenID Foundation: RISC Profile Specification 1.0
• OpenID Foundation: CAEP Interoperability Profile 1.0
• OpenID Foundation: Shared Signals Working Group Specifications
• Google for Developers: Protect user accounts with Cross-Account Protection
• Microsoft Learn: Continuous access evaluation

Related NHI Mgmt Group resources: Token and Session Security Guide · Zero Trust Identity Guide · Fraud and Cyber Convergence Guide · Conditional Access Guide · OAuth 2.1, GNAP and FAPI Guide