Beyond the Login: A Guide to the Shared Signals Framework
As security professionals, we understand the gap between detection and response can be frustrating. An event happens on an endpoint, but our identity platform doesn’t know about it. A user’s risk profile changes, but their session token is still valid for another hour. We’re stuck playing catch-up, trying to stitch together siloed systems with brittle, custom APIs.
Traditional authentication is a point-in-time gate. Once the user is in, our visibility into their session’s ongoing health is often limited. But what if our security tools could talk to each other in real-time, using a common language? That’s the promise of the Shared Signals Framework (SSF). Let’s break down what it is and why it’s a game-changer.
A Biological Blueprint: The Body’s Nervous System
Imagine your IT infrastructure is a human body—a complex system designed to function, thrive, and protect itself from harm.
The Brain (as the IDP, e.g. Okta): This is the central command center. It manages identity, makes high-level decisions, stores memories (logs), and coordinates complex actions.
Pain Receptors (as the EDR): These are specialized, distributed sensors. The nerve endings in your skin are highly attuned to detect specific, localized threats like extreme heat or sharp pressure. They are your endpoint detection agents.
The Immune System (as ZTNA, e.g. Zscaler): This system monitors everything flowing through the body like the bloodstream, the lymphatic system. It detects internal threats like viruses (malware in traffic) or toxins (data exfiltration attempts) that the skin receptors would never see.
The Nerve Impulse (as the SSF Signal): This is the standardized, lightning-fast electrochemical signal that communicates “Danger!” It’s the Security Event Token (SET).
Now, imagine you get sick.
The In-Transit Threat (an illness): When you’re feeling sick, your Immune System (Zscaler) detects a virus in your bloodstream (malware traveling on your network) as it tries to travel to a vital organ. It identifies the threat based on its signature and sends an urgent signal to the brain.
The Central Response (Coordinated, IDP-driven Action): The Brain (Okta) receives this signal from the system. Now the central processor has the information it needs to take action. To fight the virus in your body, your brain will take system-wide action: It raises the body’s temperature to fight the virus (escalates the security posture), floods the bloodstream with white blood cells, instructing them to find and neutralize that specific virus signature (tells Zscaler to block all traffic associated with that malware), and registers the new disease as new threat and to attack on sight (a new, enriched security policy is created). The IdP could also take actions by forcing step-up MFA
The Technical Foundation: Unpacking CAEP and SETs
The magic of those “silent signals” is built on open standards from the OpenID Foundation.
Continuous Access Evaluation Protocol (CAEP): This is the core protocol defining the “how.” CAEP (pronounced “cape”) specifies the event types and the JSON-based structure for the signals themselves. It’s the playbook that gives the signals their meaning.
Security Event Tokens (SETs): The signal itself is a JSON Web Token (JWT). A SET (RFC 8417) is a specialized JWT designed for security events. It contains standard claims like issuer (iss) and subject (sub), but its payload is the events claim.
The events Claim: This is where the action is. It’s a JSON object holding a URI for a specific CAEP event, such as:
…/session-revoked
…/credential-change
…/risk-incident
…/assurance-level-change
The Architecture: Transmitters, Receivers, and the Signal Stream
The framework operates on a standardized pub/sub model with two main roles:
Signal Transmitter (Publisher): Any entity that observes a state change and publishes a SET. This could be your EDR/XDR platform detecting malware, your SSE platform like Zscaler flagging data exfiltration, or your IDP noting a password spray attack.
Signal Receiver (Subscriber): Any entity that subscribes to signals and can act on them. This is your IDP ingesting a risk signal, a critical SaaS application terminating a session, or an ZTNA platform like Zscaler receiving a command to block a now-compromised user.
This communication flows over a secure Signal Stream, creating a real-time bus for security events.
The IDP as a Central Hub: The Okta Example
An IDP like Okta is uniquely positioned to act as the central hub or broker in this architecture by both receiving and transmitting signals.
Okta as a Signal Receiver
Here, Okta consumes signals to make smarter policy decisions.
Scenario: A user authenticates via Okta. Minutes later, Zscaler (a Transmitter) detects that the user is attempting to upload sensitive corporate data to an unsanctioned personal cloud storage account.
Mechanism:
Zscaler generates a SET with the user’s ID detailing the DLP violation.
It pushes this SET to the signal stream that Okta is subscribed to.
Okta (the Receiver) ingests and validates the SET.
Based on policy, Okta takes immediate action: revoking all of the user’s sessions, forcing them into a limited-access state pending investigation, or adding them to a high-risk group with limited permissions.
Okta as a Signal Transmitter
Okta can also broadcast signals based on events it observes.
Scenario: An administrator explicitly revokes a user’s sessions from the Okta console after a phishing alert
Mechanism: Okta (the Transmitter) generates a SET with a session-revoked event and pushes it to downstream receivers, including Zscaler, instructing it to immediately terminate the user’s internet access and block their credentials at the network edge.
A New Era of Unified Security
Ultimately, the Shared Signals Framework represents an evolution in post-authentication security. By creating a standardized, vendor-agnostic communication bus, SSF breaks down the silos that have long existed between our endpoint, network, identity, and cloud tools. This interoperability is the key to enabling a true Zero Trust architecture, transforming the IDP from a static gatekeeper at login, into a dynamic policy enforcement hub for the entire user session. The more ZTA components – such as EDR, data security, SIEM – that can communicate via SSF means even better interoperability and faster response times. The most critical outcome of this shift is the drastic reduction in remediation time. Instead of waiting hours for a token to expire, we can now act on credible threat signals in near-milliseconds. This framework allows our entire security stack to finally operate as one cohesive, intelligent, and responsive team, building a more adaptive and resilient defense against modern threats.
