Notifications
Clear all
Topic starter
25/06/2026 10:28 pm
TL;DR: Live identity risk, service account records, and authentication policy changes are now being brought into SOC playbooks through Silverfort’s integration for Google Security Operations, including enforcement on legacy protocols such as NTLM, Kerberos, and LDAP, according to Silverfort. That matters because identity context and response controls are now collapsing into one workflow, making identity the operational layer SOC teams can no longer leave outside incident response.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should security teams use identity risk in SOAR playbooks?
A: Security teams should use identity risk as a triage and containment signal inside the playbook, not as a separate manual lookup.
Q: Why do service accounts remain hard to govern from the SOC?
A: Service accounts remain hard to govern because their ownership, usage, and policy state are often split across tools and teams.
Q: What breaks when identity policy cannot be changed from the response case?
A: When identity policy cannot be changed from the response case, containment depends on a second workflow that often lags behind the alert.
Practitioner guidance
- Map identity actions to playbook stages Identify which response steps need live risk enrichment, which need service account lookups, and which can actually change policy state.
- Scope automation credentials by function Use distinct app-user credentials for risk reads, service-account actions, and policy writes.
- Define legacy-protocol containment criteria Pre-approve when playbooks may tighten NTLM, Kerberos, or LDAP authentication state during an incident, and record the decision in the case timeline.
What's in the full announcement
Silverfort's full article covers the operational detail this post intentionally leaves for the source:
- Action-by-action integration setup for the Google Security Operations connector
- API family breakdowns for Risk, Service Accounts, and Policies operations
- Playbook examples showing how response actions map to authentication containment
- Minimum configuration fields and validation steps for the connector instance
👉 Read Silverfort's integration guide for Google Security Operations identity response →
Identity risk in SOAR playbooks: what should IAM teams change?
Explore further
25/06/2026 11:01 pm
Identity response is no longer a separate workflow from SOC response. When identity risk, service account posture, and enforcement state are exposed inside the same playbook, the old separation between detection and identity administration starts to break down. That does not make identity governance easier, but it does make the SOC the place where identity control finally becomes executable.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, and a quarter encountered multiple attacks.
A question worth separating out:
Q: Who should approve automatic identity containment actions in SOC workflows?
A: Automatic identity containment actions should be approved by the team that owns both incident response and identity policy governance, with clear limits on which actions can execute without extra review. The key is to predefine authority before an incident, not improvise it mid-case.
👉 Read our full editorial: Identity risk inside SOC playbooks changes NHI response models
