Least privilege, practically: taming admin sprawl and standing access

why least privilege is hard in practice

Someone joins and gets provisioned. They change roles and get more, because adding access is fast and removing the old access is nobody's job. They run a project that needs elevated rights, and the elevation never gets revoked. Multiply that across a few hundred people over a few years, and the access map stops resembling the org chart. People carry permissions three jobs deep, admin rights outlive the migration that needed them, and nobody can say who actually requires what.

This is simply how any system behaves when granting access is easy and revoking it has no owner. Least privilege is the discipline of pushing back against that drift on purpose.

the shapes excess access takes

Before you can cut it, name it. Excess access shows up in a few recognisable forms:

• Privilege creep. Access accumulated across role changes, never narrowed back. The single most common form.
• Standing admin. Elevated rights held permanently, used rarely, and exposed constantly. The highest-value target for an attacker.
• Orphaned elevation. Admin granted for a one-off task and never removed.
• Broad default roles. People dropped into a wide built-in role because it was faster than scoping a narrow one.
• Inherited access. Someone took over a colleague's responsibilities and got their access added on top of their own.
• Non-human over-permission. Service accounts and integrations with far more scope than they use, often the broadest grants in the environment.

Standing admin and non-human over-permission deserve the most attention. They carry the most power, they are watched the least, and they are exactly what an attacker who lands a single credential goes looking for. Most intrusions now begin exactly this way: 82% of interactive detections are malware-free, the attacker logging in with a valid credential rather than deploying malware (CrowdStrike, 2026).

how to find the excess

You cannot reduce what you cannot see, so the work starts with a current picture.

Inventory privileged access first. List everyone who holds admin or elevated rights across your core systems, and every service account and integration with broad scope. For each, capture who owns it and when it was last used. Last-used is the most useful signal you have: standing admin that has not been used in months is the easiest, safest thing to remove.

Compare access to role. For a sample of people, line up what they can reach against what their current job needs. The gaps between the two are your privilege creep. You do not need perfect role definitions to start; the obvious mismatches are visible immediately.

Flag the broad and the dormant. Wide default roles, accounts with access to systems they never touch, and elevation with no recent activity. These are the low-risk, high-value cuts.

how to remove it without breaking work

The fear that stops least-privilege work is breaking something someone quietly relied on. The way around that fear is sequence, not courage.

Start with the safe cuts. Standing admin with no recent use, orphaned elevation from finished projects, and access for people who have left. Removing these breaks nothing because nobody is using them.

Time-box instead of removing, where you are unsure. For access you suspect is unused but cannot confirm, move it from standing to on-request or time-limited. If nobody asks for it back, you have confirmed it was excess. Just-in-time elevation, where admin is granted for a window and expires, turns standing privilege into requested privilege without a hard cutover.

Narrow broad roles to scoped ones. Replace wide default roles with roles shaped to what people actually do. Do it role by role, not all at once.

Tackle non-human access deliberately. Reducing a service account's scope can break an integration, so confirm what each one actually uses before you cut. But broad, unused scopes on OAuth grants and service accounts are among the most important to close, because they are the least watched.

Communicate the path back. People accept tighter access when getting more is easy and fast. If the request path is painful, they will hoard access, and you are back where you started.

how to keep it from creeping back

A one-time cleanup decays the same way the original sprawl built up. Three habits hold the line:

• Grant with an expiry in mind. Default new elevated access to time-boxed rather than standing wherever your tooling allows.
• Tie access to role changes. When someone moves, review what they no longer need, not just what they now need. The mover step is where creep is born.
• Review privileged access on a tighter cadence than standard access, because it carries the most risk.

what it connects to

Least privilege underpins half the frameworks and most of the real risk:

• It is A.8.2 and A.8.3 in ISO 27001, CC6.1 and CC6.3 in SOC 2, and a named expectation in NIS2, DORA, and GDPR.
• It is the control that limits blast radius when a credential is stolen, which is how most intrusions now begin (82% of interactive intrusions are malware-free, CrowdStrike 2026).
• It depends on the joiner-mover-leaver lifecycle working, because that is where access is supposed to be right-sized.