Standing Access Revocation: Closing the Revoke Gap

Granting access in a Microsoft environment is fast. Someone starts a role, submits a request, or gets added to a project, and within minutes they have a group membership, a license, and a set of permissions to match. Standing access revocation almost never moves at the same speed. A person changes roles, leaves a project, or exits the company entirely, and the access they no longer need quietly stays in place, sometimes for months.

This asymmetry is the core of what security teams call the revoke gap: the time between when access should be removed and when it actually is. It is not caused by carelessness. It is caused by the fact that granting access is usually a single, deliberate action with an obvious trigger, while revoking it depends on someone remembering, noticing, or being told, none of which happen reliably at scale. The result is standing access: permissions that persist well past the point they were needed, accumulating quietly in every Entra ID tenant and on-prem Active Directory forest.

Fixing this is less about better intentions and more about redesigning how access is tied to a person's actual status. This article walks through why the revoke gap forms, what it costs, and how attribute-based, automated lifecycle management closes it.

Why Standing Access Accumulates

Standing access is not a single mistake. It is the cumulative effect of small gaps that repeat across every joiner, mover, and leaver event.

Grants have a trigger; revokes usually do not

When someone joins a team, there is a clear moment that kicks off access provisioning: a start date, an onboarding ticket, a manager's request. When someone moves off a project or changes departments, there is rarely an equivalent trigger for removing the access tied to their old role. Nobody files a ticket to say "please remove me from groups I no longer need." That access just stays.

Group membership outlives the reason it was granted

Security and distribution groups in Active Directory and Entra ID were built to be added to easily and reviewed rarely. A person picked up group membership for a six-week project two years ago and nobody has looked at it since. Multiply that by every project, temporary assignment, and cross-department collaboration an organization runs, and the group membership list stops reflecting who actually needs what.

Leaver processes focus on the account, not the full access footprint

Most offboarding checklists disable the account and remove it from the most obvious systems. But a person accumulates access across dozens of groups, application role assignments, and shared resources over a tenure of several years. A checklist built around "disable the account" catches the account. It does not reliably catch every group, every shared mailbox permission, and every application role that person picked up along the way.

Manual reviews cannot keep pace with change

Even organizations that run periodic access reviews are checking a snapshot, typically once a quarter. Standing access created in week two of the quarter sits unreviewed until the next cycle. By the time a manual review catches it, the access has already existed, unused and unmonitored, for weeks or months.

What Standing Access Actually Costs

Unrevoked access is not a theoretical risk. It has concrete, recurring costs.

• A larger attack surface. Every account with more access than it currently needs is a bigger target if that account is ever compromised, whether through phishing, credential theft, or an insider threat.
• Audit and compliance friction. Frameworks like ISO 27001 and NIS2 expect organizations to demonstrate that access matches current need. Standing access from a role someone left a year ago is exactly what an auditor will flag.
• Wasted license spend. Access frequently travels together with a Microsoft license. A former project member who kept their group membership often kept the license tied to it too, sitting unused.
• Slower, riskier reviews. The more standing access accumulates, the longer and less reliable every subsequent access review becomes, because reviewers are wading through noise instead of exceptions.

None of this requires a breach to matter. It shows up as risk on paper long before it shows up as an incident.

Closing the Revoke Gap With Attribute-Based Access

The most durable fix is not a faster manual process. It is removing the dependency on someone remembering to act.

Tie access to attributes, not to a point-in-time decision

When group and role membership is assigned automatically based on attributes like department, job title, and location, access is not a decision made once and left alone. It is a live evaluation. The moment an attribute changes, whether HR updates a job title or a manager moves someone to a new cost center, the access tied to the old attribute value is no longer justified by the rule that granted it in the first place.

Let a mover event trigger revocation automatically

A mover, someone changing roles internally, is the case standing access loves most, because the move itself rarely triggers any cleanup. With attribute-based access, a role change is not just a new grant. It is also an automatic re-evaluation of every existing membership, so access from the old role is removed as part of the same event that assigns access for the new one, not left to be discovered six months later.

Automate the leaver event completely

For someone leaving the organization, revocation cannot depend on a checklist being followed correctly by whoever handles offboarding that week. ServiceChanger's ABAC engine ties group and role membership to a person's attributes, so when a leaver's status changes, access tied to those attributes is revoked automatically, across Entra ID and on-prem Active Directory, rather than department by department. For organizations that want the full onboarding and offboarding process driven directly from their HR system, this can be built on Azure automation accounts and runbooks on top of that same engine.

Use group mining to find what manual grants missed

A lot of standing access exists as manual, one-off group additions that never got mapped to a rule. Group mining looks at existing access patterns and suggests which memberships actually reflect a defined, attribute-based structure. That turns undocumented legacy access into something a review can actually reason about, rather than an unexplained line in a long list.

Standing Access vs. Automated Lifecycle: A Comparison

Aspect	Manual / ticket-based	Attribute-based automation
Trigger for revocation	Someone notices or files a ticket	Attribute change (role, department, leaver status)
Timing	Days to months after the fact	At the moment the attribute changes
Coverage	Limited to systems someone remembers to check	Applied consistently across Entra ID and on-prem AD
Review burden	High: reviewers see everything, including what is already correct	Low: reviews focus on exceptions outside the rule set
License impact	Unused seats often go unnoticed	Surfaced through real sign-in activity and usage reporting

Where Self-Service and Reporting Fit

Automating the revoke side of the lifecycle does not mean removing people from the loop entirely.

Self-service keeps requests intentional

When users request access themselves through a self-service portal, rather than picking up broad group membership by default, the access that does get granted is tied to an actual, stated need and an owner who approved it. That makes the eventual revoke easier to justify too, because there is a clear record of why the access existed.

License reporting flags what standing access is costing you

ServiceChanger's license module tracks Microsoft license usage from real Entra ID sign-in activity, keeping a contract and seat registry and flagging unused seats, over- or under-utilization, and contracts nearing renewal. It will not revoke a license SKU for you, but it gives IT and finance the insight to see exactly which seats are tied to standing access nobody is using, so the right people can act on it.

FAQ

What is standing access? Standing access is any permission, group membership, or role assignment that persists after the reason it was granted no longer applies, typically because a person changed roles, finished a project, or left the organization and the access was never revoked.

Why is revoking access slower than granting it? Granting access usually has a clear trigger, like a start date or a request, while revoking it depends on someone noticing the access is no longer needed. Without an automatic process tied to a person's current status, that noticing rarely happens promptly.

Does attribute-based access control (ABAC) actually remove access automatically? Yes, when access is assigned based on attributes like department, job title, and location, a change to those attributes triggers a re-evaluation, so access tied to an outdated attribute value is removed as part of that same event rather than waiting for a manual review.

Can ServiceChanger revoke Microsoft licenses directly? ServiceChanger's license module reports on real usage and flags unused or underutilized seats along with contract and renewal details. It gives you the insight and right-sizing guidance to reclaim seats; the ABAC engine handles the group and role membership side of revocation directly.

If standing access has been quietly building up in your Entra ID and Active Directory environment, it is worth looking at how much of it could be closed automatically by tying access to attributes instead of memory. For a broader look at structuring this, see our guide to access governance and compliance, or browse our Access Control and Compliance coverage. If you want to see how ServiceChanger closes the revoke gap in practice, get in touch.