Permissions accumulate; they almost never leave

In most organizations, access only ever flows one direction: up. Someone joins, gets the permissions they need, then picks up more for a project, covers for a colleague on leave, moves to a new team — and the old access comes along for the ride. Nobody ever circles back to take it away, because removing access feels risky and granting it feels helpful. The result, a few years in, is a workforce where half the accounts can reach far more than the job requires.

That sprawl is one of the most reliable findings in any security posture assessment, and it's exactly what an attacker counts on. The whole point of compromising a credential is what that credential can reach. Over-provisioned access turns one phished password into a key to the whole building. Least privilege is the discipline of making sure that key opens as few doors as possible.

Least privilege, stated plainly

The principle of least privilege is simple to state and hard to live: every account — human or machine — should have exactly the access it needs to do its job, and no more. Not the access that's convenient, not the access "just in case," not the access someone needed two roles ago. Just enough, and no extra.

The payoff is blast-radius reduction. When an account is compromised — and assume one eventually will be — least privilege decides whether the attacker lands in a broom closet or a vault. It's the same containment logic that limits lateral movement in a ransomware attack: the less any single identity can touch, the less any single compromise costs you. Strong authentication decides whether an attacker gets in; least privilege decides how far they get once they do. You need both.

Roles beat one-off grants

Managing access one permission at a time doesn't scale, and it's how sprawl happens. Role-based access control (RBAC) groups permissions into roles that map to job functions — "support agent," "billing admin," "read-only auditor" — and assigns people to roles instead of hand-granting individual permissions.

  • It's auditable. "Who can refund a customer?" becomes a question you can answer by listing a role's members, not by spelunking through thousands of individual grants.
  • It's reviewable. You evaluate whether a role has the right permissions once, instead of re-deriving it for every person.
  • It resists drift. New hires get a clean role, not a copy of whatever sprawling access the last person happened to have — the "clone this user's permissions" pattern is how one over-provisioned account quietly becomes ten.

Watch the high-value roles specifically. Standing administrative access is the prize an attacker is hunting; the fewer permanent admins you have, the smaller the target. Where a platform supports it, just-in-time elevation — granting admin for a window and revoking it automatically — beats a standing grant that lives forever.

Joiner-mover-leaver: the lifecycle that plugs the leaks

Most access problems trace back to one of three moments in an identity's life, and each has a failure mode:

  • Joiner. A new person needs access provisioned. The failure is over-granting — handing them a broad role for convenience instead of the narrow one the job needs.
  • Mover. Someone changes teams or roles. This is the most-missed event: they gain new access and keep all the old access, slowly accumulating the permissions of every role they've ever held. A mover should be re-baselined, not merely added to.
  • Leaver. Someone departs. The failure here is the dangerous one — an account that's never fully deprovisioned. Orphaned accounts of former employees and contractors, still live, still privileged, monitored by no one, are a standing invitation. Offboarding has to be immediate and complete, and it has to cover the easy-to-forget access too: SaaS tools, shared credentials, API keys, third-party integrations.

Access reviews: the periodic correction

Even with clean RBAC and tidy lifecycle handling, entitlements drift, so you need a periodic check that pulls them back toward least privilege. An access review (or recertification) is exactly that: on a regular cadence, the owner of a system or the manager of a team is shown who has access to what and made to affirm that each grant is still justified — or revoke it.

  • Cadence by sensitivity. Quarterly for systems holding regulated or customer data; at least annually for everything else.
  • Make the reviewer accountable. A review where the manager rubber-stamps the whole list to clear their inbox is theater. The reviewer should have to consciously keep or remove each grant.
  • Hunt the specifics. Dormant accounts that haven't logged in for months, privileged access that's outlived its reason, service accounts nobody can name an owner for, and external collaborators who should have been removed when the project ended.
  • Keep the evidence. A completed, timestamped access review is precisely the kind of continuous audit evidence that frameworks like SOC 2 expect — and reviewing access quarterly is far less work than reconstructing a year of it the week before an auditor calls.

Attackers don't break down doors when they can walk through one you left unlocked. Least privilege locks the doors you don't use; access reviews are how you keep finding the ones that drifted back open.