Least privilege.

The principle, and why it keeps failing in practice

Least privilege is easy to state and hard to live. Every identity, a person, a service account, an automation script, an API key, should hold exactly the permissions its task requires and nothing else. The failure mode is rarely a deliberate decision to over-grant. It is accretion. Someone needs admin rights for a one-off migration and the grant is never removed. A service account is created with broad scopes because narrowing them would take an afternoon of testing nobody has time for. A team is given a role designed for a different team because it was the closest fit on the shelf. Over months, identities collect permissions the way a desk collects paper, and nobody can explain why any given one is there.

That accretion is the attack surface. When an over-permissioned account is phished, leaked, or quietly abused, the blast radius is whatever that account could touch, which is usually far more than its actual job. The discipline of least privilege is not the initial grant, which is the easy part. It is the ongoing work of removing what is no longer needed and being able to justify what remains.

How practitioners actually implement it

Least privilege is an operating habit supported by tooling, not a one-time configuration. The work clusters around a few recurring activities:

• Role and permission design: build roles around job functions so that granting access is a deliberate mapping, not a copy of whatever the last person had.
• Just-in-time and just-enough access: grant elevated rights for the window they are needed and remove them automatically afterwards, rather than leaving standing admin permissions in place.
• Access reviews: periodically re-examine who holds what and require an owner to confirm each grant is still justified. Anything nobody will vouch for gets revoked.
• Separation of duties: split sensitive actions so no single identity can both initiate and approve a high-risk operation, which is least privilege applied to workflows rather than data.
• Machine identities: treat service accounts, tokens, and pipeline credentials with the same scrutiny as human users, because they are often the most over-permissioned and the least reviewed.

Where it sits among zero trust, IAM and PAM

Least privilege is a principle. The neighbouring terms are the machinery that delivers it. Identity and access management (IAM) is the system that defines identities and what they can do, so least privilege is the rule IAM is supposed to enforce. Privileged access management (PAM) is the tighter discipline applied to the highest-risk accounts, where least privilege matters most and just-in-time elevation usually lives.

Zero trust is the broader architecture that assumes no identity is trusted by default and verifies every request; least privilege is one of its core mechanics, because verifying a request only helps if the access being granted is already minimal. You can hold the principle without the tooling, but at any real scale the principle without IAM, PAM and regular reviews quietly decays back into over-provisioning.

The idea is woven through the standards even where the exact phrase varies. ISO/IEC 27001 Annex A addresses access control, privileged access rights, and the periodic review of user access rights. The NIST access control family is built around least privilege and separation of duties as named principles. The CIS Controls call for controlled use of administrative privileges and account management. Auditors do not just want to see that access was granted correctly once. They expect evidence of an ongoing review cycle, and a standing admin account that nobody reviews is treated as a finding, not a convenience.