Privileged access management covers the admin accounts — the keys to everything. Least privilege is its wider sibling: the principle that everyone’s everyday access should match their actual job — the bookkeeper reaches the accounting system, not the HR files; the sales team sees the CRM, not the engineering archive. It sounds obvious. It’s also, in nearly every environment we onboard, quietly false — because access has a physics problem: it only ever grows on its own. Here’s why, and the modest discipline that reverses it.
The physics of access sprawl
Nobody designs over-broad access; it accumulates. The new hire gets “just copy Bob’s permissions” — inheriting Bob’s decade of exceptions. The temporary project grant never expires. The promotion adds new access without removing the old, so twenty-year employees hold the union of every role they’ve ever had. Departures remove people but rarely tidy groups. Each grant was reasonable; the sum is an organization where “who can see the payroll folder?” has no crisp answer — which matters because access breadth is blast radius: the phished account does exactly as much damage as its permissions allow, ransomware encrypts what the infected user can reach, and Copilot cheerfully answers from everything a prompt-writer can technically open.
Design by role, not by person
The fix starts with a small design exercise: define access per role, once — what does “bookkeeper,” “project manager,” “field tech” need? — and grant by membership in those roles (security groups, in practice), never by individual exception. The payoffs stack: onboarding becomes assignment rather than archaeology, promotions become a role swap (old access removed as new is granted — the step sprawl feeds on), and “who can see X?” becomes readable at the group level. Two supporting rules keep the design honest: sensitive data lives in containers scoped to roles — the classification map’s Restricted tier in tightly-membered sites, not scattered where broad groups reach — and exceptions ride the exception process: written, expiring, owned, because the individual grant with no end date is exactly how the physics restarts.
The access review: gravity’s counterforce
Design decays without maintenance, so the standing discipline is the twice-yearly access review — an hour per pass, sharpened by scope: skip the low-stakes shares and review the containers that matter (Restricted-tier sites, finance and HR systems, the admin roles, external guests and vendor accounts). The method is one question per name: does this person’s current job need this? — answered by the data’s owner, not IT, because the accounting manager knows who belongs in the accounting system and IT only knows who’s in it. Findings get removed on the spot; the count of removals is a metric worth trending (it should shrink as the role design matures), and the review’s evidence is precisely what insurers and auditors mean when they ask about access control.
Selling it internally
Least privilege has a reputation problem — it sounds like distrust. The honest reframe, worth saying in the rollout meeting: this protects employees as much as data. The person with minimal access is minimally interesting to attackers, minimally exposed when their account is the one phished, and cleanly outside the suspect pool when something goes wrong in a system they never could touch. Broad access is a liability the holder never asked for; scoping it is a favor, not an accusation — and paired with a fast request path for the genuine needs, almost nobody misses the access they never used.
The bottom line
Least privilege is role-shaped access plus a counterforce to sprawl: design permissions per role, grant by group, swap on promotion, expire the exceptions, and review the sensitive containers twice a year with the data’s owner answering one question per name. It shrinks every incident you’ll ever have — phish, ransomware, insider, AI-assisted oversharing — before it happens, which is the quiet definition of the best security work: blast radius, reduced in advance, on a Tuesday.