Security Orchestration Automation and Response (SOAR)

Security Orchestration, Automation, and Response (SOAR) turns a security alert into executed actions: it opens a case, gathers context, and runs a playbook that acts on other systems through connectors, pausing for an analyst where a step needs a human. For identity incidents, the playbook is the IAM team's containment procedure written down in executable form: which sessions and tokens to revoke, which credentials to rotate, which changes an attacker made to undo, and which of those steps wait for approval. A playbook can only contain an identity incident as far as the identity systems let it act, and the automation account that can disable any user is itself one of the most privileged identities in the estate.

Containing an Account Takeover

Resetting the password is the step everyone remembers, and on its own it evicts almost nobody. An attacker with a stolen session or a refresh token keeps working, and one who has been in for a day has usually added a way back in. A takeover playbook has to work through the stages in order, because each one assumes the earlier ones are done.

The first step ends what is already running. Revoking the user's sessions and refresh tokens at the identity provider stops new tokens from being issued, but it does not end the sessions that applications keep themselves, and a self-contained access token stays valid until it expires unless the resource server checks it. RFC 7009 allows an authorization server to revoke the related access tokens when a refresh token is revoked, but does not require it. Reaching the applications takes a second channel: a session-revoked event under the Shared Signals Framework (SSF) Continuous Access Evaluation Profile (CAEP), or OpenID Connect back-channel logout for applications that support it. The playbook should record which applications confirmed the revocation, because the incident is only contained when the last one has.

The second step removes what the attacker added. That means authenticators registered during the compromise, which MITRE ATT&CK lists as Device Registration (T1098.005), and OAuth consent grants to applications the attacker controls. It also covers mail forwarding rules, credentials added to application registrations (T1098.001), and any role the account gained. The SIEM supplies that list: every change the account made or received since the first suspicious event. Only then does a credential reset help, and it should be followed by a fresh enrolment with a phishing-resistant factor such as a passkey, so the recovery does not reopen the channel the attack came through.

Whether to disable the account is a separate decision. For a single user it costs little. For a shared mailbox owner, a service account or an executive in the middle of a transaction, disabling can do more damage than the attacker, and revoking sessions while the account stays enabled under heightened monitoring is often the better containment.

Rotating Machine Credentials Without an Outage

When the compromised identity is a machine, a leaked API key, a database password or a workload's client secret, the response is rotation, and the order is the reverse of a human account. Revoking first breaks every system that uses the credential legitimately. The safe sequence issues a new credential, delivers it to each consumer, confirms the consumers use it, and only then revokes the old one, and it needs the issuing system to accept two valid credentials during the overlap. Where the credential lives in privileged secret management, the playbook calls the vault, which knows the consumers and can rotate them together. Where it does not, the playbook first has to find out who uses it, and a credential nobody has inventoried cannot be rotated quickly by anyone. That is the practical case for bringing non-human identities under management before an incident rather than during one.

Workloads that authenticate with short-lived tokens obtained through federation change the step. There is no stored secret to rotate, so the playbook removes or narrows the trust relationship that lets the workload obtain tokens, and the tokens already issued expire within minutes. For an AI agent, the agent registry names the owner to notify and the credentials to revoke.

Privileged Access During an Incident

Privileged access gives a playbook three more actions. It can end a live privileged session through session management, which also preserves the recording as evidence. It can rotate a vaulted privileged password that was checked out during the suspicious window. And it can withdraw any just-in-time elevation still in force. The last one needs verification: as the Zero Standing Privileges article argues, an elevation withdrawn in the request system can survive in the target system, so the playbook should confirm that the assignment is gone from the target and not only that the request was closed.

Where the Playbook Stops and Asks

Deciding which steps run automatically and which wait for a person is the design decision in an identity playbook, and two properties settle most cases: whether the action can be undone, and how many identities or systems it touches. Revoking one user's sessions is cheap and reversible, because the user signs in again, so it can run the moment a detection fires. Raising the user's risk level or forcing a step-up at the next sensitive operation falls into the same class. Disabling a privileged account, a break-glass account or a service account that production depends on is not cheaply reversible, and neither is removing a federation trust or rotating a credential shared by many systems. Those steps wait for approval.

Volume needs its own limit. A detection rule that misfires, or an attacker who knows the rule, can make a playbook lock out hundreds of accounts in a minute, and the organization ends up doing the attacker's work. A threshold on how many accounts one playbook may act on per hour, beyond which it stops and asks, keeps a flawed rule from becoming a self-inflicted outage.

The approval is itself an authentication event. The approver should confirm on a registered device with a phishing-resistant factor, and see what exactly is being approved, for which account and in which case, which is the ceremony Client-Initiated Backchannel Authentication (CIBA) standardizes. The case then records who approved which step and when. That record is what an auditor asks for after a destructive action, and what the analyst on the next shift needs when a disabled executive calls.

The Governance System Can Undo the Response

A response that edits the directory directly can be reversed without anyone deciding to. Identity governance reconciles target systems against the access it believes each identity should have, and SCIM provisioning pushes the same state to applications. A group membership the playbook removed will be re-granted at the next reconciliation, and an account it disabled may be re-enabled by the next synchronization from the HR system. The playbook has to act through the governance system, or mark the identity there as suspended, so that the desired state changes along with the actual one.

The same record makes recovery possible. When an incident turns out to be a false positive, or the account is clean again, the playbook needs to restore what it removed, which means it must have written down the prior state before it acted. Every action, with its case reference, the prior state and the outcome, goes back to the SIEM, so that the incident's timeline shows the response as well as the attack.

The Automation's Own Identity

The connectors of a SOAR platform hold credentials for the identity provider, the directory, the vault, the governance system and the cloud accounts, which makes the platform one of the most privileged non-human identities in the organization. A compromise of it is a compromise of everything it can act on. Its permissions should cover the response actions its playbooks take (revoke, disable, rotate, suspend) and not the administrative rights that happen to include them, such as creating accounts or assigning roles. Its credentials belong in the vault, and where the target systems allow it they should be short-lived tokens rather than static API keys. Its own actions belong in the SIEM under a dedicated identity, not a shared administrator account.

Playbooks deserve the treatment Policy as Code gives to authorization policy. A playbook decides who is locked out and when, so changes to it need review, versioning and a test against past incidents before release, and the right to change it is privileged access. Where playbooks have to be exchanged or outlive a platform change, OASIS Collaborative Automated Course of Action Operations (CACAO) Security Playbooks 2.0 (Committee Specification, 2023) is the vendor-neutral format, including steps a person performs.

Identity Threat Detection and Response (ITDR) and the SIEM decide that something has happened. Some ITDR tools also carry out identity responses themselves, and where they do, the rules above apply to them in the same way. What matters is that each response action runs in one place, under one set of approval rules, and leaves one record.