What is the principle of least privilege, and how would you enforce it in practice?

The principle of least privilege (PoLP) says that any identity — human or machine — should hold only the permissions it actually needs, for only as long as it needs them. It is one of the highest-leverage controls in security because it directly limits what an attacker or a mistake can do.

Why it matters: blast radius

Every credential is a potential foothold. If a phished user or a compromised service account has broad rights, the attacker inherits those rights. Least privilege ensures that compromising one identity yields a small, contained set of capabilities rather than the keys to the kingdom. The same logic protects against honest mistakes — a script that can only touch one bucket can't accidentally delete the whole estate.

Enforcing it in practice

• Role-based access control (RBAC): group permissions into roles tied to job functions instead of granting ad-hoc rights to individuals.
• No standing admin: remove permanent administrative privileges; grant them through just-in-time elevation that expires automatically.
• Scoped service accounts: machine identities get narrowly scoped permissions per workload, not shared god-accounts.
• Regular access reviews: periodically recertify who has what, because permissions accumulate over time — privilege creep — as people change roles.
• Default deny: start from zero access and add explicitly, rather than starting open and trimming.

A related idea

Need-to-know is the data-side cousin: even if you have the technical privilege, you should only access information relevant to your task. Least privilege and need-to-know reinforce each other.

What interviewers look for

State the definition crisply, then connect it to blast radius. The mid-level differentiator is naming concrete enforcement mechanisms — RBAC, JIT elevation, access reviews — and acknowledging privilege creep as the thing that erodes it over time.