WEEK 26 · IDENTITY

Audit one privileged group and remove one person.

Privileged access creep isn't a tool problem. It's a Monday habit.

Submitted by Neil Watkins · MondayMove

You have a privileged access tool. Maybe two. Possibly three, if you count the one the last team bought and nobody remembers configuring. None of them have touched your Domain Admins group in eight months.

Privileged access creep happens the same way every time. Someone needs elevated permissions for a project, a migration, a vendor engagement. They get access. The work ends. Nobody removes them.

This is not negligence. It is physics. Adding someone to a privileged group has a trigger: a ticket, a request, an approval. Removing someone has no trigger. So membership grows, the group gets noisier, and nobody questions it until something forces the issue.

Every practitioner I have spoken with knows their privileged groups are bloated. That is not the problem. The problem is that "we should clean this up" lives permanently on the backlog, parked somewhere below the next tool evaluation and the next compliance deadline.

Most teams treat least privilege as an architecture problem. Get the right PAM solution, build the joiner-mover-leaver workflows, integrate with your IdP. The result is often a beautifully documented provisioning system with clean onboarding and six years of stale accounts in every privileged group it predates.

Least privilege is not an architecture problem. It is a habit problem.

The tool shows you who has access. The habit is the part where someone reads that list, makes a judgment call, and removes a person from it. No platform automates that. A practitioner has to do it.

So, here's the MondayMove

Pick one privileged group: Domain Admins, root in your cloud account, or the keys to your customer database. List every member. Find one person who should not still be there and remove them today. Then put it on your calendar for next month.

No tool required. Just the list and five minutes.

Friday Follow-Up

What Practitioners Found When They Audited One Privileged Group

More names than expected. At least one that shouldn't be there. Every time.

Submitted by Neil Watkins · MondayMove

June 25, 2026

MondayMove gives you one concrete action every Monday. FridayFollowUp closes the loop.

Each Friday, a short dispatch on what practitioners actually found when they ran the week's move: where they got stuck, what surprised them, and what to do next. Not sanitized case studies. Field notes. Practitioner to practitioner.

This week's move was direct: pick one privileged group, list every member, find one person who should not still be there, and remove them. One group. One removal. Five minutes.

The friction usually shows up before the removal, not during it. Pulling the list is fast. Reading the list is where things get uncomfortable. There is almost always at least one name that produces a long pause. Someone who left. Someone who moved to a different team. Someone who needed access for a project that wrapped up two quarters ago. The account is still active and nobody flagged it because nobody was looking.

The second friction point is the approval conversation. Even when everyone agrees the access should go, the question of who authorizes the removal can stall things. If that happened to you this week, it is worth noting: the removal itself is the easy part. The harder part is knowing whose call it is. If that is unclear in your environment, that ambiguity is the real finding.

Think about how organizations handle payroll. Nobody debates whether to remove a terminated employee from the payroll run. Nobody waits for a quarterly audit to stop paying someone who left. The rule is simple: unentitled people do not get paid, and that standard gets enforced fast because the cost of getting it wrong is immediate and measurable.

The same logic applies to privileged access. Unentitled people should not have keys to your most sensitive systems. The only difference is that nobody feels the cost until something goes wrong. That distance is the entire reason the list of people who shouldn't still be in Domain Admins keeps growing.

Some practitioners skipped the move entirely, not from indifference but from not knowing where to start. Domain Admins felt too risky to touch. Cloud root felt like it needed a change window. The right answer for those folks: start smaller. A shared mailbox with elevated permissions. A service account that a contractor created. Something lower-stakes where the removal is unambiguous. The habit matters more than the group you pick first.

If you ran the move and removed someone, the next step is to extend the cadence. Pick a second group next week or put a recurring calendar event on the books for 30 days out. The goal is not to audit one group. The goal is to make group review something that happens on a schedule instead of in response to an incident.

One removal is not least privilege. One removal, repeated, is how least privilege becomes a posture.

No correct answers here. This is practitioner-to-practitioner. The more honest the responses, the more useful this gets for everyone reading on Monday morning.

See you then.

Discussion