Last quarter, Expel published their annual threat report. The number that stuck with me: 68.6% of the incidents their SOC handled in 2025 were identity-based attacks. Not malware. Not exploits. Not

zero-days. Stolen credentials, hijacked sessions, OAuth abuse, and MFA bypass. More than two-thirds of all incidents started with somebody using a valid identity to walk in the front door.

I looked at our own case data afterward. The split was similar. The majority of real cases our analysts investigated last year involved compromised credentials, not compromised endpoints.

And yet. Open the average SOAR platform and look at the playbooks. Phishing response. Malware triage. Endpoint isolation. Vulnerability scan follow-up. The playbooks assume the threat comes from outside and arrives through a technical vector. They assume the attacker has to break something to get in.

The attacker doesn’t break anything. They log in.

What identity attacks actually look like in the SOC

The analyst gets an alert: “impossible travel detected.” User logged in from London at 9 AM and from Lagos at 9:47 AM. She opens the SIEM. Checks the IP. Checks the user’s login history.

Cross-references with the HR system to see if there’s a travel request. There isn’t. She escalates.

That took 25 minutes. Now multiply it by the number of identity-based alerts in your queue, which is growing because every SaaS tool you add creates new authentication surfaces, and you start to see the problem.

The SOAR platform can run a phishing playbook in its sleep. Extract the URL, detonate it in a sandbox, check the sender against a blocklist, quarantine the email. Clean, automated, done. But ask the same platform to investigate an OAuth token abuse case and it stares at you blankly. There’s no playbook for “a third-party app just granted itself read access to every file in the CEO’s Google Drive using a stale consent grant that nobody revoked.”

The playbook library wasn’t built for this category of threat. It was built for a world where the perimeter was the network edge, the attacker used malware, and the investigation centered on an endpoint. That world is gone but the playbooks haven’t caught up.

Why SOAR doesn’t handle identity well

SOAR platforms were designed around a specific investigation model. An alert fires. The playbook kicks off. It queries a set of tools, usually EDR, SIEM, firewall, and maybe a sandbox. It enriches the alert with IOCs. It makes a decision or presents the analyst with a recommendation.

This model works when the unit of investigation is an endpoint or a network event. It breaks when the unit of investigation is an identity, because identity investigations require a different data set, a different logic flow, and a different set of containment actions.

An endpoint investigation asks: what happened on this machine? The tools are EDR, disk forensics, process trees. An identity investigation asks: what did this user do across every system they have access to? The tools are IdP logs, SaaS audit trails, OAuth consent records, session management APIs, and directory services. The data lives in different places, the query patterns are different, and the containment actions, disable account, revoke tokens, force re-authentication, are different from the endpoint playbook’s block IP, isolate host, kill process.

Most SOAR platforms can technically call the APIs needed for identity investigation. They’re extensible. You can write a custom playbook that queries Azure AD, pulls OAuth grants, checks Okta logs, and revokes sessions. But “technically possible” and “well-supported” are different things. The phishing playbook ships out of the box. The identity investigation playbook is a custom build that requires your team to understand the IdP’s API, the SaaS audit log schema, and the token lifecycle, and then maintain it as those APIs change quarterly.

The three identity attacks your SOAR can’t handle

There are whole categories of identity threats where the standard playbook model doesn’t apply at all.

Credential stuffing at scale. An attacker tests thousands of stolen credential pairs against your authentication endpoint. Each individual attempt looks like a failed login. Your SIEM generates a few hundred alerts. The SOAR playbook doesn’t cluster these as a coordinated campaign because it processes each alert individually. Meanwhile, 12 of those credential pairs worked, and the attacker is now inside with valid sessions.

OAuth consent abuse. A malicious app requests permissions through a legitimate OAuth flow. The user clicks “Allow” because the prompt looks like every other SaaS authorization. The app now has read access to email, calendar, and cloud storage. No malware. No exploit. No alert from the EDR. The SOAR platform doesn’t even see it because the action happened in the IdP layer, not on an endpoint.

Session hijacking. The attacker steals a session cookie from the browser and replays it from a different device. They’re now authenticated as the user without ever entering a password or triggering MFA. The IdP thinks it’s a normal session continuation. The SOAR platform sees nothing because the session was already authenticated when it was created. The attacker browses SharePoint, downloads sensitive files, and logs out. The entire chain looks like normal user behavior to every tool in the stack.

These aren’t exotic attacks. They’re the majority of what gets through. CrowdStrike reported that 80% of breaches involve compromised identities, and the techniques are getting faster. The attacker who used to spend weeks on reconnaissance now uses automated tools that test credentials, exploit OAuth flows, and hijack sessions at machine speed.

What the SOC actually needs

The fix isn’t a better playbook library. It’s a different investigation model for identity threats.

The SOC needs to treat identity as a first-class entity, the same way it treats endpoints. That means: a risk score per user that updates continuously based on authentication patterns, access behavior, and privilege usage. An investigation workflow that starts with “what has this identity done across all systems” rather than “what happened on this endpoint.” Containment actions that are identity-native: disable the account, revoke the OAuth grants, invalidate the sessions, force step-up authentication.

And it needs to happen automatically for the vast majority of cases. A SOAR platform that can isolate a compromised endpoint in seconds but takes 45 minutes of manual work to investigate a compromised identity has the wrong priorities for a world where identities are the primary attack vector.

The SOC analysts I talk to already know this. They’ve watched the balance shift over the last two years. The endpoint cases are getting easier because the tools are mature. The identity cases are getting harder because the tools aren’t. They’re manually stitching together Azure AD logs, Okta event streams, Google Workspace audit trails, and SaaS-specific admin panels to build a picture that their SOAR platform should be assembling for them.

The SOAR platform that figures out identity-native investigation and response will win the next five years of this market. The ones that keep shipping phishing playbooks and calling it innovation will wonder why their customers’ SOC teams are still drowning, even though the endpoint side of the house has never been more automated. The perimeter moved. The playbooks didn’t. That’s the gap