Shared Signals Framework (SSF)
The OpenID Shared Signals Framework (SSF) is a standard for sharing security events in near real time between systems and organizations, so that a session revoked, a device fallen out of compliance or an account compromised in one place is acted on everywhere else that relies on it. It works alongside OpenID Connect and OAuth 2.1 deployments and gives them a common channel for security-relevant information across trust boundaries. Two profiles define what is sent: the Continuous Access Evaluation Profile (CAEP) for changes that should alter a live session, and Risk Incident Sharing and Coordination (RISC) for account-level incidents shared between organizations. SSF 1.0, CAEP 1.0 and RISC 1.0 have been OpenID Final Specifications since September 2025.
An access decision made at login normally holds until the session or token it produced expires. SSF lets the system that notices a change tell every system still relying on the old decision, so that each of them decides again. Whether an organization gains anything from that depends less on the transmitter than on the receivers: an event only shortens the window if the application that receives it does something.
Offboarding at Revocation Speed
When someone leaves, the IAM team disables the account at the identity provider, and SCIM deprovisioning removes it from the applications connected to it. Neither ends a session that is already open. An application that accepted a login this morning keeps its own session cookie, and an OAuth client keeps its access token until it expires and its refresh token until the authorization server stops honouring it. Until then the leaver, or an attacker holding a stolen session, keeps working. Shorter lifetimes narrow the window at the price of more logins and more load on the identity provider, and they do nothing for an application whose own session outlives the token that created it.
With SSF, the identity provider sends a session-revoked event to every receiver on the stream when the account is disabled. A receiver that acts on it ends the local session and revokes the tokens it holds, and offboarding takes effect in minutes instead of at the next expiry. The same path carries the other cases an auditor asks about: a credential reset after phishing, a device that fails its compliance check, an account that Identity Threat Detection and Response (ITDR) has flagged. The control that can be measured is the time between disabling an account and the last application rejecting it. It is only as short as the slowest receiver, so it has to be measured per application, by revoking a test account and watching which applications still let it in.
Setting Up a Stream
Everything in SSF runs over a stream: a configured channel between one transmitter and one receiver, with an agreed set of event types and subjects. The transmitter publishes its metadata at /.well-known/ssf-configuration below its issuer, including its signing keys, the delivery methods it supports and the endpoints for managing streams. The receiver creates a stream through that management API, authenticating with whatever the transmitter requires, typically an OAuth access token or mutual TLS, and names the event types it wants. The transmitter answers with the types it will actually deliver, the intersection of what it supports and what was requested. A receiver that does not compare that list with its request can believe it is subscribed to events that will never arrive.
Subjects are the second decision. A transmitter either sends events for all subjects by default or for none until the receiver adds them one at a time. Within one organization, all subjects is the practical setting. Between organizations, adding only the users both parties serve keeps the stream from disclosing anyone else. The transmitter may silently ignore a request to add a subject, for example when the user has declined to have events shared, so a successful call does not prove coverage. Subjects are described with the identifier formats of RFC 9493, such as an email address, an issuer and subject pair or an opaque identifier, or with the complex subject SSF itself defines, which combines identifiers such as a user, a device, a session and a tenant.
A stream that has stopped delivering looks exactly like a stream with nothing to report. SSF gives the receiver two defences. It can ask for a verification event, which the transmitter sends through the stream carrying a value the receiver chose, proving end to end that events arrive and validate. And a transmitter that pauses or disables a stream must first send a stream-updated event saying so. A paused stream holds its events and delivers them when it resumes; a disabled one drops them. Receivers should request verification on a schedule and alert when it fails, as they would for any control that fails without an error.
Push or Poll
Events travel as Security Event Tokens (SETs, RFC 8417): signed JSON Web Tokens whose events claim names each event by URI and carries its details, with the subject and the time it was issued. SSF delivers them by one of two methods.
With push delivery (RFC 8935), the transmitter posts each SET to an HTTPS endpoint the receiver runs, and the receiver answers 202 once it has validated and stored the token. It is the faster method, and the one that makes offboarding in minutes realistic. It also requires an endpoint the transmitter can reach, which for a cloud identity provider means one reachable from the internet, and whether a SET is sent again after the receiver was down is left to the transmitter's implementation.
With poll delivery (RFC 8936), the receiver fetches waiting SETs from the transmitter and acknowledges them by their jti in its next request. Unacknowledged SETs can be delivered again, so an outage at the receiver costs delay rather than events, up to however long the transmitter keeps them. By default a poll request is a long poll, which the transmitter holds open until an event arrives, so latency stays low without an inbound connection. Poll suits on-premises applications and anything behind a firewall that cannot accept connections from outside.
What a Receiver Has to Do
Receiving an event starts with validating it: the signature against the transmitter's published keys, the issuer against the stream configuration, the audience, and the secevent+jwt token type. A receiver must discard an event whose subject contains a member the transmitter has marked critical if it cannot process that member, and it ignores fields it does not understand. The same SET can arrive twice, so the receiver keeps the jti values it has seen.
Then the receiver has to find the subject. The event names a user by email address, by issuer and subject, or as a complex subject of user, device and session, and the application has to map that onto its own accounts and live sessions. An application that never kept an index from the identity provider's subject to its own sessions cannot act on an event even when it receives one, and building that index is where most retrofits spend their effort.
The action itself is left to the receiver. The specifications say what an event means and not what to do about it. For session-revoked, the obvious action is to end the matching sessions and revoke any refresh tokens issued on them. For a credential change or a lowered assurance level, it may be to demand a fresh login, or a step-up for sensitive operations. For a device compliance change or a risk level change, it is an input to the next access decision, which a decision point behind OpenID AuthZEN can read as one attribute among others. Each application owner has to decide this per event type and write it down, because the same event can reasonably mean "log out now" in one application and "ask again at the next write" in another.
Many applications that list SSF support today only receive events: they accept the stream, log what arrives or act on one event type, and leave sessions open for the rest. "Supports SSF" in a product sheet therefore says little. The questions for a procurement are which event types the application acts on, what it does for each, and how long a revoked session survives. The same gap exists in the organization's own applications, and closing it application by application is most of the work of an SSF rollout. That is also why a rollout should start with the applications that hold the most sensitive data and the longest sessions, rather than with those easiest to connect.
CAEP and RISC
CAEP is the profile for live sessions, mostly within one organization or between an identity provider and the applications that trust it. Its eight event types are session revoked, session established, session presented, token claims change, credential change, assurance level change, device compliance change and risk level change. Risk level change reports a principal's current risk as low, medium or high, optionally with the previous level and a reason, which gives risk engines and ITDR systems a standard way to tell applications what they have concluded. CAEP events are also what workload and machine identities and AI agents need when their posture changes during a long-running task rather than at login.
RISC is the profile for accounts shared between organizations. An email provider can tell the services a user has signed up to that the account was compromised, disabled or purged, or that its identifier was recycled and now belongs to someone else, which matters to every service that uses that address for recovery. Its other events cover credential changes the user should make, activated recovery, changed recovery information, and consent: opt-in and opt-out events carry the account holder's choice about whether events about them are shared at all. RISC also defines a sessions-revoked event, but it is deprecated, and new implementations must use CAEP's session-revoked instead. A deployment that handles both profiles therefore needs a single session-revocation path.
Cross-organization RISC streams carry personal data about people who are customers of both parties, so they need a legal basis and a data-sharing agreement before they need an endpoint. The framework itself limits what leaks: a transmitter can refuse or silently ignore requests to add subjects, so that a receiver cannot probe whether someone holds an account.
Where the Events Go Next
The applications that end sessions are the reason to deploy SSF, and the same events serve detection as well. In the SIEM, a session revocation next to a burst of failed logins tells a different story than either alone, and in SOAR an event can start a response workflow. ITDR sits on both sides of the stream: it consumes events to detect account takeover and transmits a risk level change when it has found one. In a Zero Trust architecture this is the mechanism that turns a decision made once at login into one that is revisited whenever the facts behind it change. Device Bound Session Credentials work from the other side, by making the session cookie an attacker would need harder to steal in the first place.