SOC Identity Responder: contain a compromised account without handing out admin roles

When an account is compromised, the first few minutes matter. The attacker has a session and possibly a password, and the analyst who spotted it in Microsoft Defender needs to cut them off. In many organisations that analyst can't. Either they wait for someone on the identity team, or they've been given broad roles such as User Administrator or Helpdesk Administrator "just in case", which lets them change far more than they need to.

Microsoft has added a built-in role for exactly this job: Entra SOC Identity Responder, in public preview. It holds four permissions, all about containment, and it can only act on users who don't hold admin roles.

What the role can do

Microsoft describes it as a role for containment actions taken from the Microsoft Defender portal. The actions are still enforced and audited by Entra, so they show up in the audit log like any other change. The role's template ID is 58f930cc-fcf4-4152-852c-1d7dbf502139, which you can look up with the GUID lookup.

What it can't do

The limits are as useful as the permissions, because they tell you where the identity team still has to step in.

• No admin accounts. Like Security Administrator and Security Operator, the role is limited to non-administrative users and can't act on privileged accounts. A compromised admin still needs a Privileged Authentication Administrator or Global Administrator.
• No authentication methods. It can't see or remove a user's MFA methods. If the attacker registered their own Authenticator or phone number, someone with Authentication Administrator has to remove it.
• No devices, groups or apps. Disabling a device, removing group memberships or revoking app consent are separate jobs for other roles.

One detail worth knowing: Microsoft notes that the ability to reset a password includes updating the phone and alternative email properties that self-service password reset uses. That's another reason to treat it as a privileged role, which Microsoft labels it as.

How containment fits together

Order matters. Disable the account first so no new sign-ins succeed, then revoke sessions so existing refresh tokens stop working, then reset the password before you re-enable anything. Revoking sessions doesn't instantly kill access tokens that have already been issued. They run until they expire, unless the app supports continuous access evaluation, so a disabled account plus revoked sessions is the combination you want.

Setting it up properly

The role supports role-assignable groups and works with PIM, so a sensible design is an eligible assignment to a group that holds your SOC analysts.

1. Create a role-assignable security group, for example ROLE-SOC-Identity-Responders. Only Global Administrators, Privileged Role Administrators and the group's owners can manage its membership, which protects it from tampering. Don't give the SOC analysts ownership of it.
2. Make the group eligible for Entra SOC Identity Responder in PIM, rather than permanently active.
3. Set activation rules: a short maximum duration, a justification, and ideally an authentication context that requires phishing-resistant MFA. Skip approval, because waiting on an approver defeats the point of a fast containment role.
4. Remove the old roles analysts were holding for containment, once the new one is tested.

Connect-MgGraph -Scopes "Group.ReadWrite.All","RoleManagement.ReadWrite.Directory"

# Role-assignable group for the SOC
$group = New-MgGroup -DisplayName "ROLE-SOC-Identity-Responders" -MailEnabled:$false `
  -MailNickname "role-soc-identity-responders" -SecurityEnabled -IsAssignableToRole:$true

# Make the group eligible for the role for a year
New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter @{
    Action           = "adminAssign"
    PrincipalId      = $group.Id
    RoleDefinitionId = "58f930cc-fcf4-4152-852c-1d7dbf502139"   # Entra SOC Identity Responder
    DirectoryScopeId = "/"
    Justification    = "SOC containment role"
    ScheduleInfo     = @{ StartDateTime = Get-Date; Expiration = @{ Type = "AfterDuration"; Duration = "P365D" } }
}

Analysts then activate it in the portal, or from PowerShell as described in activating PIM roles with Microsoft Graph.

Containment from PowerShell

The Defender portal is the intended place to take these actions, but it's useful to have a fallback. With the role active, an analyst can do the same from Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "User.EnableDisableAccount.All","User.RevokeSessions.All"
$upn = "jane.doe@contoso.com"

Update-MgUser -UserId $upn -AccountEnabled:$false   # 1. stop new sign-ins
Revoke-MgUserSignInSession -UserId $upn              # 2. invalidate refresh tokens

Afterwards, the user sees AADSTS50057 (account disabled) if they try to sign in. To see what the attacker did before you stepped in, paste their sign-ins into the sign-in log explainer or use the queries in the KQL library.

Things to check before relying on it

• It's in public preview, so test it in your tenant before writing it into the incident runbook
• For users synced from Active Directory, check how disabling and password resets behave in your setup: attributes mastered on-premises and password writeback both affect the result
• Agree a handover with the identity team for what the role can't do: MFA methods, admin accounts, devices and app consent
• Alert on activations of the role, the same way you'd alert on other privileged roles
• Include the group in your regular access reviews