Principle of Least Privilege

Best Practice: Principle of Least Privilege

The principle of least privilege (PoLP) states that every user, service, and process should have only the minimum access needed to do its job, and nothing more. First articulated by Saltzer and Schroeder in the 1970s, it remains a foundation of secure system design. It matters because broad permissions turn a small compromise into a large one. If an attacker takes over an account or service that can only touch one resource, the damage is contained; if that identity can touch everything, a single breach becomes catastrophic. Least privilege shrinks the blast radius of every incident. For a developer it is a design default that prevents accidental over-reach; for a leader it is the single most effective way to limit breach damage. It underpins zero-trust architectures, where no identity is trusted by default and every access is scoped, time-bound, and logged. The hardest part in practice is not granting least privilege but maintaining it, because permissions accumulate as people change roles and projects. Regular access reviews and automated removal of unused entitlements prevent this permission creep, keeping the principle real over time rather than just at the moment of provisioning. Least privilege applies not only to people but to machines and code: a service account, a CI pipeline token, and a background job each deserve the same scrutiny as a human user, and often more, because automated identities run constantly and are rarely watched. Treating non-human identities as first-class subjects of access control closes a gap that attackers frequently exploit once they gain an initial foothold.

Step-by-Step Implementation Guidance

1. Inventory identities, roles, and the permissions each currently holds.
2. Define the minimum permissions each role genuinely needs for its tasks.
3. Replace broad or wildcard grants with narrowly scoped permissions.
4. Separate duties so no single identity can complete a sensitive action alone.
5. Use short-lived, just-in-time access for elevated operations.
6. Review and remove unused permissions and dormant accounts regularly.
7. Log access and alert on use of high-privilege permissions.

Common Mistakes Teams Make When Ignoring This Practice

• Granting admin or wildcard permissions because it is faster than scoping.
• Leaving permissions in place long after the need has passed.
• Sharing one high-privilege account across a whole team.
• Giving services standing access instead of just-in-time elevation.
• Never reviewing entitlements, allowing permission creep over time.
• Granting temporary elevated access for an incident and never revoking it afterward.

Tools and Techniques That Support This Practice

• Role-based and attribute-based access control (RBAC and ABAC).
• Cloud IAM access analyzers that flag unused or overly broad permissions.
• Just-in-time and privileged access management (PAM) tooling.
• Policy-as-code engines (for example OPA) to enforce scoped permissions.
• Regular access reviews and automated dormant-account cleanup.
• Cloud entitlement management (CIEM) tools that continuously right-size identity permissions.

How This Practice Applies to Different Migration Types

• Cloud Migration: Replace broad legacy roles with narrowly scoped IAM policies in the new cloud.
• Database Migration: Grant per-service database roles instead of shared superuser accounts.
• SaaS Migration: Provision vendor and integration accounts with the minimum scopes needed.
• Codebase Migration: Re-scope service accounts and pipeline credentials as components move and change owners.

Checklist

• Inventoried identities, roles, and permissions
• Defined minimum required permissions per role
• Replaced broad grants with scoped permissions
• Applied separation of duties for sensitive actions
• Used just-in-time access for elevation
• Scheduled regular entitlement reviews
• Logged and alerted on high-privilege use