Shared Signals and CAEP: ending a leaver's live sessions, not only the account

Leaver processes are usually measured by one timestamp: when the directory account was disabled. That covers new authentications. It does not cover what was already issued, such as a session in a SaaS application, a refresh token held by a mobile client, or an API token used by a script. Those persist until they expire or until the application is told to end them.

For applications the directory does not front at all, including local accounts in disconnected applications, the directory action changes nothing. The disconnected applications guide covers that case separately.

NIST SP 800-53 AC-2 (h) asks organizations to notify account managers when users are terminated or transferred, and AC-2 (l) asks them to align account management with personnel termination and transfer processes. Security events sent between systems are one way to do that notification within minutes rather than by ticket.

The OpenID Foundation's Shared Signals Working Group maintains three related specifications.

For a leaver, the useful events are CAEP Session Revoked, which tells a receiving application to end the person's session, and RISC account disabled, which tells it the account is no longer valid.

NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse, was published as final on 15 September 2026 by authors from NIST, CISA and Accenture Federal Services. Its stated audience is federal agencies and cloud service providers, and it covers key management, token verification and lifecycle controls. The OpenID Foundation noted on 16 September 2026 that the report recommends SSF and CAEP.

For a private-sector program it is guidance, not an obligation. It is still a clear public statement that continuous evaluation belongs in token lifecycle controls, and a useful reference when an auditor asks how quickly a leaver's access actually ended.

1. The HR event starts the leaver workflow in the IGA.
2. The directory account is disabled.
3. The system acting as transmitter, typically the identity provider, sends events to every application registered as a receiver.
4. Receiving applications end sessions and revoke tokens for that person.
5. Applications that are not receivers, and local accounts anywhere, still need a direct removal step or a ticket. Confirm with a fresh account pull, as in the joiner-mover-leaver process.

Signals only reach applications that implement a receiver. List which of your critical applications do, and keep the others on the explicit removal path.

• Does the product act as an SSF transmitter, a receiver, or both, and for which events?
• Which of our critical applications can receive CAEP Session Revoked today?
• What happens to local accounts in applications that cannot receive signals?
• Is each signal, and the action it caused, logged as audit evidence?

Shared Signals support is not part of this site's scoring rubric. The editorial method lists the criteria we score.