Principle of least privilege

The canonical statement comes from Saltzer and Schroeder's "The Protection of Information in Computer Systems" (1975): every program and every user of the system should operate using the least set of privileges necessary to complete the job. It sits among their eight design principles alongside fail-safe defaults, complete mediation, separation of privilege and least common mechanism, and its stated rationale is damage containment and a smaller set of code and people to audit. The capability-security community's variant, the principle of least authority (POLA), stresses authority rather than permissions, meaning everything a subject can cause, including indirectly through the objects and services it can invoke.

Control frameworks make it auditable. NIST SP 800-53 Rev. 5 control AC-6 has enhancements that are widely used as a checklist: AC-6(1) restricts who may reach security functions, AC-6(2) requires non-privileged accounts for non-security work, AC-6(5) limits privileged accounts to defined roles, AC-6(7) requires periodic review of privileges, AC-6(9) logs use of privileged functions and AC-6(10) prevents non-privileged users from executing them. ISO/IEC 27001:2022 Annex A 8.2 (privileged access rights) and CIS Controls v8.1 Safeguard 5.4 (dedicated administrator accounts) express the same idea.

Least privilege has three dimensions: scope (which actions on which resources), time (standing versus just-in-time access that expires) and context (only from a managed device, only for an approved change). At the operating-system level it means a daemon binds its port and then drops root, or holds only the Linux capability CAP_NET_BIND_SERVICE; seccomp filters and Windows UAC's split token work in the same spirit. In containers it means running as non-root, dropping all capabilities, a read-only root filesystem and no privileged flag; in Kubernetes, namespace-scoped Roles instead of ClusterRoles and no automatically mounted service-account token where none is needed. In cloud IAM it means resource-scoped policies without wildcards, permission boundaries, and tools that generate policies from observed activity or flag unused permissions.

The hard part is maintenance rather than design. Privilege creep through job moves, "temporary" grants that never expire, role explosion that pushes admins toward broad roles, and service accounts made domain administrators "to make it work" are the usual failure modes. Good practice measures the gap between granted and used permissions and trims it continuously, while keeping audited break-glass paths so least privilege does not undermine availability. Least privilege is a principle; RBAC, PAM and just-in-time elevation are mechanisms that implement it, and separation of duties is a related but distinct principle that splits one sensitive task across several people.