Organizations design endpoint privilege around the day someone joins. The onboarding checklist covers accounts, groups, applications, and the elevation policy that goes with the job. The endpoint privilege lifecycle gets real attention at exactly one moment — and then it stops.
The day someone changes role gets no equivalent checklist. A developer moves into finance. A service desk technician joins the network team. A project manager takes over a department. Their access to files and applications follows a process, because someone notices when it breaks. Their ability to elevate on the endpoint follows nothing, because nothing breaks. The user keeps working. The old permissions stay.
Over time this produces privilege creep: users accumulate permissions from previous roles and keep them long after the work that justified them ends. Every individual grant looked reasonable on the day someone made it. The accumulation never did.
Where the Endpoint Privilege Lifecycle Breaks
A role change produces no error message. That is the entire problem.
Nobody disputes the governance principle, and our case study on insider threat covers what it costs when an organization ignores it: when a role changes, access should change with it. This post takes the next question. The principle does not enforce itself, and knowing that access should move tells you nothing about what makes it move.
When someone loses access they still need, they open a ticket within the hour. When someone keeps access they no longer need, they never mention it — often they never notice. The gap closes only when a person goes looking for it, and most IT teams have no trigger telling them to look.
Standing local admin rights turn creep into a permanent condition. Rights that never expire survive every reorganization, every internal move, and every promotion in the organization. Ten years of role changes leave behind a set of permissions that maps to nobody’s current job. Auditors find these accumulations easily, because the pattern shows up the same way every time: long-tenured employees hold the broadest privileges, and no document explains why.
From Identity Governance to the Endpoint
The standards bodies treat role change as its own trigger rather than a footnote to offboarding. CIS Safeguard 6.2 asks organizations to revoke access on role change, not only on termination, and the rationale behind CIS Control 6 names two causes directly: access that lingers as people move between roles, and local administrator rights on user laptops.
That framing draws a clean line. Identity governance sets the rule — access follows the role. Endpoint privilege management has to carry the same rule down to the device, where elevation rights live and where nobody notices when they stop matching the job. Most organizations enforce the first half through their directory and leave the second half to memory.
Removing standing admin narrows the problem. It does not close it. Time-bound elevation stops rights from lasting forever, but a policy that grants the wrong scope still grants the wrong scope every time someone triggers it.
Group Membership as the Control Point
The practical fix is structural. Scope elevation policies to groups rather than to people, and the role change becomes the moment your privilege model updates.
CapaOne Privilege Manager, part of the CapaOne Endpoint Management Platform, defines who can elevate what, where, and under which constraints — per user, group, device, or application. Policies target Entra ID groups directly and respect the group structure you already maintain, so the identity system that already reflects someone’s job can also drive what they elevate on the endpoint.
When elevation policies point at groups, changing someone’s group membership changes which policies apply to them. The directory carries the decision, so nobody rewrites a privilege rule for every internal move. Confirm the behavior against your own group structure before you rely on it, and design for the two cases below, which follow different rules.
Removing standing admin is the starting point, not the destination — our solution page on endpoint privilege management covers that step.
Per-User Exceptions
Every exception you write for an individual attaches to that individual and outlives their job. These exceptions accumulate faster than teams expect, because each one solves a real problem on the day someone writes it. Record the reason next to every exception, and treat the absence of a reason as a signal to remove it.
Pre-Approved Applications
Privilege Manager lets you pre-approve applications by executable name or app path. That mechanism removes friction for routine work, and it describes a task rather than a person. A pre-approval that made sense for one team may make no sense once the person triggering it works somewhere else — so check pre-approvals against the roles that actually use them, not against the roles that requested them.
Role Change Review Checklist
Run this when someone moves, and run it across the affected teams after a reorganization.
- Confirm the new group membership. Check that the person sits in the groups their new role requires, and that those groups carry the elevation policies you expect.
- Remove the legacy group memberships. Adding the new groups without removing the old ones is the single most common cause of privilege creep.
- Find the per-user exceptions that name them. These survive every group change. Read the reason you recorded, and delete the exception if the reason no longer applies.
- Review the pre-approved applications their new policies allow. Ask whether the new role genuinely needs each one.
- Check the elevation durations. A task that took twenty minutes in the old role may take two in the new one. Shorten the window where the work changed.
- Read the last month of elevation activity. Elevations that fit the old job and not the new one tell you which policy to look at first.
- Export the evidence. Privilege Manager captures user, endpoint, executable name and app path, time, duration, and outcome for every elevation event, and exports the record to CSV. Keep the export from before and after the move.
- Set a follow-up. Book a second look thirty days later. New roles reveal requirements the first review misses, and unrecorded workarounds appear in that window.
Steps 6 and 7 need evidence rather than memory. Filter the CSV export to the people who moved, sort by executable, and read it next to a list of their current groups. Anything triggered by an application their new role does not use marks a policy that has outlived its purpose.
Metrics Worth Tracking
The heading matters more than it looks. Governance arguments lose to budget arguments because they arrive without numbers, and every figure below comes out of data your team already holds.
- Standing local admin accounts across the fleet. The headline number, and the one a board understands without translation.
- Per-user elevation exceptions. A rising count tells you the group model needs work rather than more exceptions.
- Age of the oldest per-user exception. An exception should cover a temporary need. This number shows whether yours do.
- Share of elevation policies scoped to groups rather than individuals. Your best single indicator of whether privilege follows the organization.
- Average elevation duration. Shorter windows mean tighter scope, and the trend matters more than the absolute figure.
- Elevation events that fall outside the user’s current role. The direct measure of privilege creep, and the one that needs the CSV export.
- Role changes reviewed within thirty days. Turns the checklist above into something you can report on.
Track these quarterly rather than continuously. The point is the trend line, not the daily number, and a quarterly cadence survives contact with a busy team.
Privilege Manager runs as a complete platform on its own, and it targets Entra ID groups whether or not you run Microsoft Intune alongside it.
Where to Start
Pick the last reorganization your organization completed and treat it as a test case. Pull the elevation log for the people involved, read it next to the groups they belong to now, and count the mismatches. That number tells you whether your privilege model follows your organization or lags behind it.
A mature least-privilege model does not end at removing local admin rights. It holds when elevation permissions keep matching what people actually do, through every internal move the organization makes. Getting the first part right takes a project. Keeping the second part right takes a structure.
Book a demo of CapaOne Endpoint Management Platform and we will walk through elevation policy design against your own group structure.