Killing Active Sessions Across the Federated Fleet

What it stops

This control stops a compromised identity from maintaining persistent access across a fleet of federated applications. When an account is flagged for compromise, the goal is to kill all active sessions and prevent new ones. It halts T1213 by removing the trust bridge between the Identity Provider and the Service Providers. This prevents an attacker from hopping from one SaaS tool to another using a single hijacked token. It limits the window of opportunity for bulk data export across connected apps, which is a common goal in T1567. Without this ability, an attacker can linger in a downstream application long after the primary account has been locked. This reduces the blast radius of a single credential theft.

What it does not stop

Many assume that killing the IdP session kills every downstream app session. This is a mistake. Most applications issue their own local session cookies after the initial SAML or OIDC handshake. These local sessions often persist regardless of the state of the federation link. An attacker with a valid Salesforce session cookie can continue to export leads even if the Okta or Azure AD account is disabled. The control does not stop an attacker who has already pivoted to a long-lived API key or a personal access token created during the breach. Vendor brochures call this "instant revocation". In practice, it is often more of a suggestion that the application may choose to ignore for several hours. This gap allows an attacker to finish a data dump while the security team believes the threat is contained.

What it looks like when it is working

Working controls produce a specific pattern in the logs. The IdP records a global session termination event for a specific user ID. Immediately after, the service provider logs show a spike in 401 Unauthorized or 403 Forbidden responses for that same identity. Telemetry shows an identity attempting to access multiple applications in short succession but failing at every gate. There is no gap where the user can still reach one app while being blocked from others. The timing between the kill command and the rejected requests is tight. This consistency indicates a functional integration rather than a series of manual tickets sent to different app owners. It proves that the session death signal has propagated through the federation chain.

How to prove it

Pick a test identity with access to three distinct federated applications, such as GitHub, ServiceNow and Zoom. Log into all three using a single browser session on one machine. At exactly 10:00 AM, execute the command to break federation or revoke all sessions for that user at the IdP level. Attempt to refresh the page or perform a data-read action in each application every 60 seconds. A pass is achieved if all three applications reject access and force a redirect back to the IdP within 300 seconds of the kill command. Record the exact timestamp of the revocation command from the IdP logs. Record the timestamp when the first rejected request occurs for each of the three apps in their respective audit logs. Calculate the difference in seconds for each application to find the slowest link.