Least Privilege in Practice, Not on a Slide

Least privilege is the security principle no one argues with and almost no one achieves. The idea is trivial: every identity should hold exactly the access it needs to do its job, and nothing more. The difficulty is entirely operational. Permissions are granted under deadline pressure, rarely revoked, and quietly inherited — so a policy that was minimal on day one becomes a standing liability by day four hundred.

The gap between the principle and the running system has a name in most organisations: permission creep. A developer needs read access to one bucket for an incident, gets granted the whole account, and the grant is never rolled back. A role built for a migration outlives the migration by years. Multiply that across every human and machine identity and you arrive at the normal end state — a population of identities that could do far more damage than their job requires, which is precisely the blast radius an attacker inherits the moment one of them is compromised.

Why 'need' is the hard word

Least privilege sounds like a policy statement; in practice it is a data problem. To grant only what an identity needs, you must know what it actually used — and most environments do not measure this. Cloud providers now expose the raw material: access analysers that compare granted permissions against permissions exercised over a window. An identity holding two hundred permissions and using nine is not a judgement call. It is a measurement, and the other one hundred and ninety-one are the finding.

The moves that actually shrink privilege

• Start from deny, add from evidence. Default to no access and grant against observed usage, not against a job title or a worst-case guess. Access-analyser data turns 'what might they need' into 'what did they use'.
• Make grants expire. A permission with no expiry is a permission you will never revisit. Time-bound access — especially for elevated or break-glass roles — converts creep into a default-off state.
• Separate standing from just-in-time. Routine work runs on a small standing role; anything sensitive is requested, approved and granted for a bounded window, then automatically withdrawn.
• Attach the review to a real trigger. Recertify on role change and departure, not only on an annual calendar entry that everyone rubber-stamps.
• Include machine identities. Service accounts and CI roles are usually the most over-permissioned and the least reviewed — and they rarely have a human to notice the excess.

There is a cultural trap worth naming. Over-granting feels helpful and costs the granter nothing; the bill arrives later, on someone else's incident. A least-privilege programme has to make the safe path the easy path — fast, self-service, time-bound requests — or engineers will route around it with a broad grant that never gets cleaned up. The security team that answers an access request in a day with a scoped, expiring grant earns the right to deny the standing wildcard; the team that takes a week guarantees the wildcard wins.

Least privilege is a direction, not a destination

No environment reaches a permanent state of perfect minimality; work changes, and access must change with it. The realistic goal is a system where privilege trends down by default — grants expire, unused permissions surface automatically, and every access has a reason someone can name. An organisation that cannot answer 'why does this identity have this permission' for an arbitrary row is not running least privilege; it is running hope.

You cannot right-size access you have never inventoried. Least privilege begins the same place every other control does: you can't defend — or scope — what you haven't discovered.