In our last post on closed-loop remediation, we made the case that detection without action is just documentation. Group removal is the most precise of those actions. It takes back access a person no longer needs without touching the account, the badge, or the paycheck.
But a group membership is never just a membership. It’s a doorway. Behind it sit applications, admin consoles, permission sets, and the data those permissions reach. Remove someone from a group and you change what they can touch across every system that trusts that group. Sometimes that change is exactly what you wanted. Sometimes it takes away the one admin path an attacker was waiting to use. And sometimes it locks a developer out of production on release day.
The problem is that the group name tells you none of this. “IT Admins” sounds obvious. “Antonio Test Group 11” doesn’t, and in the demo below it leads straight to two quarterly finance reports. You can’t judge a removal by its label. You have to see what’s on the other side of the door.
Remediation you can’t preview is a guess. And guessing is the wrong posture for the one control that decides who reaches your most sensitive systems.
Privilege lives in groups, and attackers know it
Most standing privilege doesn’t arrive one grant at a time. It arrives through group membership, nested and inherited, until nobody can say from memory what a single group actually unlocks. That is exactly why adversaries spend so much effort on groups.
The super admin role is one group away
In the summer of 2023, Okta warned customers about a campaign in which callers talked IT service desk staff into resetting MFA for highly privileged users. Once inside, the attackers used Super Administrator access to grant higher privileges to other accounts, reset authenticators on existing admins, and in some cases strip second-factor requirements from authentication policies. Okta’s recommendation included reviewing and limiting who holds Super Administrator roles. That review is a group removal exercise. Getting it right means knowing which memberships lead to the admin console and which ones don’t.
The forgotten path is the one that gets used
In January 2024, Microsoft disclosed that the nation-state actor Midnight Blizzard password-sprayed its way into a legacy, non-production test tenant account with no MFA. From there the actor found a legacy test OAuth application with elevated access to the corporate environment and used it to reach corporate mailboxes. The account that let them in looked harmless. The access hanging off it did not. Indirect, inherited, long-forgotten paths are where real exposure hides, and they are invisible if all you look at is the first hop.
Persistence by membership
MITRE ATT&CK catalogs Additional Local or Domain Groups as a named persistence and privilege escalation technique: adversaries add accounts they control to privileged groups so they keep access even after defenders rotate a password or close the original foothold. When you respond, you have to remove the right memberships, all of them, and confirm the privileged paths are actually gone. Pull the wrong group and the attacker keeps the door. Pull too many and you take your own responders offline.
The fix that locks out the responders
Action without visibility hurts defenders too. In October 2021, a command meant to assess backbone capacity took Facebook’s entire network offline. The audit tool designed to catch that kind of mistake had a bug and let it through, and the outage cut off the internal tools engineers needed to fix it. Identity changes carry the same risk. Revoke a membership without seeing its dependencies and you can remove an on-call engineer’s admin path in the middle of an incident.
The lesson isn’t to remove less. Standing privilege is the largest driver of identity blast radius, and it has to come down. The lesson is that every removal has a blast radius of its own, and you should see it before you commit, not after the help desk calls.
Blind remediation fails in both directions
Removing group access without a preview tends to fail one of two ways. Both come from the same root cause: acting without seeing the consequence.
|
When you remove without a preview |
What goes wrong |
What a preview gives you |
|
You remove too little |
A second group still grants admin access, so the attacker’s path survives |
Every app and resource the selection actually cuts, so you know the path is closed |
|
You remove too much |
A legitimate engineer loses production access and the business learns to route around security |
What survives through other groups, so you keep the access people need |
|
You can’t explain the change |
Auditors and incident reviewers see an action with no rationale |
A required note and a log entry tied to each membership removed |
|
You can’t scope it at scale |
Thirty users across 140 groups becomes a spreadsheet exercise |
One view of every user, every group, and the downstream impact of each choice |
What’s new: Impact Preview for Remove User from Groups
Remove User from Groups now opens into an Impact Preview. Before a single membership changes, you see exactly what access each user will lose, traced across the Veza Access Graph from the group through to applications, roles, permissions, and resources. You change the selection, the preview updates, and you commit only when the blast radius is the one you intend.
Start from the query you trust
Remediation starts where the finding lives. In the demo, the Okta User to Okta Group query returns 264 Okta users. Select the ones you want to act on, open Remediate Selected, and choose Remove User from Groups, listed under Automatic actions that run with guardrails.
Thirty users selected from query results, with Remove User from Groups under Automatic actions.
See every membership you’re about to cut
The Impact Preview opens with the full scope at the top: in this case, removing 30 users from up to 142 groups. Each user expands to show every group membership in play, so you can keep or drop individual memberships instead of treating a person as all-or-nothing.
Select a user and the graph draws what that removal does. For agarraway@veza.com, removing both the Everyone and IT Admins groups cuts access to three Okta apps: GitHub Enterprise Cloud, GitHub Enterprise Server, and the Okta Admin Console, plus an unconstrained Okta resource. Red paths show access that goes away. Muted nodes show access that stays.
The graph traces each selected membership to the apps and resources the user will lose.
The banner above the graph summarizes the impact in plain language. Choose See More for the full list, grouped by resource type.
A one-glance answer to the question every approver asks: what exactly will this person lose?
Change the selection, watch the blast radius change
This is where the preview earns its place. Uncheck the Everyone group and keep only IT Admins. The graph recalculates instantly. Now the removal cuts the Okta Admin Console and the unconstrained resource, while both GitHub apps stay reachable through Everyone.
That is the surgical move security teams want and rarely get to make with confidence: take away the admin path an attacker would target, and leave the developer access the person needs to do their job.
Removing only IT Admins strips the admin console path while GitHub access survives through another group.
Follow access all the way to the data
Group names rarely tell the whole story. Here, akamber.okta@vezatest.com belongs to 137 groups. Selecting three of them shows a path that runs from Antonio Test Group 11 through a custom application, into Manager and Viewer roles, through read, write, and delete permissions, and down to individual Q1 and Q2 reports.
No reviewer would guess that from the group name. The graph shows it in seconds. When you need to go deeper, Open in Graph Builder takes the same context into a full investigation. For large selections, Name and Group filters narrow the list so you can focus on the memberships that matter.
The preview follows access past the app layer to roles, permissions, and the specific reports a removal protects.
Commit with a reason, guardrails attached
The Remove from Groups button stays disabled until you’ve selected the memberships and written a note. The note is mandatory because every access change should carry its rationale. Active Guardrails stay visible throughout, starting with full auditability, so every action is attributed and timestamped. Once you commit, a confirmation tells you how many memberships are being removed and points you to the log for status.
Every removal lands in the Remediation Log
Each membership removed writes to the unified Remediation Log on the query: when it was requested, who requested it, its status, the note, the entity, and the action type. The same log records every other remediation action in Access Intelligence, so an auditor or incident responder has one place to see what changed and why.
One searchable record of every removal, with attribution, status, and the reason behind it.
How this strengthens your identity security posture
You close the right door. The preview shows whether a removal actually cuts the privileged path, so attacker access doesn’t survive through a second group you didn’t check.
You keep the business running. Access that survives through other memberships is visible before you commit, so legitimate work doesn’t break and people don’t learn to route around security.
You remediate faster, not slower. Confidence removes the hesitation. When you can see the outcome, you stop parking removals in a ticket queue waiting for someone to map dependencies by hand.
You see the data, not just the app. Tracing access to roles, permissions, and individual resources turns least privilege from a group-cleanup chore into real data protection.
You can defend every change. A required note, visible guardrails, and a unified log mean every removal holds up in front of an auditor, a regulator, or a post-incident review.
You scale precision. Thirty users, a hundred and forty groups, one view. Precision no longer depends on how much time a reviewer has.
Where this is going
Impact Preview reflects a principle we’re building into every remediation action in Access Intelligence: you should see the consequence of an access change before it happens, on the same graph that found the risk.
As part of ServiceNow, we’re extending that preview-first model across the remediation toolkit, so every action, from right-sizing a membership to containing a compromised account, comes with a clear view of its blast radius. Fast should never mean blind.
Try it today
Open a query that surfaces risky group memberships, select the users you want to right-size, and choose Remove User from Groups. Toggle memberships on and off and watch the graph show you what changes. Commit only when the access you’re removing is the access you meant to remove.
Every group removal changes a blast radius. Make sure it’s the attacker’s, not yours.
About the author
