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.
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:
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
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.
Receivers: A receiver is an external system that Britive sends security events to. For each receiver, an admin configures:
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
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.
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:
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)
Results are retained for 90 days.
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)
An external IdP sends a security event to Britive's event endpoint as a signed JWT.
Britive validates the event came from a trusted, configured issuer.
Britive looks up the event-to-action mapping configured for that issuer.
Britive executes the mapped action on the identified user.
The result is recorded in the results log.
Sending a Signal (Outbound)
A security-relevant event occurs in Britive (e.g., a user is disabled).
Britive checks if any configured receivers have a mapping for that event type.
For each matching receiver, Britive constructs and delivers a signed security event token to the receiver's endpoint using the configured headers.
The result is recorded in the results log.