---
title: "Shared Signals Framework"
slug: "shared-signals-framework"
updated: 2026-05-08T11:45:34Z
published: 2026-05-08T11:45:34Z
canonical: "docs.britive.com/shared-signals-framework"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.britive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Shared Signals Framework

The Shared Signals Framework (SSF) is an industry standard for exchanging security signals between systems and applications such as IdPs. It allows organizations to share real-time security events, for example, “this user's session was revoked” or “this account was disabled”, across systems automatically. For more information about SSF, see [Shared Signals Framework Specification](https://openid.net/specs/openid-sharedsignals-framework-1_0.html).

Britive supports two directions:

- Receiving signals (inbound): Britive listens for security events from external IdPs (such as Okta or Azure AD) and automatically takes action on the affected user.
- Sending signals (outbound): When security-relevant events happen in Britive, Britive can notify external systems (such as a SIEM or an IdP).

Standards Britive implements:

| Standard | What it covers |
| --- | --- |
| CAEP (Continuous Access Evaluation Profile) | Session revocation, credential changes, authentication assurance changes |
| RISC (Risk Incident Sharing and Coordination) | Account lifecycle events (disabled, enabled, deleted) |
| SET (Security Event Token) | The JWT-based format used to carry security events |

## Terminology

- **Transmitters**: A transmitter is an external identity provider that sends security events to Britive. For each transmitter, an admin configures:

Example**:** An admin registers their Okta tenant as an issuer and maps the "session revoked" event to the "Force Logout" action. When Okta sends a session-revoked signal for a user, Britive automatically logs that user out.
  - Issuer's URL (used to identify and verify incoming events). Once an issuer is created, its URL cannot be changed. To use a different URL, delete and re-create the issuer.
  - Which security events from that issuer should trigger which Britive actions
- **Receivers**: A receiver is an external system that Britive sends security events to. For each receiver, an admin configures:

Example**:** An admin registers a SIEM as a receiver and maps the Britive "Disable User" event to the RISC "account-disabled" signal. When Britive disables a user, the SIEM is automatically notified.
  - Endpoint URL where Britive will deliver events
  - Optional custom HTTP headers (e.g., an Authorization token), stored securely and never shown in plaintext
  - Which Britive events should be sent to that receiver, and which standard event format to use
- **Event Mappings**: Mappings define the translation between Britive actions and external standards.
  - Issuer mappings**:** When I receive “this external event”, take “this Britive action”
  - Receiver mappings**:** When “this Britive event*”* occurs, send “this standard event*”* to the receiver
- **Results**: Every processed event, both received and sent, is logged with the following:

Results are retained for 90 days.
  - The event type and subject (user)
  - The action taken
  - Whether it succeeded or failed
  - Timestamps and direction (received from an issuer, or transmitted to a receiver)

## Britive Actions

When Britive receives an inbound security event, it executes one of three **Britive actions** on the identified user. Actions are cumulative; each more severe action includes everything the less severe action does.

| Action | Description | Severity |
| --- | --- | --- |
| Force Checkin | Revokes all of the user's currently active privileged access sessions (profile/PAP check-outs). The user loses active access but can re-authenticate and check out again normally. | Least severe |
| Force Logout | Everything in Force Checkin also invalidates all active authentication sessions. The user is fully logged out and must re-authenticate. | Moderate severe |
| Disable User | Everything in Force Logout, plus it disables the user account. The user cannot log in until an administrator re-enables the account. | Most severe |

### Timing note

After a Force Logout or Disable User action, authentication sessions are terminated immediately. However, due to caching in the API layer, a user may retain access for up to approximately 60 seconds. This is expected platform behavior.

### Recommended Mappings

| If the external IdP sends | Recommended Britive action |
| --- | --- |
| Session revoked (caep/session-revoked) | Force Logout |
| Account disabled (risc/account-disabled) | Disable User |
| Credential compromised (risc/credential-compromise) | Force Logout or Disable User depending on severity preference |
| Credential changed (caep/credential-change) | Force Logout |

## Supported Security Events

These are the standard CAEP and RISC event types that Britive supports. Admins select from this list when configuring issuer mappings (inbound) or receiver mappings (outbound).

### CAEP Events

| Event Name | Description |
| --- | --- |
| Session Revoked | A user's session has been terminated by the IdP |
| Credential Change | A credential (password, key, or MFA device) was changed |
| Token Claims Change | The claims associated with a token have changed |
| Assurance Level Change | The authentication assurance level changed (e.g., MFA enrolled or removed) |
| Device Compliance Change | A device's compliance status changed |

### RISC Events

| Event Name | Description |
| --- | --- |
| Account Disabled | A user account was disabled |
| Account Enabled | A user account was re-enabled |
| Account Purged | A user account was permanently deleted |
| Account Credential Change Required | The user must change their credentials |
| Credential Compromise | A user's credential was compromised |
| Identifier Changed | The user's identifier (e.g., email) changed |
| Identifier Recycled | An identifier was reassigned to a different user |
| Sessions Revoked (deprecated) | All sessions for a user were revoked, use CAEP Session Revoked instead |
| Opt In | The user opted in to sharing |
| Opt Out Initiated | User-initiated opt-out |
| Opt Out Cancelled | User cancelled opt-out |
| Opt Out Effective | User opt-out is in effect |
| Recovery Activated | Account recovery was activated |
| Recovery Information Changed | Account recovery information was changed |

## Britive Event Types for Outbound Signals

These are the Britive events that can be sent to external receivers. Admins select from this list when configuring receiver mappings.

| Britive Event | Display Name | Typical Signal Type |
| --- | --- | --- |
| user.disable | Disable User | Account Disabled (RISC) |
| user.enable | Enable User | Account Enabled (RISC) |
| user.delete | Delete User | Account Purged (RISC) |
| admin.reset.password | Admin Reset Password | Credential Change (CAEP) |
| user.self.update.password | User Updated Password | Credential Change (CAEP) |
| admin.reset.mfa.device | Admin Reset MFA | Credential Change (CAEP) |
| mfa.registration.completed | MFA Enrolled | Assurance Level Change (CAEP) |
| mfa.registration.deleted | MFA Removed | Assurance Level Change (CAEP) |
| mfa.registration.admin.deleted | Admin Removed MFA | Assurance Level Change (CAEP) |
| authentication.logout | User Logged Out | Session Revoked (CAEP) |
| admin.access.checkin.all | Force Checkin All | Session Revoked (CAEP) |
| api.token.create | API Token Created | Credential Change (CAEP) |
| api.token.revoke | API Token Revoked | Credential Change (CAEP) |
| service.identity.disable | Disable Service Identity | Account Disabled (RISC) |
| service.identity.enable | Enable Service Identity | Account Enabled (RISC) |
| service.identity.delete | Delete Service Identity | Account Purged (RISC) |

**Note:** The "Typical Signal Type" column shows the natural mapping. Admins can configure any Britive event to any supported CAEP/RISC event URI.

## How It Works

### Receiving a Signal (Inbound)

1. An external IdP sends a security event to Britive's event endpoint as a signed JWT.
2. Britive validates the event came from a trusted, configured issuer.
3. Britive looks up the event-to-action mapping configured for that issuer.
4. Britive executes the mapped action on the identified user.
5. The result is recorded in the results log.

### Sending a Signal (Outbound)

1. A security-relevant event occurs in Britive (e.g., a user is disabled).
2. Britive checks if any configured receivers have a mapping for that event type.
3. For each matching receiver, Britive constructs and delivers a signed security event token to the receiver's endpoint using the configured headers.
4. The result is recorded in the results log.