Security teams have never been better at seeing risk. We have graphs, scores, dashboards, and alerts that surface dormant accounts, orphaned identities, over-permissioned users, toxic access combinations, and privilege anomalies across every system we run. Visibility is no longer the hard part.
Acting on what we see is.
Walk into most identity programs and you'll find the same quiet failure. The findings are known. The risky accounts are named. The reports are current. And the risk is still open, because between seeing it and fixing it sits a wall of tickets, approvals, module switches, and handoffs to another team that may or may not get to it this quarter. Detection has raced ahead. Remediation has been left behind. When the two are that far apart, all that visibility becomes documentation: an accurate, timestamped record of risks we knew about and didn't close.
That gap is where breaches live. Attackers don't exploit the risks we can't see. They exploit the ones we saw, logged, and never got around to fixing.
The Remediation Problem Nobody Wants to Name
There's a second, subtler reason identity risk stays open: the only fast action most teams have is the wrong size for the problem.
Ask a security engineer what they can do the moment they find a risky identity, and the honest answer is usually “disable the account.” That's the blunt instrument. It's decisive, and it's often completely disproportionate to the actual risk. So one of two things happens.
The team overreacts. They disable an account that was mostly legitimate, break someone's access, generate a help desk escalation, and teach the business that security is the department that shuts things off. Trust erodes, and the next remediation gets slower because now there's a review process wrapped around it.
Or, far more commonly, the team does nothing. The finding is real but the fix feels too heavy, so it goes into a queue, becomes a ticket, waits for a change window, and sits open. Mean time to remediate stretches from hours into weeks. The risk ages. The window stays open.
This is the trap of all-or-nothing remediation. Most identity risk isn't binary. An over-permissioned user is a legitimate person carrying access they no longer need. A stale SharePoint grant is one forgotten permission on one site, not a reason to deactivate anyone. A possibly-compromised account needs containment right now and its state preserved for investigation, not demolition. When the only quick tool is the nuclear one, teams either cause damage or accept risk. Neither is security.
The Principle: Match the Fix to the Risk
Effective remediation is proportionate remediation. The right response is the smallest safe action that closes the specific risk in front of you, taken the moment you find it, in the same place you found it.
That means a real toolkit, not a single hammer. Right-size access when someone has too much. Cut a single exposure when one grant is the problem. Contain instantly and reversibly when you suspect compromise. Deactivate outright only when the account truly shouldn't exist. And it means doing all of that inside the visibility workflow, not by exporting a list and starting a second journey in another tool, because every context switch is time the risk stays open and another chance for a copy-paste mistake.
This is the standard we've built toward in Access Intelligence. Today it takes a meaningful step forward.
What's Now Available
We've expanded direct, in-query remediation with three new actions that sit alongside the Disable Accounts capability we introduced earlier. Together they turn a single response into a graduated one.
Remove User from Groups
Over-provisioning almost always arrives through group membership. A user gets added to a group for a project that ended, a role they've moved on from, or an access need that expired, and the membership is never revoked. The person still belongs at the company. The access doesn't belong to them anymore.
Remove User from Groups lets you strip a specific membership straight from your query results, right-sizing access without disrupting the account. This is the action for enforcing least privilege, breaking up toxic access combinations, and resolving separation-of-duties conflicts by removing one side of the conflict rather than deactivating a productive employee. You reduce standing privilege, which is the single largest driver of identity blast radius, without a single help desk ticket.
Remove User from Groups joins the Remediate menu as an automatic, guardrail-governed action, right beside the query results.
Remove Direct User from SharePoint Sites
Direct user grants on SharePoint sites are one of the most persistent and least-managed sources of data exposure in the enterprise. Access gets assigned to an individual directly, outside of any group, usually for a one-time need, and it never comes back off. These grants accumulate silently into a sprawl that no group-based review will ever catch.
Remove Direct User from SharePoint Sites targets that exposure precisely. From a query surfacing direct access to sensitive or over-shared sites, you remove the individual grant while leaving the user's legitimate group-based access untouched. This is remediation reaching past identity systems into the collaboration data where real exposure lives, closing the kind of gap manual review never gets to at scale.
A query surfacing SharePoint users with direct site access, with Revoke Direct Access available inline.
Safety conditions are validated and a granular preview shows exactly what will be affected before anything commits.
Execution is gated by active guardrails, full auditability, and a mandatory note capturing the reason.
Suspend User Accounts in Okta
Suspend is the containment action, and it's built for speed and reversibility. Suspending a user in Okta blocks authentication immediately while preserving the account, its group assignments, and its app assignments.
When you suspect a credential is compromised, when an account is behaving anomalously, when someone is under investigation or on extended leave, you need to stop access now and keep the ability to restore cleanly later. Suspend does exactly that. It shrinks attacker dwell time from whenever-the-ticket-clears to right now, and because it's fully reversible, it lowers the stakes on acting fast. Fast, reversible containment is how you break the hesitation that leaves risk open.
Okta users in a LOCKED_OUT state, with Suspend Accounts available directly from the query as an automatic action.
How This Enhances Your Security Posture
Graduated remediation isn't a convenience feature. It changes the security math.
It collapses mean time to remediate. When the fix lives inside the query, finding and closing a risk become one motion instead of a multi-week workflow. Risk that used to age in a queue gets resolved on discovery.
It drives real least privilege. Group removal makes right-sizing access something you actually do at scale, not an aspiration you review once a year. Standing privilege is the largest lever on blast radius, and now you can pull it precisely.
It shrinks attacker dwell time. Instant, reversible suspension turns “we saw something suspicious” into immediate containment, removing the delay attackers depend on.
It cuts data exposure at the source. Direct SharePoint grant removal reaches the forgotten permissions that group-level governance can't see, reducing the surface area where sensitive data leaks.
It removes the excuse not to act. When teams have a proportionate response for every situation, they stop overreacting and they stop deferring. Remediation becomes routine instead of a risk-management decision every time.
Safe by Design, Because Action at Scale Demands It
Giving teams the power to act directly on identity risk only works if that power is governed. Every action, old and new, runs through the same safety-first workflow.
Before any action is available, customizable guardrails confirm the query's conditions are still valid and the action is appropriate. A granular preview shows exactly what will be affected and its current state, and you select precisely what to process before anything commits. Every execution requires a mandatory audit note capturing the reason. And every action, whether a disable in Active Directory, a group removal in Okta, a direct-grant removal in SharePoint, or an Okta suspension, writes to one unified Remediation Log: who acted, what they did, when, why, and the current status of every entity processed, searchable and persistent, with no extra instrumentation.
That combination, automation speed with a complete audit trail and human confirmation at every step, is what makes direct remediation defensible to a regulator and trustworthy to the business. It's the difference between fast and reckless.
Where This Is Going
The conviction behind all of this is simple: risk you can see should be risk you can resolve, without leaving the workflow and without reaching for a tool that's too blunt for the job. Disable Accounts proved the pattern. Group removal, SharePoint cleanup, and Okta suspension prove it scales into a proportionate toolkit.
As part of ServiceNow, this is exactly the direction we're accelerating: closing the distance between the signal and the fix until detection stops being documentation and starts being defense. Seeing risk clearly was step one. Acting on it precisely, safely, and immediately is what actually reduces it.
Try It Today
If you're a customer, the new actions are live in Access Intelligence now. Run your access queries and act on the results directly, matching the response to the risk: right-size access with a group removal, cut data exposure with a SharePoint grant removal, contain a threat with an Okta suspension, or deactivate outright with a disable.
Detection without action is just documentation. It's time to close the loop.
About the Author
